Project Management Software
Specialists in Project Infrastructure
Scope CreepOnce upon a time there was an old man who had lived in the one street all his life. He wanted to keep his memories of the people who worked in the street and asked an artist if he would help.
The old man took the artist into the street and asked him how much, and how long, to paint everyone in the street. The artist looked down the street, and counted 20 people. He said
The old man then walked him to the other end of the street.
To his surprise the artist could now see 30 people. Some were in doorways. Some couldn't be seen because they were standing behind other people. One person had been doing up a shoelace behind a car. The artist said
Does this sound familiar? How often do we count what we can see, and make an estimate based on that. Again and again, the time blows out because of what we didn't know we had to count. It is common sense to know that if we are trying to plot everything that needs to be done over several months in a project, we will not be able to see everything. We must make allowances for the unknown.
Try this exercise when explaining the concept to a person who is demanding an estimate. Ask them to write down everything that they are going to do next weekend - from midnight Friday to midnight Sunday. Allocate a time to each task. Add up all the times and see how much free time they have in the 48-hour period. Chances are you will come up with 8 or 10 hours of free time. When you ask them if they will have that time free, the usual response is
"Of course I won't have that amount of time free. The kids will need to be taken somewhere, and there will be a few people drop in or phone me, or we will decide on the spur of the moment to go out for lunch. I will be lucky to have 2 or 3 free hours."
Projects are no different. There will always be unforeseen activities. To sit down and list all the activities you know about, then allocate a time to each activity, then add up the time, will only give half the picture. If you can't see it, it doesn't mean it isn't there. So how to handle the contingency. In most organisations, contingency is a dirty word. Here are a few strategies.
The further away the activity, the more difficult it is to scope. You have a good idea of what you are doing tomorrow, and how long it will take. You don't have the same clarity about the week after next. In this case, take the activities towards the end of the phase and double the time.
For example, the phase is to produce a requirements report. You think after all the workshops and interviews, the report will take three days to write up. Make it six days. Build in a review step which will take a day, and a rework activity that takes another day. If challenged, talk about adding quality to the output by undertaking a formal review prior to delivery.
Not as effective as padding, you can gain approval for a budget and schedule that reflects what you know now. Argue that the quote is only for what is specified in the list of activities. For additional activities there should be a separate fund where time and cost can be added to the project, subject to approval by the Sponsor.
When something comes up, there is a process in place to go to the Sponsor and draw on the funds. To make this happen, the Sponsor needs to understand that foresight is not as accurate as hindsight. The responsibility also is passed to the Sponsor to agree variations or to reject them.
Move the focus from Scope, Resources, Cost and Quality, to Time. Agree with the Sponsor that we will achieve as much as we can within the fixed time period. In this way when a scope variation arises, you can take the option to the Sponsor to include the variation but take out something else (or perhaps provide more resources or money).
Phase by Phase Estimating
By far the most effective way to estimate is on a phase by phase basis. By phase, I mean a two to six week chunk of work with clear deliverables. It is far easier to forecast six weeks ahead rather than six months ahead.
This is a more painful path but can prove a point. Record the time and cost estimates for each project (or phase) in the organisation. Compare them with the final result. Over a period of a year or two, you will start to throw up a pattern of the level of underestimation. Use this as the basis for your contingency.
Making accurate estimates in an IT project is a flawed technique. IT estimation is an art, not a science. That is not to say there should be no estimate. No estimate is worse than an incorrect estimate. At least if an estimate exists, you can see how you vary as the project proceeds.
The key is to get the organisation to understand it is not a fixed tender. There will be variations because with IT projects, the future is rarely clear. Farmers might forecast income for their crops, but they cannot predict drought and flood. They cannot foresee disease or attack by pests. They cannot control world markets that dictate prices and demand.
Similarly IT Project Managers do not have control over the complexity and cost of the required solution until the evaluation of the proposed solution is complete. How many simple name and address solutions have turned into multi-million dollar CRM implementations? How many software purchases have become hardware upgrades when the finally selected solution came to be implemented?
The critical questions are often not visible at the start of the project. Even if they are, they may not be answerable unless you provide all the permutations on how the question might be resolved. The answer would become meaningless.
The correct answer is that the project will take X months and Y dollars however our best guess is that the estimate might be out by up to Z%. It should be expected that the numbers will change. As the project progresses, Z% hopefully reduces, and X months and Y dollars can be refined.