Estimation Basic Order of magnitude estimate and WBS

This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the fast & optimal estimate as per time & information availability we can provide.

Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks. We can have a simple standard table to choose from at departmental level. Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.

Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on. These weighing factors will differ based on the team and project and should be reviewed after the project to help get better values the next time. Add together all these values for each task to get an estimate of time and resources required.

Size	Complexity
	Low	Medium	High
Small			1) Tune database
Medium
Large	1) Load data		1) Integrate with security system 2) Create data validation routines

Figure 1. A sample table used for doing an order of magnitude estimate.

Doing rough and fair estimates

These estimates can be done when you have a good idea of the tasks to be done and how to do them.

Those who will do the actual work are the best people to do these estimates. One then can add up all the estimates from different people to get the final estimates. Ensure you collect estimates on the three variables of time, people, and infrastructure/material needs.

Break down tasks to as detailed a level as possible or at least 2 levels. As mentioned previously, it can help to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task. Break tasks down to a granularity of eighty hours or less.

Conclusion, the preceding techniques can help one achieve better estimates. Review estimated needs versus actual needs after every project. Identify what was correct and what was wrong. This will help you improve the next time. As with many other activities, experience will help you get better!

Now let’s look at the other best practice followed in majority of IT companies, The work breakdown structure (WBS) is an effective tool in managing programs and projects. It assists both developers and contractors in fulfilling management responsibilities. In accordance with good IT organizations management of major system programs and projects, a WBS is mandatory for major system acquisitions and major projects, and will be used for other projects when practical. A WBS is required when performance measurement is applied to a contract. The purpose of WBS is to support the initial project estimation till completion of program and project objectives within budget and schedule constraints. This can be used for various work efforts including research, development, construction, test and evaluation, and operations. The products of these work efforts may be hardware, software, data, or service elements (alone or in combination).

A WBS is developed by first identifying the system or project end item to be structured, and then successively subdividing it into increasingly detailed and manageable subsidiary work products or elements. Most of these elements are the direct result of work (e.g., assemblies, subassemblies, and components), while others are simply the aggregation of selected products into logical sets (e.g., buildings and utilities) for management control purposes. In either case, the subsidiary work product has its own set of goals and objectives which must be met in order for the project objectives to be met. Detailed tasks which must be performed to satisfy the subsidiary work product goals and objectives are then identified and defined for each work product or element on which work will be performed.

Completion of an element is both measurable and verifiable by persons (i.e., quality assurance persons) who are independent of those responsible for the element's completion. Because WBS element/product completion can be verified, a WBS provides a solid basis for technical, schedule and cost plans and status. No other structure (e.g., code of account, functional organization, budget and reporting, cost element) satisfactorily provides an equally solid basis for incremental project performance assessment.

It usually consists of three levels of products/elements with associated work definitions. The three upper levels of are defined below

• Level 1 is the entire program/project.
• Level 2 elements are the major product segments or subsections.
• Level 3 contains definable components, or subsets, of the level 2 elements.
• Level 3 can be further definable components, or subsets, of the level 3elements.
• So on & so forth

Now let’s create some rules / regulations for the WBS process implementation in sample IT organization. I have tried to be as generic as possible in this.

1. The WBS is prepared as early as project definition will permit.
2. A preliminary WBS is developed in initial phase to define the top levels of a WBS for the entire project (system) life cycle. Normally, this life cycle WBS will be in two parts: one part for the acquisition cycle of the system being acquired (Phases A through D), and one part for the operations and support phase (Phase E).
3. The WBS is to be compatible with the organization Wide standard Coding Structures defined in quality process as per the need & fitments
4. A revisit WBS is prepared by compiling the elements of the WBS(s) with the new additions or modifications as per the defined standards.
5. As design concepts change, the WBS is further refined and changed to reflect new systems and subsystem approaches.
6. When a project initiated , the WBS becomes formalized as the project outline, and all changes to it should be formally approved by the program managemt office.
7. The preliminary WBS, written by estimation group / project personnel, is developed through no more than the three highest levels of the proposed contract.
8. The preliminary WBS is developed from the basic elements of the sales WBS and expanded for use in the request for proposal (RFP), preparation of proposals, and the evaluation and selection process.
9. Normally, only the top three levels of the WBS will be specified in an RFP. The WBS is considered a preliminary WBS until it is finalized as a result of negotiation and incorporated formally into the contract.
10. When high risk items are located at low WBS levels, these items can be identified against the higher-level WBS element of which the high risk item is a part. It is not necessary or desirable to extend the WBS below the top three levels in order to identify the high risk item.
11. The periodic reviews are the basic need in Agile project execution methodology as the agility implies in changing the requirements & so the effort & cost plans in our daily executions.

As we can infer, a work breakdown structure defines all work to be performed for project completion. It is a product-oriented structure, not an organizational structure. To develop and maintain a WBS, you must have a clear understanding of the project's objectives and the end item(s) or end product(s) of the work to be performed. The WBS elements should represent identifiable work products (e.g., hardware, software, data or related service products). Because of its product orientation, a WBS provides the framework to plan, track and assess the project's technical, schedule and cost performance.

A preliminary WBS is established as soon as program management believes the project has reached a stage of definition where it is feasible. It is used to assist in the preparation of the program / project initiation documents and the project plan. As now the preliminary project development process is an iterative process. During its early phases the preliminary WBS may be revised as necessary. Once the project is established in sufficient depth,

procurements may be planned by using selected WBS elements to develop preliminary schedule diagrams. Preliminary WBSs are incorporated into the RFPs, subsequent proposals, and eventually finalized in the executed contract(s) based on negotiations.

Feel free to reach me at ravindrapande@gmail.com to share thoughts & suggestions.