Project Management Blog

In the following posts I’ll define the term “Internal projects” and will show that they are essential for any IT department.

Despite the fact that there are managers out there, that understand the value of inner projects and the fact that these project already exist, too many IT departments still fail to understand how important they are. Thus, my task is to offer another point of view of this subject, which will hopefully help more IT managers see the light.

So let’s start by defining the term – “Internal project”

Internal project is a development project which output is a tool or a system that only serves the IT department. The project is financed solely from the IT budget and the system does not generate any direct revenues.

At first look it doesn’t look like much of an offer. Give me your budget and give me your time any in return I’ll give you a tool or system that generates no revenues. No wonder a lot of managers refuse to this strange offer.

Nevertheless, strange as it may look, any IT manager must accept this offer.

So as I said before…In the next posts I’ll show why are the Internal Projects so important and how they should be implemented

Asaf Gilad

It is imperative to understand the overall Business goals of an Organization while it comes to executing Projects.

In today’s world of rapid change, often Management has to fine tune the methods and roadmap to reaching Business Goals. Eventually this frequent one degree shift impacts the whole Organization. However these changes are not trickled down to the floor where the work gets done - as a result the projects start drifting away from the Project goals and the PMO start panicking....
The ongoing economic downturn has forced Organizations to live on split second decision. Probably it’s a new way of governing Corporations and the project Teams have to learn it fast to cope with it.

I think the PMO should work very closely with the Management and any and every shift and turn should be propagated to the Team members with its impacts. This open communication helps to rebuild the lost confidence, keeps the project in focus and finally accomplish Corporate goals.

Overview: Risk management is a key, if under-appreciated, part of project management. Managing things that you’ve mapped out thoroughly and understand in detail is challenging at times, a science in its own right. However, a knack for managing unknowns elevates your work to the level of art.

Every professional Project Manager understands the triple constraints of scope, schedule and budget. We also understand that everything affects everything else. Of course there are other constraints such as quality, customer satisfaction and so on that we also have to consider. External constraints impact your projects such in the form of weather, labor conditions and even legal requirements. Dealing with these known constraints is a big part of the planning effort and putting those different parts into a coherent and effective whole is every bit as much an art as composing a symphony.

Now… imagine performing your grand opus in the middle of a desert in Dubai or in the middle of retooling for a manufacturing plant. Imagine performing your symphony without a dropped note while changing out the IT infrastructure for the banking industry during a financial crisis. You no longer have quite the same opus.

You have a series of choices to make to deal with the unknowns you’ll face. Each choice will affect other parts of your project. Chances are good that your project will spin off into chaos. A very large part of all projects do fail in at least one of the triple constraints.

To stretch the musical metaphor just a bit further, imagine your project not so much as a symphony, with every note placed just so in the idealized setting of the concert hall… imagine it as jazz.

Risk management is the tool set and approach that allows you to work within the chaos to produce beautiful music, even if you arrive at the end by a different route every time you play.

Framework: First, let me sell you a little on why risk management is worth the extra effort. Then let’s look at how you can promote risk management to your stakeholders and use it most effectively. Finally, some thoughts about risk management in general to help put everything into perspective.

Somewhere on the Internet is a web site devoted to “The 2 Rules”. It contains a long list of heuristics, rules of thumb, for hundreds of professions. For example, boxing has the following two rules:
1. Hit the other guy
2. Don’t get hit

For amateur project managers, the two rules might be: 1. Things go wrong
2. See rule 1

For a professional PM with some experience:
1. Things go wrong
2. Deal with it

For a PM who really understands Risk Management…
1. Things go wrong
2. Take advantage of it

True, doing a credible job at risk management takes extra time and effort, along with the active participation of the project team – things which are all usually in short supply. However, it’s one of the few parts of project management, aside from the work breakdown structure itself, where you get multiple benefits for a single activity.

Here are some things to consider about Risk Management. You get more accurate estimates, sometimes lower than originally planned but almost always more accurate. You get the Work Breakdown Structure clearly understood, communicated and even critiqued by all the key project team members. You have actively looked for possible problems and also possible opportunities that will help the project. You project team not only understands what needs to be done, it now understands how problems in one area affect the other areas. You get the chance early in the project, when changes cost the least, to identify and fix potential issues.

If those things helped convince you of the value of Risk Management, consider these things when you try to advocate for it:

When “Things go wrong”, you have a plan to deal with them in the most effective manner possible, as early as possible.

When things go right, you get the choice of going to your stakeholders and returning reserves from the project budget or of bringing in the project further under budget.

If you have planned well, you may have the chance to take advantage of unexpected opportunities. Not all risks are negative risks. For example, because of risk reserves set aside for price fluctuations in energy, when fuel prices dropped, you were able to buy all your asphalt paving and asphalt based roofing materials at a steep discount. When the prices rose again, you’ already locked in at the lower price.

As any professional PM will know, when things go wrong it’s ultimately your job to deal with it. If your planning has been effective and if you have been successful in building good contingency plans, you won’t be left wondering what to do next in the event of problems.

General Thoughts On Risk Management and Project Management --

It seems to me that it’s a lot easier on the ego to learn from the mistakes other people make but it seems to stay with you better when you do it yourself.

Building on my earlier musical metaphor, give some thought to how a jazz combo goes about producing an improvisational piece that’s more inspired than the original. Jazz is anything but spontaneous; a good musician has practiced for years and truly understands the territory. The group practices and rehearses together. There is a solid framework underpinning the music that never goes away. A riff may go far from the original tune, but at some point always returns to the original direction. The best jazz musicians work well together; know what to expect from each other and play to make each other sound better. While jazz is being produced, nobody just “phones it in”. Everyone is fully engaged and paying attention. See any parallels to what a great project team should look like?

We can draw Risk Management lessons from the armed services. I’m referring to combat of course, but specifically I’m thinking about damage control. In combat, THINGS GO WRONG. That’s what combat is. If you don’t have a plan, have it understood by everyone, have it well rehearsed and prepared in advance, people die. People you care about die.

Some general principles in combat risk management that apply to all risk management:
1. Have a plan
2. Make certain it is flexible
3. Keep it simple (at least simple to execute for the guy on the front line)
4. Make sure it’s understood by everyone
5. Practice, rehearse and think it through in advance.
6. Always have reserves in place
7. Be prepared for the worst case
8. Be prepared to jump on opportunities
9. Have a back-up plan
10. Have a fall back position prepared
11. Someone always fails to get the word, be ready for that.
12. Always guard your supply lines

Sometimes, Risk Management can be daunting. It’s helpful to have templates and checklists to help think through and brainstorm about things that can go off track.

Use a Risk Register to track risks and the trigger points when those risks must be dealt with. It’s a great way to keep from getting blindsided.

When brainstorming, tell the team that you will make several passes through the list of risks to get a better picture. Try to go through at least one pass that’s just “silly stuff” like asteroid collisions to get the team to loosen.

Realize that all risks get written down but only risks considered to be above the tolerance threshold are going to actually require follow-up. Others will only need to be monitored.

Try throwing out lists of categories, like “Manpower”, “Money”, “Management”, etc. to give people a starting point to drill down and capture general risks. Try “Politics”, “Processes”, “Payment” or the more familiar Initiation, Planning, Execution, Management, Closing cycle. See if you can get two or three risks from every category.Be sure to work through risks that are specific to each work package in the Work Breakdown Structure.

Once you’ve captured a list of risks that you think is comprehensive, try making a pass through it to see if you can identify positive risks, (opportunities).
It’s rare that a problem can’t be turned to some advantage.

Once you have your risk register populated, it’s time to evaluate, quantify and plan for contingencies. Be certain you have a good understanding of your stakeholder risk tolerance levels and be sure to communicate with them regarding the way you’ll set your risk tolerance thresholds. You may want to consider dual risk tolerance thresholds for large projects. A lower one where a trigger for action is defined and an owner assigned to monitor the risk, then an upper tolerance threshold beyond which contingency plans must be developed.

For smaller projects, for risk of low impact and low likelihood, it’s probably a safe bet to make the assumption that one or two will occur (add into the reserves) and ignore the rest.

Getting accurate estimates for the work needed to deal with risks will allow your overall budget estimate to be more accurate. The reserve planning for both time and budget can be used to communicate with the project team why it’s not a good idea to pad estimates. As you develop the risk estimates, you have the opportunity to explain the purposes of the risk reserves and management reserves.

Risks with very high probabilities, 90% or above, are equivalent to issues or events. You might as well deal with them as if they have already occurred. If you do get lucky and the 90% probability doesn’t happen, you’ll have taken a calculated risk, pun intended, that in this case simply didn’t pay off. Think of it as buying insurance. If you had failed to act and not committed resources when the risk became reality, you’d have been much worse off.

Summary --- Risk Management tools and techniques and the team’s awareness of the need to accommodate risk allow you the ability to remain relatively calm while dealing with chaos. Risk Management allows you the freedom to plan for the truly unexpected because you don’t have to waste time dealing with those risks that could be reasonably expected. You may even get the chance to grab onto opportunities you’d never see or be able to capitalize upon without this preparation. You are the conductor in the symphony of your projects. Risk Management might just be the grace note you should consider emphasizing in your next composition.

How to start a project?

Get a reference point.
Whatever it is.

Good chances are that the project is based on an emotional desire. No one wrote a Specification. Some one knows one part of the project, some one else knows another. There's no one 'oracle', no one place which holds the whole information in an ordinated manner. No constant reference point which one can work by, sometimes no one to ask either.

A few years ago I lived in the country side. One night I went out for a run in the fields. The hour was 22:00 and the fields were much vast and dark than I imagined them to be.

Instead of 20 minutes run, I found myself unable to position, running around in circles (probably, I saw nothing). After a while, when I started loosing patience, I decided to stop choosing different directions every time I believe I run in the wrong direction and instead to find a light source and run towards it. 10 minutes later I found my self near the lights of a small village street far from my home. I continued walking down the street and from there hitch hiked home. The whole adventure took something like 90 minutes.

When you get a project, look for reference points.

Start building a model with what you have. A model shouldn't be a specification document but the actual thing (if it's a program, you should actually program it).

Always try to understand the small details, they will hold the keys to understanding the whole system but never try to implement all of them in the model.

Cling to the big reference points.

• What are the main objects of the project?
• What can't the project work without?

Build it up together.
Don't try to cover 100% of the cases.
Build the simplest implementation.

Remember, it is cheaper to build 2 tools which do specific functioning than building 1 which does both. It's much pricy to build or buy a Swiss Knife than a simple set of tools for each function needed.

In databases, many times - it's chipper to do 2 SQL queries with a UNION instead of 1 complex one.

Never try to fulfill all the functionalities of the project with one tool. It's cool and interesting but it might cost you your seat. If two functionalities are ment to be processed by one tool, it will naturally happen in a later phase - when similarities of the two different tools will intrigue you to commit this change specifically.

As you continue in the process of building this model, you will naturally see what's central and what's not. It will be possible for you and for your client to ask the right questions and get the proper answers.

Along the way, keep an open eye on the weak points of the model - write them down, think about them, plan and finally refactor.

This article provided by dorkalev.com.

I always thought that writing a good spec before programming is mandatory.

I like short but frequent discussions where a project spec is being written. I found out that having a spec (Agile, or not) is something mandatory. Ever since I understood I have to demand a spec from the customer, even if I have to sit down with him and write it together (frequently), programming became a much faster and easier task to commit.

It is funny that in our world of 'thinking' people, so many times we don't think and rush to program without a true moment of thinking.

If you know the road, you can reach the target.

If you start programming before having a plan, you might find yourself in a chaotic situation. You spent a lot of time programming stuff that isn't needed at all and now you have 20 waiting tasks with unknown priorities. Chaos. The customer isn't nice anymore, you are frustrated and the project becomes more and more complicated.

In cases where the possibility of getting a good spec is low there's a project management style that has to be considered - the chaotic one.

The Chaotic Project Management

1 In the beginning God created the heaven and the earth.
2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.

Genesis I, 1-2

Bring the customer to your office for a couple of days or go sit with him in his. Define short tasks together and to them with his constant observation. The customer should understand that for this matter you function as his 'hands' and to the actual programming but what will be is what he asks.

Don't think about performance or beauty of code. Don't think about good DB structure, think about getting it done.

This project management style gets results very fast but it is pricey and demands great patience. It should only be used when you know you can't go a step forward in the project because of lousy communication and bad specs.

It should be done only with customers you have intimate relation with and are ready to go into this adventure with the price it demands.

Many clients don't understand what project they wish to have. This project management style is all about getting to know the project. It's about managing something that has yet been formed ("without form and void").

After a while, you'll have a clearer picture of what the project is and so would your customer.

Now will be a good time for both of you to write a good spec and manage this project in a more conservative way.

http://www.bartleby.com/108/01/1.html#S1

This article provided by dorkalev.com.

Today a client of mine emailed me with great news. He is starting to see results from the last 6 months of his marketing efforts. For instance, his sales pipeline is heating up thanks to an educational letter and follow up campaign we worked on—including 2 recently closed deals. He just spoke at an association that serves his target market and landed a client and a lead that way. Plus he is actively getting referrals from his existing customers, which now number about 70.

But 4-5 months ago, things didn’t look so rosey. It is only thanks to a consistent, focused commitment to marketing that he has achieved these results.

While you can see instant results by marketing, it takes time and persistence to build momentum.

Hopefully you have a plan and are sticking to it. Don’t get frustrated. Results come to those who persist.

Some positive thinking guru used to tell the story of a bunch of gold diggers who dug a big hole looking for gold and eventually gave up. Then someone else claimed the land and found a huge supply of gold after digging only one foot more. Keep digging!

This article provided by sitepoint.com.

The last blog post talked about the importance of failure.

There are two mindsets that makes failure acceptable and bearable, and they are non-judgment and non-attachment.

Both of these mindsets mean that you can go all out to get your business going, or to make a sale—but you stay a bit detached. You don’t judge yourself. You don’t take things personally. You don’t wrap your ego up in how things go, and instead drive to the outcome.

If things work out, great! If they don’t, you observe what happened, learn, make adjustments, and try again.

Many people misinterpret non-attachment to mean that one is passive. That’s not the case. You still move forward powerfully and with full intent. You still give it your all. But you don’t add the junk that so many people add—like tying your sense of personal worth to your success or failure.

A friend and business partner and I recently invested lots of money in a business that didn’t quite work out. I mourned it for a while, and then moved on. He is still kicking himself about the result. What’s the point?

There is a Zen story about two monks crossing a river, when they meet a beautiful naked girl. She asks for help crossing the river. The older monk picks her up and crosses the river, while the younger monk looks on in shock (as monks are supposed to be celibate and avoid beautiful naked girls). A mile or so down the river, the younger monk is still in shock, and can’t stop thinking about the older monk’s behavior. The older monk says something like, “I crossed the river with that girl a mile ago and left her there, yet you still carry her.” I think lots of people still carry their burdens of long and not so long ago.

There is a great book called the Inner Game of Tennis by Tim Galloway that everyone should read—tennis player or not. In it, Galloway talks about a Self 1 and a Self 2. Self 1 is our rational, thinking self. It is the self that gets all wrapped up in ego and judgment. It is the self that causes players to talk to themselves on the court, or throw their racket when they miss a shot. Self 2 is the self that actually gets things done, and hits the ball—without thinking, but simply by doing. His approach is about trusting and developing Self 2.

The same applies to business. The more you can let your Self 2, your non-judgmental and non-attached observer and doer, do the job, the happier and more successful you will be.

Another fine book to read is Money and the Meaning of Life—which gets into our attachment to and judgments about money. How we think about money has a lot to do with our enjoyment and ultimate fulfillment and success.

Failure means nothing. Success means nothing. Striving for excellence and fun—that’s everything (and also nothing).

Hopefully this does not come across as too fluffy or mystical. It is a very crucial point, and a hard one to put into practice.

This article provided by sitepoint.com.