In the IT Project Blog article “Creating a Project Schedule”, we opened with a discussion of how difficult it is to estimate the difficulty and length of time it will take to complete an IT project before you have developed an intimate knowledge of the tool being developed or of the exact business needs before they are fleshed out. To help put some framework around how to go about developing an accurate schedule and project plan with or without such knowledge, we’ll introduce three different methods for schedule estimation:
- High-level feasibility analysis
- Top-down estimating
- Bottom-up estimating
We will cover the first two in this article.
1. High-Level Feasibility Analysis
The key to conducting a feasibility analysis is to understand that project scheduling, budgeting, and resource estimating is a continuous and iterative process. While it would be nice to be all-knowing from the project’s kickoff, that’s just not realistic. Instead, use the knowledge you do have to walk through these three steps to help generate high-level estimates despite limitations:
- First, document general high-level project requirements and overall business process needs.
- Second, identify potential solutions (think ideas, not technical resolutions) to high-level needs.
- Finally, investigate any potential constraints that may affect project execution.
Deliberately stepping through all three of these components, especially investigating constraints, to the feasibility analysis will enable you as a project manager to identify necessary start and end points. These scheduling estimates for your project and its resources can be dictated by other organization limitations. This makes estimating without low-level details more straightforward. Be sure to double-check that your estimates for fulfilling the project's high-level business needs are practical by consulting your PMO, other project managers in your department, or another subject matter expert.
2. Top-Down Estimating
The top-down method is also best applied during the project’s initiation or planning phases, when rough quotes are needed for charters, return on investment reports, and project proposals. Like the high-level analysis, this technique is also quick, but still generates estimates that the business and the project team can be confident in. This confidence is achievable even if you have limited details about project requirements. How? Here are two ways to make estimations with limited details about your current project:
- Consult Your Organization’s Project Archives Here is where maintaining a company-wide lessons learned database really pays off. Finding a past project from which you can draw similarities – the characteristics of the business need, the type of application development or enhancement, and so on – can be the starting point for estimating your current project’s schedule. Review actual budget hours for those projects and apply them to yours where there are similarities in effort. Finding a similar project gives you a good starting point for determining the effort required for your own.
- Start a Work Breakdown Structure Notice the keyword: “Start”. The traditional purpose of creating a WBS is to break a project’s work efforts into small discrete task packages, as small as you can, in order to create the most accurate work estimate possible. Well, in this case, the assumption is that you do not know the detailed work efforts needed. So, start by creating a partial WBS, only breaking down your deliverables to the first few high levels. After doing so, use a best guess (or the best guess of a team technical expert) to estimate the work required.
Both the High-level Feasibility Analysis and Top-Down Estimating are good techniques to be used during project initiation when very little is known about exact project requirements. However, since we’ve determined that estimating is an iterative process, how can you refine your initial approximations once you do know scope details? Bottom-Up Estimating is a perfect way to do so and will be discussed in more detail in the next IT Project Blog article.
Which method do you use? Which do you feel gets the most accurate results?