Along with business benefits, the BCA must quantify expected costs and the assumptions upon which those estimated costs are based, usually with scenarios for the range of costs.
The scenarios are based on an alternatives analysis for the possible solutions that may be pursued in completing the planned project. The alternatives analysis may be as simple as a buy-versus-build comparison, or may compare several scenarios against one another simultaneously.
High-level Estimates
Whether the responsibility of providing high-level estimates falls on the shoulders of a relationship manager, a team of dedicated project estimators or a new IT person for each new project, the approach I coach clients to use is called comparative analysis. The name implies the details behind the approach.
Comparative estimating allows you to assemble estimating elements or estimating assumptions quickly and to the satisfaction of your detail-oriented IT estimating staff. Comparative estimating is a technique based on comparing your planned project with a number of previous projects that your IT department has completed, which have similar attributes to the planned project.
Specifically, comparison-based estimation defines a set of attributes for the project to be estimated, selects previously implemented projects with similar attributes then using the median values for effort, duration, etc. from the selected group of projects produces an estimate for project effort and duration.
Defining the set of attributes to use in the comparison should fit the culture and discipline level of your IT organization but, at a minimum, should include the identification of:
Most organizations (large and small) do not maintain a repository of completed projects, organized by key attributes with actual time efforts associated to them. Because of this, I stress the use of an IT relationship manager and a dedicated high-level project estimating team. Together, they provide a storehouse of experience and knowledge of previous projects that can be tapped.
Likewise, these highly-experienced IT professionals can supply a median estimate for effort for each of the planned project’s attributes. (Some people call this intuition when you’re working with such experienced folks.)
Whether the estimates are captured by project role (i.e., business systems analyst, DBA, .NET developer, etc.), by project phase (i.e., planning, design, development, testing, etc.), or by some other categorization that is specific to your company, the result is your estimate.
To ensure your estimates are as close to an “apples-to-apples” comparison you should develop an estimating template to guide the estimate through all the components and criteria appropriately.
Where possible, roles that can be estimated based upon a given percentage (instead of providing a custom, individual estimate) should be handled without the need for assigning a member to the estimating team. For example, a project manager role can be allocated at a 15% level for a small project, and a 20% level for a large project. Similarly, a technical writer role may add 0% to a small project and 5% to a large project.
Lastly, when an estimate is being given, the estimating staff needs to estimate the amount of time it would take for the average employee to perform the task.
The critical time for any project estimation is at the screening and business case analysis phases, because these estimates set the funding expectations for the entire project. If the project estimate at this time is way out of “whack”, then any requests for extensions of funding may be extremely difficult to justify and most likely rejected by management.
The challenge of up-front, high-level project estimation is getting the costs of resources and duration accurate enough to provide a fairly clear picture, without having much detailed information about the project available.
The more consistency you can bring to the project estimation process in your PPM practice the better your estimations will become over time. Your should create a standardized estimation procedure that all involved can and do buy into. That way people can’t argue about the outputs, only the inputs, and their effort is spent productively understanding the scope and cost drivers for the project.
One final thought, look up the word “estimate” in the dictionary. You may find it useful in a meeting.
Jeff Monteforte is president of Exential, a Cleveland, OH.-based information strategy consulting firm, which specializes in IT governance, information security and business intelligence solutions. He can be reached at [email protected].