Implementing Bottom-Up Cost Estimates

IT project managers love estimates; accountants don’t. One of the toughest parts of your job as an IT project manager is to accurately predict the expenses your project will generate. As an IT professional, you know this is true because there is so much to IT that fluctuates: RAM, new versions of software, the size of hard drives, the speed of processors, and just about any other facet of the IT world. Intel’s Gordon Moore is known for “Moore’s Law,” where he predicts processing power doubles every 18 months. This law, which is generally accepted as true, has spread to all areas of technology. Everything becomes more efficient with technological advances.

The old adage that time is money is never more true than when it comes to information technology. While the speed and price of hardware and software may fluctuate, one of the largest expenses in an IT project is time. Why? Basically, if you, or your team, are not adequately prepared to implement the technology, the estimated time to install and roll out a plan can double or even triple. A project manager must take into account the learning curve to implement and manage the new technology.

A project manager cannot always know her team’s ability to implement a given technology. For example, a project manager assigns Jim to the development of an application. Jim does have a proven track record with developing applications in Visual Basic; however, this application will have hooks into a SQL database. If Jim does not have a clear understanding of the procedures to communicate with the SQL database, his reported estimated time might well be lower than the actual time used to create the application. Worse still, Jim doesn’t understand SQL at all and needs additional weeks to ramp up on the technology to make his application design flesh in with the existing SQL database. Jim’s weeks of training may incur additional expenses from your project budget and delay other workers and tasks that require Jim to complete his portion of the project first.

The cost of team development needs to be included in your project budget, both from a training and learning curve perspective. In other words, if you have a QA tester that will be using new software for error detection, not only do you have to figure in the cost of training, but you also have to remember that productivity on that piece of testing software will be about 60 percent of capacity in week 1 versus 90+ percent capacity in week 10. If the project team lacks the skills to deliver, it must be trained. Lack of knowledge to do the project work guarantees project failure. It’s no great discovery that so much of the knowledge surrounding information technology is disposable, although it’s necessary for the imminent project. Consider all the old and discarded information you and your project team have learned about DOS, OS/2, and Microsoft’s products. At the time, the information was of incredible value; as technology changed, however, the information’s value waned. The value of the training and knowledge to complete the project is what’s important, not its value years from now.

Another fluctuating expense is hardware. Generally, hardware is at a fixed price and decreases in cost as newer, faster, better hardware becomes available. However, there are times when demand outweighs supply and the hardware costs increase. Also, as laptops, desktops, and servers drop in price, the demand for parts to manufacturers increases; this can cause hardware prices to remain steady, but the hardware itself to be significantly back-ordered. This, of course, throws your entire implementation plan askew.

To avoid these pitfalls, a project manager should implement bottom-up cost estimates. A bottom-up estimate does not mean you pour a shot of your favorite brew and yell, “Bottoms up!” Bottom-up cost estimating is the process of creating a detailed estimate for each work component (labor and materials) and accounting for each varying cost burden. As Figure 4-1 illustrates, a project can be divided into phases, and then each phase can be assigned a cost value.

Figure 4-1: A project divided into phases allows each phase to be assessed a cost value.

For example, an application development project can be divided into three phases. Within each phase, the work to complete the phase relies on time, software, and hardware. The project manager can assign each of these factors a monetary value to complete the total phase of the project.

In other words, the project manager is starting from the bottom of the project— the genesis—and working toward the project deliverables. Each component of the project has a monetary requirement assigned to it to ultimately predict the final cost. When you begin to create your budget, here are some issues to consider:

Divide your project into phases. By segmenting the entire project into phases, it’s easier to identify milestones and assign the amount of work and materials required to complete each phase. Once you break the project into phases, you’ll find assigning dollars to each phase is more manageable than assigning one lump sum to an entire project.
Address the integration phase. By prepping the production environment for the onset of the implementation, budgetary concerns can address downtime, lag, required work hours, and the time the project manager requires to oversee that the tasks are being completed to keep the project on schedule.

Consider the fully burdened workload required to complete each phase of the project. A fully burdened workload is the amount of work, in hours, required by the staff to complete each phase of the project. Part of the budget must include the man hours necessary to complete any given phase. Team members should have a dollar amount assigned to their work hours to predict the true expense of the implementation. (In some instances, it may be, unfortunately, beyond your control to predict the hourly rate of workers due to your company’s human resources department policy.) Additionally, when some work is outsourced, the hourly rate may include overhead, general and administrative expenses, a risk load factor, and a profit load. As a project manager, you should be aware of what ancillary, or additional costs, go into a true project cost.

Consider the costs for any specialized services. Will you be using subject matter experts? Will the project include training for the implementation team? Will the project include a pilot team of ordinary users? Any of these special services are easy to overlook when calculating a project’s budget, but they will come back to haunt you if you don’t plan for their expenses before the project begins..

Consider the costs for equipment. Of course, if you are purchasing new hardware, this is easy to account for. However, consider the value of leasing versus purchasing new hardware. Consider the impact of equipment dedicated to the project on any production machines that may be affected by the project’s implementation—such as test servers, workstations reserved for testing, application development machines, the percentage of processor utilization, memory usage, and bandwidth impact.

Consider production costs. Any project will have fringe costs such as photocopying expenses, creating rollout manuals and user manuals, designing and developing web pages, and development.

Consider quality requirements. The project needs to account for the level of testing that needs to be done. How much regression testing, integration testing, and so forth, should be included to meet the customer’s quality standards?

Consider risk. Just as with the budget, risks are vague in the initial stages of a project. As the planning evolves, so does information on risks and risk management. You will need money for rework, risk mitigation, schedule delays, and workarounds.

Consider reserve amounts. All projects run into challenges. Smart project managers plan for the unknown “unknowns,” and for uncertainty. One way to plan for those things we can’t know for certain is to keep a reserve amount to handle unforeseen circumstances. This is like the same idea as the personal savings account we keep for emergencies, only this reserve amount is for our project. The amount may, or may not be under your control, but it is useful to understand the concept, and how to plan for it.

Once you’ve taken into consideration these different aspects of your project implementation, you’re ready to begin calculating expenses. After you’ve broken your project plan down into phases, create an evolution of expenses for each phase. For example, in phase 1 of a project, consider the expenses required to complete this stage of the project:

Hardware to be purchased
Software to be purchased
Licensing issues
Consultants
Internal developers’ time
Percentage of time required by each team member to complete this phase of the project
Risk and reserve funds
Other expenses pertinent to your project

In the first phase of the project, you can complete the expenses required and then use the same template to move on to the second phase, the third phase, and so on, to create a table of expenses for each phase of the project.

Allowance for Change

When using bottom-up cost estimates, you need to calculate some allowance for change. When calculating time and costs for expenses, a project manager should create an average estimate for each phase of the project by factoring best- and worst-case scenarios into components that may fluctuate on price. Here’s an example of an implementation phase for a new server-based application:

Component	Best Case	Worst Case	Average
New server (fixed price)			$7500
Application software (fixed price)			$2500
Application license (fixed price)			$3500
Development	40 hours	100 hours	70 hours
Testing and resolution	40 hours	120 hours	80 hours
Rollout to users	40 hours	80 hours	60 hours
Documentation	$4000	$6000	$5000
Training	120 hours	240 hours	180 hours

By including the best- and worst-case scenarios into your bottom-up cost estimates, you are factoring in an allowance up to the maximum amount, but predicting an average amount. Figure 4-2 depicts a simple predicted average for a project’s expense. Most expenses within your project can follow this formula.

Figure 4-2: Worst- and best-case scenarios allow for average amount predictions.

Some elements of your estimates will not come close to the worst-case scenario, or even the average cost. Others will no doubt reach the worst-case scenario and perhaps even pass it. How do you determine the amount of time and the price value associated with each component? Here are factors that you should call upon to estimate your budget:

Prior experience If you’ve worked with similar projects in the past, you’ll call upon your experience to predict how similar phases of work will fit within the scope of this project.
Historical information Similar projects may have historical information that helps guide your current project’s budget. In addition, are there mentors or other project managers you can call on for advice? Ask others how long certain elements took when they implemented similar projects within the company or in their work history. Project team members may have experience with key areas of your plan, so their input is needed.

Fixed quotes Vendors should be able to offer a fixed quote or a not-to- exceed (NTE) price on a deliverable. Typically, a fixed quote is for a product rather than a service, and it is valid 30 days from the time of the quote.

Standard costs Your budget department may have preassigned “standard costs” for labor to do tasks such as programming lines of code, installing hardware, or adding a new server. The cost of these activities may be found in a company-wide charter of accounts that represent types of work and their associated costs. This preassignment of values helps you estimate labor costs for a project easily, and without having to justify each labor expense as a line item. Hours to perform the task still may be a point of contention.

We’ll talk more about time estimating in Chapter 5, but you should be keenly aware that time and money are interrelated. Time is money. In some organizations, the cost of the employee completing the work is not seen as a cost attributed to a project. In other organizations, however, the employee’s time is billed to the project’s customer. For example, an IT project to create a sales automation program may bill the sales department for the application developer’s time. While the cost of the developer may not reflect the hourly rate of the employee, dollars are shifted from the sales department’s budget to the IT department to account for the developer’s time.

Tolerance for Budget Variance

As the cost of hardware, software, and services can fluctuate, project managers and management must agree on a tolerance level for the project’s budget to be plus or minus a percentage of the predicted costs. Depending on your project and its budget, this may be only 1 to 2 percent or as large as 10 percent. Any variance in your project’s budget can be unsettling, as it may reflect a lack of planning. Typically, management is more eager to deal with budgets under the predicted total costs than ones that are over. Beware: projects that finish significantly under budget are not reasons to celebrate; it often indicates a lack of proper planning for project costs.

To circumvent any disagreements, management and the project manager must agree on the range of variance for your project. Don’t use the range of variance as an additional cushion for your purchases—you may need that percentage you spend now later in the project. In some companies, a variance in the budget can reflect the monetary rewards assigned to a project’s success.