PPM and Project Estimation - Part II

By Jeff Monteforte

(Back to article)

Last month (see sidebar) I wrote that performing project estimates is a discipline required in a project portfolio management (PPM) practice. As I discussed, there are four distinct project estimates required as a project progresses though the project lifecycle.

The project phases and the associated estimates are follows:

  • Screening/Initial investigation – requires an order of magnitude estimate.
  • Business case – requires a top-down, budgetary estimate.
  • Functional design – requires a bottom-up functional estimate.
  • Technical design – requires a detailed bottom-up implementation estimate.

    Lastly, I indicated that the first two estimates, order of magnitude and budgetary, are owned and integrated into the PPM process, while the functional and implementation estimates are owned by PMO and project management practices.

    This month, I want to go in-depth regarding the PPM-related estimates that occur during project screening and business case analysis activities. Specifically, who performs the estimates and how they are used.

    These two estimates are the most critical to project success, despite the fact that they are easily the most inaccurate and high-level of the estimates produced. This may seem like a contradiction, but it is the cost estimates provided to your executives during the project screening and business case analysis phases that set the expectations and tone for the entire project.

    Paralysis by Analysis

    Moreover, while these up-front estimates are high-level and have the largest margin of error, they typically are the most difficult for IT personnel to calculate.

    Most IT professionals are used to providing an estimate during the functional and technical design phases when there is significant detail about the solution. During these phases and estimates an IT estimator literally knows how many database tables, reports, online screens, and programs will be developed. They have a sense of comfort in their estimates because they have tangible and discrete items that they can count and individually evaluate.

    In contrast, the screening and business case estimates are produced with a significantly different level of information.

    During screening you typically have to produce a cost estimate for the entire solution and the only detail you have to work with is a two-paragraph description explaining the business objective trying to be accomplished. Because of this, the majority of your IT staff will not be able perform this level of project estimating because their need for detailed design information just does not exist.

    I’ve discovered over the years that select individuals, who are comfortable executing in “grey areas,” with a unique combination of skills is required to produce such estimates. These individuals typically have hands-on software development experience in their backgrounds, but are naturally more capable in soft skill areas, such as communication, interpersonal relationship building, and business system analysis.

  • Many organizations establish the IT relationship manager role to address this area of need. (For more information on the IT Relationship Manager role and other roles required for a PPM practice refer to my previous article Succeeding with PPM Requires Follow Through.

    Dedicated Estimators

    Performed properly, estimation is a quick judgment call conducted by confident, experienced staff, who are familiar with the expected technologies involved and the business needs associated with the request.

    Initial estimates should be performed by a small number of people in a very short time frame. Refined estimates will generally require additional staff (usually the assigned project team) and a longer time frame.

    Staff who perform estimating need to be confident, experienced individuals familiar with the application(s) to be modified; the technologies most likely to be used to address the solution; the requirements of the business; the intention behind generating an estimate; and the tools used to develop an estimate.

    In order to reduce the number of people required to perform an estimate, staff capable of estimating more than one role within a project lifecycle should be selected. Doing so will reduce the impact to the overall IT organization by interrupting the work load of less people; should make scheduling meetings easier and most likely timelier as less staff are required; and should result in a shorter hourly duration for the delivery of an estimate.

    If the staff selected is chosen from a senior-level pool of IT personnel, this can be accomplished without negatively affecting the quality of the estimate.

    The Screening Estimate

    The screening of a project idea is essential in establishing an efficient PPM practice. All new project requests get funneled through a single process which first applies an order of magnitude estimate to roughly size the amount of work and capital spending anticipated in completing the project. This “cost-sizing” estimate is initially used to determine which remaining PPM evaluation steps to use in assessing the project.

    As I discussed before, not all project ideas should go through the entire PPM process. That process, by design, should only be for larger projects requiring review by the IT Investment Council, which is comprised of a company’s senior management.

    If a project’s estimated cost-sizing falls below the threshold you’ve set for defining a large project, then that project should be managed by a specifically designed small projects process. For more insight into this topic refer to one of my previous articles Good Things Come in Small Packages.

    The Business Case Estimate

    The business case analysis (BCA) establishes sound business reasons for proceeding with an IT investment or project by providing insight into how the IT project supports the business needs and strategic goals of your company.

    While the purpose of an IT project business case is to evaluate and potentially justify the IT investment from all relevant perspective, the heart of the business case analysis provides financial justification for an investment decision (see related article, Making the IT Project Business Case).

    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:

  • Existing systems that will be impacted.
  • The development language likely to be utilized.
  • The platform (e.g., hardware/network configuration) applicable to your project.
  • IT environmental tools that will be utilized, such as data-driven testing tools.
  • Project complexities and risks that may impact project completion.
  • 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 jmonteforte@exentialonline.com.