It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I've long given up looking for panaceas. Actually, I have always regarded estimating as a relatively simple task and have taken my queue from the construction industry who has had to frequently produce reliable estimates over the years. As such, there are basically three variables involved:
* Methodology - defines the stages of work by which projects are completed, from beginning to end. Some portions of the project will be executed serially, others in parallel, either way, each stage should define precisely what work has to be accomplished to the types of components involved. Typically, components are identified, designed, tested, and installed in moderation which is commonly referred to as "stepwise refinement" (going from the general to the specific) as prescribed by the methodology.
* The components involved - in the construction field, it is the wood, stone, glass, nails, rivets, steel beams, etc. to be used to construct a building. In the I.T. field it is the data elements, records, files, input, outputs, programs, business processes, etc. The methodology dictates the sequence by which the components are implemented. A component assembled at the wrong time and place will likely prove disastrous, which is why the methodology is so important. To make this work, it is necessary to produce a rough design of the object in question. For construction, it would mean a complete rough design of a building, aka, "artist rendering." In I.T., it would mean a complete rough design of a system or program. Only after the rough design has been completed can a listing of the components be identified.
Another consideration is the state of the components, how many are new versus how many can be reused from other projects. To illustrate, if there are already preexisting nuts and bolts to satisfy the product, they certainly can be reused; if not, new nuts and bolts have to be designed. Within a systems development project, if a data element such as "Customer Number" has already been invented and implemented, there is no point in introducing a redundant component; developers should simply reuse the existing data element. Such reusability of components not only expedites development time, but promotes integration of different products.
"Bill of Material Processors" (BOMP) are commonly used to keep track of components, be it in the construction field or I.T.
* The skill of the people charged with executing the project. A novice worker will obviously take longer to perform a given task than an experienced expert. This is also why it is preferable to have the people charged with the work participate in the estimating process as it becomes a reflection of their commitment. In a situation where project personnel are unknown, the Project Manager can still render an estimate based on "averages" defining the amount of time necessary to build a component for a given task. As projects are executed, the actual time expended to complete a component for a specific task should be captured so such averages can be refined based on historical data.
This approach to estimating is universally applicable to any product development based project. It is based on the recognition that most estimating errors are errors of omission, not commission. It is the forgotten or overlooked components that lead to most estimating errors. Again, this is why the rough design is so vital as it will overcome the problem of omissions. As in any construction project, a rough architectural design is required to effectively estimate the project to build it. The same is true in I.T. projects where the objective is to build a new system. To do so, a complete rough design of the system must first be prepared to effectively estimate the remainder of the project.
This approach also distinguishes the use of time as either "direct" or "indirect." Whereas direct time represents whole work, indirect time represents interferences detracting from project execution. Estimates should be expressed in direct time, not indirect time, as we want to know the amount of pure effort needed to complete a component and task. This approach to time also implies estimating and scheduling are separate activities. Whereas, direct time is used to express estimates, indirect time is used to calculate schedules. For example, if an estimate for a project task is ten direct hours, and a worker is only able to spend four direct hours of work each day (with another four indirect hours spent elsewhere during the day), the task should be completed in 2.5 working days. Separating time into "direct" and "indirect" greatly improves precision in both estimates and schedules.
Here is a typical scenario for estimating a product related project, be it construction, I.T., manufacturing related, or whatever:
1. Specify and analyze requirements.
2. Prepare a rough design of a product to satisfy the requirements.
3. Prepare an itemized listing of components to be used in the product, aka, "Bill of Materials," identifying which are new and which can be reused.
4. Based on the materials, define the remaining stages of work to develop the product (the methodology).
5. Estimate the amount of time necessary to complete the various stages. If project personnel are known, have them participate in the estimating process.
6. After the estimate has been defined, calculate the project schedule based on the methodology and use of time (direct vs. indirect).
7. Review with the client for approval.
This approach is certainly not new and has been used for many years in a variety of industries. Ultimately it represents a complete mental execution of the project in order to determine costs. This is essentially no different than what a professional golfer does before swinging his club on a drive; he visualizes everything from how he is to swing the club, the follow through, to where he wants the ball to land, and the ensuing strokes necessary to complete the hole. Preparing a rough design is no different. It is thinking the project through to completion by considering all of the components needed to satisfy the product. Will it be perfect? No, but it will be more accurate than making wild guesses based on some wild pseudo-scientific calculation. The only drawback to it though is it requires some hard work in upfront planning and design; it is certainly not a panacea, but then again, there never has been any magic in estimating that I know of.
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author:Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]
Copyright © 2011 by Tim Bryce. All rights reserved.