It is an age-old question. Which came first, the estimate or the budget? Think about it for any industry, not just IT. Anything in which work is performed experiences this problem.
Customer: "How much is it going to cost?"
Seller: "I won't know until I begin doing the work. How much are you expecting to spend?"
Customer: "I won't know until I know how much it should cost."
These two can keep going at it for hours in this circle, but the question boils down to one of estimation vs. budget. The problem is directly related to McConnell's Cone of Uncertainty. Before I begin the work, whether it is building a computer system or installing pipes, at the very beginning of the project, there are so many things that can go wrong, I have no idea how much something should cost. In the 'Cone' graphic, it is a factor of .25 to 4 times. In PMI-speak they would probably point to a Rough Order of Magnitude (ROM) estimate, which is supposed to -50% to +100%. This is all well and good, but the first question is where do I get that starting number?
The initial estimate/ budget number is extrememly important because this number, which is based on practically nothing, sets peoples' expectations about the project. I know, that isn't really fair. We shouldn't allow expectations to be set unless we have a number based on knowledge. But that is the reality. I have a couple tricks that I use to try to get around this problem. First, I don't tell anyone a number. I will say, "When we have an estimate I will be sure to let you know." That is true and safe, but it only works for a short time. The next thing I do is try to characterize the project in terms of magnitude. I will say that a project is "Big, Average or Small." This helps people to put some boundaries around the work and buys a little more time. This time that we're buying must be used wisely. You need to gather more information about the project. I recommend starting with Enterprise Architecture (EA). If your project is truly unique or new to the organization, EA should be able to tell you that. If it is not new, they should point you in the right direction for where this work has occurred elsewhere and you need to leverage that information from that previous work.
Even then, once you have knowledge upon which to base an estimate, your estimate is very likely still a best case scenario. You need to account for the risk of the project. So, let's say we performed our estimate to develop a system and it came to $100,000. That $100K is acceptable if everything goes well. How many projects are you aware of in which everything goes well? That just doesn't happen (see my previous article on the Perfect Project). So what you need to do now is identify the risks that your project could encounter. 'The business isn't clear with their requirements, I need additional integration work on the hardware platform, Critical people retire or leave the agency.' This process of risk identification must occur to identify the landscape of risks that might be felt on your project. Then these risks must be analyzed to identify the magnitude of impact if they are realized and the liklihood of them occurring. Each of these are numbers, the former in dollars and the latter as a percentage. Take the cost of the project and add the relative risks to it. So on a $100K project, I might have a risk-adjusted estimate that points me to $140K.
This risk-adjusted estimate is the starting point in terms of numbers. But until we get detailed requirements and design. Thus, I would take this $140K estimate and tell people that my ROM is $70K to $280K. I would never communicate an exact or specific number, rather only identify the range. And if someone forces you into a situation in which you need to identify a specific number, then it is $280K because that is the threshhold of resources that you may need to have available for the project. There is another stinky part on this. In the federal sector, if you don't need those funds, your project comes in at $138K, you need to kick that money back as early as possible so that they may be allocated to another project or risk sending them back to Treasury.
What we are doing during this time is to flatten out that cone of uncertainty to an estimate that fits the organizational structure. Since I'm in the government, generally, 10% is the allowable +/- for cost management (Earned Value). So, once I get my estimate into that neighborhood where I can manage to a 10% variance, I feel comfortable working to award a contract.
So what comes first? The estimate should drive the budget. But it never actually works out that way. Instead, the project selection process allows the budget to identify projects that could be performed within the budgetary constraints. All projects that are higher than the available funds in the budget are either struck or broken down into smaller components that could be performed peacemeal.
No comments:
Post a Comment