This chapter is about money. Have you ever noticed how people bristle when that word is mentioned? In some circles, it’s not money; it’s finances, working capital, currency, or funds. Whatever you want to call it, it’s a large part of what you need to get your project done. Your project will need a budget to create the product or service your project customer expects. The material resources you’ll need, such as software and hardware, cost money. The labor resources you’ll need; the developers’, database experts’, and network engineers’ time; as well as the brute force required to install the hardware and software also cost money.

Your project needs a budget to determine just how much money, er, capital, needs to be allotted, and when it needs to be available, so you can reach the project goal. Your project needs a plan to create estimates and predict the total cost of the project. Your project’s budget needs proof of why it will cost the amount you say it will, input from vendors, quotes from suppliers, and estimates on work hours committed to the project. And your project needs a time-phased budget that ties the resources needed with the project schedule.

You’ll need to estimate the project costs in order to get to the project budget. A budget may seem to be a necessary evil required by any project manager to get a project off the ground and into implementation. In reality, a budget is needed so that the project stakeholders can see how much it will cost to create the deliverable they desire. In addition, a budget is needed to confirm that the project manager truly knows what it is they need to deliver. A dreamy project goal is snapped into reality when management wants to hold you accountable for the cost of the project deliverables. With that in mind, let’s get started.

Budget Basics

You need a budget to control and document project expenses—before the project work begins. When you are creating a feasibility plan, you’ll no doubt include facts on the cost of the project and any ROI for the project. Now, once the project has been approved, or approved based on the financial obligations, you have to do a touch more research. Any bean counter in your organization wants to know what, exactly, your project will cost. As any project manager who has worked on IT implementations will tell you, “It’s not as easy as it looks.”

You also need a budget to get your arms around the scope of the project and what you can afford to include in your implementation. There will be instances when your budget won’t be approved and you’ll have to cut the “nice-to-have” features from the project scope or settle for fewer resources, trade-offs, and compromises to complete the project. In other scenarios, the project may have to be delayed until funds are available to continue. The worst-case scenario, of course, is that the project is approved but the funds to support the project are nonexistent.

A budget will serve as a financial guide to where the project is headed. Project managers who do their homework will have a clear vision of what the deliverables of the project will be and what it takes to reach those deliverables. Much of the information covered in this chapter is really defined in your project cost management plan. The project cost management plan, which I’ll discuss in detail in Chapter 6, defines six things:

•   Control limits  These define the acceptable range of variances for the project costs for phases, vendors, and the entire execution.

•   Assignment of costs  The project manager needs to identify where the monies in the project will be spent and link the costs to the project deliverables.

•   Chart of accounts  This is a predefined table of costs and categories for project or organization use for commonly completed activities. For example, a programmer’s time is $150 per hour regardless of which programmer is assigned to the project. Categories can include labor, supplies, cost of materials, and other known expenditures.

•   Project budget  This defines the process for creating, spending, and controlling the project budget.

•   Cost estimates  I’ll discuss several approaches to cost estimates in this chapter.

•   Cost baseline  This is the agreed-upon level of costs tied to phases, milestones, and the project. As the project moves toward completion, the costs to reach certain milestones in execution should synch with the predicted costs of the cost baseline.

Phased Gate Estimating

As you begin to create a budget, you need to come up with a plan of attack. There are numerous ways to create a budget, some better than others. One approach IT project managers have a tendency to use is to write down a list of all the products that the organization needs to purchase to complete the project and add up the cost for each. At first glance, this seems like a viable solution; however, it opens the door for potentially overlooking important details, lack of true planning, and error. A better approach is to divide your project into phases and extract cost estimates for each phase of the project. This approach, called phased gate estimating, is ideal for large projects and describes the phases of the project, such as Ideation, Requirement gathering, Design, Development, Testing, and Deployment.

Phased gate estimating allows project managers to forecast the exact expenses for the pending phase of a project and provide more general estimates for phases downstream. Phased gate estimating is linked to step funding, where the project is funded in increments based on phases instead of the entire project being funded at once. Figure 5-1 is a depiction of phased gate estimating and how it’s linked to step funding.

Figure 5-1  Phased gate estimates provide an accurate estimate for the near-time deliverables.

Phased gate estimating helps the project team get to work on immediate deliverables as they work toward milestones at the end of each phase. The immediate actions of a project should be foreseeable, as opposed to actions that will happen way off in the future. For example, you probably know what you’re doing this weekend, but you don’t know your plans for the weekend a year from now. Because IT changes so rapidly, accurate estimates are available for actions in the present and less so for actions in the future.

As discussed in Chapter 4, a key factor in any predictive project is the work breakdown structure, a deliverables-oriented decomposition of the project. From these lists of deliverables, the project manager can derive the activities required to deliver each component of the project. The major deliverables of the project, often associated with project milestones, are ideal for identifying the ends of phases within a project. For example, a project to create a new application will have some logical, visible milestones between its beginning and completion. A project manager using phased gate estimating can predict the cost of the project through the next foreseeable milestone.

Adaptive projects receive their budget from a steering committee or customer working with the product owner to predict the likely cost of the project. In an adaptive project, the budget is fixed and the scope may be trimmed based on performance. Recall that in adaptive project management, the items with the most business value are done first, and the items of lesser value are at the bottom of the product backlog. As the team completes the prioritized work, the budget is consumed; should the project run out of money before all of the items in the backlog are completed, it’s not tragic, as the most important items are done. From there, additional projects may be launched to finish the product backlog items, the project may be considered done, or more funds may go into the current project to finalize the backlogged items.

When a project calls for phased gate estimating, the WBS will reflect the approach as well. A software development project has some obvious phases, just as a hardware rollout project will. A WBS in these instances can reflect the deliverables within the immediate phase with a nod to downstream phases that will come later in the project.

Determine the Estimate Type

As a project manager, you need to be familiar with three different categories of estimates. These estimates will dictate how much detail the project manager, product owner, or business analyst will need to provide in order to create an accurate estimate.

•   Rough order of magnitude  This estimate is “rough” and is used during the initiating processes and in top-down estimates. This estimate is based on high-level requirements. The range of variance for the estimate can be −25 percent to +75 percent.

•   Budget estimate  This estimate is also somewhat broad and is used early in the planning processes and also in top-down estimates, usually when you have an approved project scope. The range of variance for the estimate can be −10 percent to +25 percent.

•   Definitive estimate  This estimate is one of the most accurate. It is used late in the planning processes and is associated with bottom-up estimates (discussed next). The range of variance for the estimate can be −5 percent to +10 percent.

The percentages associated with these estimate types are pretty standard—but it’s not unusual for an organization to develop a range of variances specific to that organization. For example, an IT integrator who performs the same type of projects for customers over and over will have a good understanding of what it takes financially to complete a typical project. The more familiar you are with your project work, the easier it becomes to predict project costs. When you’re faced with a project scope that’s significantly different from your experience, the range of variance can, and should, increase to reflect the unknowns in the project.

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 in 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. And don’t forget the cost of labor: it takes people to complete the project work, and there’s often a ramp-up time as people join the project, learn the goals, and then really begin producing results. Everything becomes more efficient with technological advances.

The old adage “time is money” is never more true than when it comes to information technology. While the speed and prices 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. And there’s the concept of knowledge work—the work that happens in your brain. It takes time to figure things out when doing software development, technical design, or other brain-centric work. You can’t really predict how long it’ll take someone to think their way to a solution.

Consider a project from management’s perspective: time spent on a project is time away from core operations. The longer it takes to complete project work, the more the project costs in both labor on the unique endeavor and time lost on operational work that drives company income. Also consider the disruption that project work can have on the organization and how the disruption can take time away from operational work. It’s imperative for a project manager to consider not just the project costs but also the indirect costs the project can have on the organization.

A project manager cannot always know their team’s ability to implement a given technology. For example, suppose a project manager assigns Jacob to the development of an application. Jacob does have a proven track record with developing applications in Visual Basic; however, this application will have hooks into a SQL database. If Jacob 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 he’ll use to create the application. Worse still, if Jacob doesn’t understand SQL at all, he’ll need additional weeks to ramp up on the technology to make his application design flesh in with the existing SQL database. Jacob’s weeks of training may incur additional expenses from your project budget and delay other workers and tasks that require Jacob to complete his portion of the project first.

The cost of team development needs to be included in your project budget, both from training and learning-curve perspectives. In other words, if you have a QA tester who will be using new software for error detection, not only do you have to figure in the cost of training that person, but you also have to remember that productivity on that piece of testing software will be about 60 percent of capacity in week one versus 90+ percent of capacity in week ten. If the project team lacks the skills to deliver, they 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 old versions of Linux, Windows 7, and even outdated hardware. 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 set 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 from manufacturers increases; this can cause hardware prices to remain steady while the hardware itself is significantly back-ordered. This, of course, throws your entire implementation plan askew. In addition, consider the unpredictable impact of supply chain issues, such as computer processors, in the past few years.

To avoid these pitfalls, a project manager should implement bottom-up cost estimates in a predictive project. 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. The bottom-up cost estimates are based on the WBS and the WBS dictionary, as these documents define each element of the project deliverables. As Figure 5-2 illustrates, a project can be divided into phases, and then each phase can be assigned a cost value based on the work packages within the phase.

Figure 5-2  A WBS can help estimate costs based on project phases.

For example, an application development project can be divided into three phases in the WBS. 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 in a predictive project, here are some issues to consider:

•   Create the WBS and the WBS dictionary. These documents are needed to create the cost estimate for the project, as they show what deliverables are created in the project. You’ll need the work packages to determine the resources that you’ll need to create the deliverables. Resources include people, materials, and facilities.

•   Divide your project into phases. By segmenting the entire project into phases, you’ll find it easier to identify milestones and assign the amount of work and materials required to complete each phase. Once you break the project into phases, assigning dollars to each phase will be 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 work 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 because of your organization’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? Will you use testing services, security audits, or other firms to complete the project? Any of these special services are easy to overlook when you’re 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 and 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 expenses for photocopying, 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 required. How much regression testing, integration testing, and so forth should be included to meet the customer’s quality standards?

You’ll also plan for any rework and testing as a result of quality control activities. When you or your team finds an error in the product, you’ll need time, and likely money, to fix the problem before the product is released to production.

•   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. I’ll talk more about risk planning in Chapter 6.

•   Consider reserve amounts. All projects run into challenges. Smart project managers plan for the 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 similar to the personal savings account we keep for emergencies, except 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 considered these different aspects of your project implementation, you’re ready to begin calculating expenses. After you’ve broken down your project plan into phases, create an evolution of expenses for each phase. For example, in phase one of a project, consider the expenses required to complete this stage:

•   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 can create an average estimate for each phase of the project by factoring best- and worst-case scenarios into components that may fluctuate on price. An average estimate is called a three-point, or triangular, estimate. This approach uses the average of pessimistic, most likely, and optimistic estimates. Here’s an example of an implementation phase for a new server-based application:

By including the best- and worst-case scenarios in your bottom-up cost estimates, you are factoring in an allowance up to the maximum amount, but predicting an average amount. Figure 5-3 depicts a simple predicted average for a project’s expense. Most expenses within your project can follow this formula. This estimating approach is called the three-point estimate because you’re using the worst-case, most likely, and optimistic approaches to create an average cost for the project expense. You can also use this approach in time estimating.

Figure 5-3  A three-point estimate creates an average for cost or time estimates.

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, 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 organization 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 is valid 30 days from the time of the quote.

•   Standard costs  Your budget department may have preassigned standard costs for labor to perform tasks such as programming lines of code, installing hardware, or adding new servers. The cost of these activities may be found in organization-wide charts of accounts that represent types of work and their associated costs. A chart of accounts includes predetermined fees for standard work your organization does, regardless of materials or labor. For example, a network drop could have a chart of accounts fee of $175 per drop, regardless of the time or materials used in the network drop. This preassignment of values helps you easily estimate costs for a project, without having to justify each deliverable as a line item.

We’ll talk more about time estimating in Chapter 6, 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 those that are over.

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

Creating a PERT Estimate

While finding the best- and worst-case scenarios is a quick and easy way to arrive at an average cost, you can use a slightly more sophisticated method called the Program Evaluation and Review Technique, also known as PERT. PERT is ideal for time and cost estimates to complete activities. PERT uses a weighted average to predict how long the activity may take. You’d say that as, “pessimistic plus the optimistic, plus four times the most likely, divided by six.” It’s divided by six because of one count for pessimistic, one count for optimistic, and four counts for most likely. The following table uses the same values as the three-point estimate but with PERT’s formula instead (this formula is also included on the Estimating Worksheet that is part of this book’s online resources; see Appendix C):

Using Top-Down Estimating

Top-down estimating allows a project manager to take a very similar project’s budget, work some financial math magic, and arrive at a reasonable budget for the current project. Top-down estimates are often used by organizations that complete IT projects for other companies. Consider IT integrators who install servers, network cable, and network equipment. They’ll have similar projects they can refer to when predicting the cost of current projects.

Within an organization, IT project managers also have projects that are similar to other projects they’ve completed in the past. Consider a project to roll out a new operating system using a disk-imaging server. If the project manager has rolled out other operating systems in the past using the disk-imaging server, they’ll have a pretty good idea of how the current project will go. This historical information, also known as artifacts, on proven, completed applications allows the project manager to avoid spending time doing a bottom-up estimate; they can work from prior successful projects instead.

The problem with top-down estimates in the IT world, however, is that most IT projects have never been done before. Specifically, because IT changes so quickly and each environment is generally customized, top-down estimates are not as reliable or usable as bottom-up estimates.

Using Analogous Cost Estimating

If you find that you’re launching projects that are similar to past accomplishments, analogous estimating may be your best bet. Analogous estimating relies on historical information to predict the cost of the current project. It is a type of top-down estimating. The process of analogous estimating takes the actual cost of a historical project as a basis for the current project. The cost of the historical project is applied to the cost of the current project with respect to the scope of the current project, its size, and other known variables.

This estimating approach takes less time to complete than other estimating models, but it is also less accurate. This top-down approach is good for fast estimates to get a general idea of what the project may cost.

Here’s an example of analogous estimating: You completed the design and installation of an application for the sales department to track incoming phone calls from clients. Your IT help desk now wants you to create an application to track phone calls from internal users. The project deliverables are technically different, but both have fundamental characteristics that can guide you to create a reasonably reliable project cost estimate.

Using Parametric Modeling

Another approach to top-down estimating is parametric modeling. Parametric modeling uses a mathematical model based on known parameters to predict the cost of a project. The parameters in the model can vary based on the type of work being completed. A parameter can be cost per cubic yard, cost per unit, and so on. For example, it costs $149 per software license and you need 200 licenses. Some quick math tells you that the total cost for the software is $29,800. A complex parameter can be cost per unit with adjustment factors based on the conditions of the project, such as delivery dates, penalties or bonuses, or additional materials used. Furthermore, the adjustment factors may have additional terms depending on project criteria.

For example, if you’re managing an application development project, you may create a cost estimate based on the number of years of experience the application developer has with a given software language. Binita may have eight years of experience, while Sam only has two years of experience. Sam doesn’t cost as much as Binita because Sam is considered less experienced than Binita. Sam can still get the work done; it just may take slightly longer than it would if Binita did the work.

When you think of parametric modeling, a parameter is generally used: cost per unit installed, cost per machine delivered, and so on. This approach doesn’t always lend itself to IT projects because of the variables within the technology. Consider function point analysis: lines of code are not always reflective of the productivity, the number of servers, or even the number of programmers assigned to an activity.

Budget at Completion

The budget at completion (BAC) is the sum of the budgets for every phase of your predictive project. This is the estimated grand total of your project. If a project manager breaks down a project into phases—and they should—then each phase can be reflected with a dollar amount that needs to be allotted to that phase. The benefit of this approach is that an organization does not need to allot all of the BAC at the project’s inception, but rather the initial amount required to set the project in motion, and another amount as each phase is completed.

The primary advantage of this approach is that an entity can continue to use the capital earmarked for the project until the next phase of the project is ready to proceed. A secondary advantage of the BAC is that it allows everyone involved in the project decisions to examine the costs of each phase of the project and then the project’s grand total. So rather than seeing “Server upgrade costs: $25,128,” management sees this:

As you can see, this approach to budgeting allows all parties to get a sense of what each phase will cost, when the monies will need to be allocated (in advance of the implementation date, of course), and the total cost of the project. This cash flow approach to project management creates cooperation among the project manager, the project customer, and management. The project manager should include phases that do not require any outlay of cash. In some situations, you may be required to add the number of hours estimated to complete each phase of the project to factor in the cost of an employee’s or a consultant’s time. The preceding sample shows only the hardware expense.

Zero-Based Budgeting

Another concept you’ll likely encounter is zero-based budgeting. Zero-based budgeting means that the budget for a department or program to be created must always start at zero, rather than a dollar amount from a similar project, and then the new expenses are factored in. This long-winded approach generally is required each fiscal year. As Figure 5-4 depicts, zero-based budgeting requires a zero balance at the genesis. In other words, you can’t take last year’s budget for all projects in the IT department, add 20 percent to it, and claim that this new number is this year’s upgraded budget. When you have to use zero-based budgeting for a project, you’re required to reflect the true costs of each project deliverable with evidence of the costs. This can alleviate fluctuations in costs from past projects to the current project.

Figure 5-4  Zero-based budgeting requires a zero balance at the genesis.

While this approach may seem similar to bottom-up estimating, it’s often used for a series of projects, an entire department, or a long-term project that may last several years.

The biggest complaint IT project managers have with zero-based budgeting is that it feels as though you’re doing your work twice. In reality, it forces you to ensure that the costs of goods and services have not changed—and if they have, the budget reflects the change in costs. Zero-based budgeting creates a sense of accountability for the project manager with regard to getting an accurate cost of the services and hardware to be purchased.

Some IT project managers will, however, rely on similar budgets and fudge their way through a new budget. Don’t take this route! Why? Why not just take last year’s figures, check out any major changes, and go with the number predicted? Well, it could cost the organization money and cost you your project and your job.

Imagine that you take last year’s budget for server upgrades, add 20 percent to the budget, and claim it as this year’s project budget. When it comes time to actually purchase the hardware, what will happen if the cost of the hardware from last year has increased due to supply and demand? Or what if the servers you used last year are no longer available and the next step requires purchasing a server that costs 30 percent more than a similar server last year? You’ll have much explaining to do.

When you are asked to use zero-based budgeting, use it. Even if the project is identical to a previous project, investigate the costs of goods and services required to complete the project and report them accurately. It’s not always fun, but that’s why it’s called work.

Determining Project Expenses

On the surface, it’s easy to predict what a project will cost. Take the hardware required, add it up, and there’s the amount needed, right? We all know it’s not that easy. There are other factors involved in predicting the cost of a project. For starters, organizations have to examine if the capital expenses (CapEx) versus the operational expenses (OpEx) the project will affect the overall finances of the organization. Capital expenses are often related to projects, as these expenses are big purchases that will be implemented into the organization and used for many years. Operational expenses include expenses such as payroll, facilities, software management, and the general cost of doing business. Projects are affected by both types of expenses.

When predicting the project expenses, a project manager has to look at employees, the combination of employees working together or alone, hardware expenses, the determined scope of the project, and the necessary hardware to implement the plan. The total of these variables makes for long planning, calculating, and educated guesses as to the expense of a project. Careful planning and experience are the two best ingredients for cooking up an accurate budget.

The Cost of Goods

If you wanted to purchase one solid state drive (SSD), it would be easy to determine the cost of that one device. However, if you need to purchase two clustered servers, with giant amounts of RAM, terabytes of RAID drives, multiple NICs, eight processors, and more power than ever before, the calculation would be a little tougher. You could leave it all up to the manufacturer or your favorite salesperson, but would you get your dollars’ worth?

Would it be better to assemble the servers in-house? Would it be better to have the manufacturer assemble the board and NICs, and then have your IT department add the RAM and the cluster RAID later? What about installing any operating systems through the manufacturer? Is your staff prepared and knowledgeable enough to assemble everything on their own? And is it even worth the time to assemble such a clustered server onsite? How much time will it take? These types of build-or-buy decisions should be based on the WBS. Each deliverable should be analyzed to assess whether it should be made or bought, or whether there is an option to build or buy that requires further investigation.

The decision to build or buy a product is a fundamental aspect of management. In some conditions, it is more cost effective to buy, while in others, it makes more sense to build an in-house solution. The build-or-buy analysis should happen in the initial scope definition to determine if the entire project should be completed in-house or procured. As the project evolves, additional build-or-buy decisions are needed.

The initial costs of the solution for the in-house or procured product must be considered, but so, too, must the ongoing expenses of the solutions. For example, a company may elect to lease a piece of equipment. The ongoing expenses of leasing the piece of equipment should be weighed against the expected ongoing expenses of purchasing the equipment and the monthly costs to maintain, insure, and manage the equipment.

For example, Figure 5-5 shows the mathematical approach to determining whether it is better to create a software program in-house or buy one from a software company. The in-house solution will cost your company $25,000 to create your own software package and, based on historical information, another $2,500 per month to maintain the software.

Figure 5-5  Build-or-buy formulas are common practices in project management.

The software company has a solution that will cost your company $17,000 to purchase, but the software company requires a maintenance plan for each software program installed, which will cost your company $2,700 per month. The difference between making the software and buying the software is $8000. The difference between supporting the software the organization has made and allowing the external company to support their software is only $200 per month.

The $200 per month is divided into the difference between creating the software internally and buying the software, which is $8,000 divided by $200, or 40 months. If the software is to be replaced within 40 months, the company should buy the software. If the software that will be created will not be replaced within 40 months, the company should build the software.

There are multiple reasons an organization may choose to build rather than buy. A project team can build or buy as much as it needs to complete the project scope. Here are some common examples of reasons to build or buy:

As you can guess, or maybe you’ve experienced, there are lots of avenues to consider when purchasing hardware that will need to be assembled and configured. In some instances, off-the-shelf hardware will be an appropriate solution for a project, while in other instances assembling the hardware onsite will be more cost effective. How can you know the difference? Figure 5-6 shows that the cost of hardware assembled by the manufacturer should not be greater than the amount of time it takes to assemble the hardware in-house.

Figure 5-6  The vendor’s costs should not outweigh the value of the cost of internal resources.

You need to consider other factors when allowing hardware to be assembled through the manufacturer versus piecing the hardware together in-house:

•   How long will the assembly take? If you or a staff member has experience assembling hardware components, you can make an accurate prediction as to the length of the assembly process. From that information, you can calculate the cost of the assembly process. This dollar amount, assigned to the assembly process, can help you determine if it is more cost effective to assemble the hardware in-house or to allow the vendor to assemble the hardware.

•   What other tasks can the technician do? Consider the technician’s time, the cost of the time, and the other responsibilities the technician could handle on the project. It may be more valuable to the project if the vendor assembles the hardware and the technician moves on to other aspects of the project.

•   Will the vendor guarantee the work? If the vendor is to assemble the hardware, that vendor should guarantee their work. Incorrectly configured hardware by the vendor could bring your project to a grinding halt. A vendor that is assembling the hardware you are purchasing is going to charge you adequately for the time and materials it takes to build the component according to your specifications. The vendor’s contract should include a guarantee that the hardware will arrive in working order and will work in your environment.

•   Is in-house assembly worth the headache? The headache factor sometimes outweighs the money saved by doing the work in-house. In some instances, especially when the savings from doing the work in-house are nominal, it is more effective to allow the vendor to assemble the hardware. Let the vendor deal with installing the RAM, processors, and BIOS upgrades and configuration. Often it’s not worth the headache to do the work in-house.

•   Can something new be learned? Sometimes by creating the product in-house your team has an opportunity to learn a new competency that can be leveraged for other projects. This assumes, of course, that you have the time to learn, experiment, and try different approaches in the creation of the product.

Outsourcing

One of the most popular trends in information technology is to outsource practically any project. On some levels, this is both cost effective and extremely productive. In organizations that don’t have a full-time IT manager, it is ideal to outsource the simplest of IT problems to a team or consultant. When you consider the cost of hiring a full-time IT professional at $85,000 per year base salary versus outsourcing to an integrator to service the computers and printers for $45,000, it’s an easy decision. However, this opportunity, as with any industry, has created some less-than-desirable businesses. It’s incredibly easy for anyone to market themselves as an IT expert, land a few accounts, and take advantage of otherwise unknowing clients. Not that this would happen to you.

When outsourcing a project or considering outsourcing a project, ask the following questions:

•   Is it cost effective? Consider the time, learning curve, implementation process, and dollar amount associated with each variable and compare that to the figures from the vendor proposing to do the work.

•   Is it productive? Again, consider the time of doing the work internally versus hiring an outside agency to complete the tasks. You should consider not only the dollar amount but also the time involved to complete the project.

•   Is the vendor reputable? Ask the vendor for references of similar work they have done before. Ask them for industry credentials from Microsoft, Oracle, Project Management Institute (PMI), CompTIA, and others.

•   Is this an HR decision? Outsourcing a technology project may not even be the project manager’s decision. HR and management may have created contracts and agreements with staffing agents to complete the project work while you, the internal project manager, are to manage the external workers.

•   Consider culture differences. Internal resources are familiar with the politics, priorities, and procedures within your organization. A vendor may have a completely different set of priorities or a different definition of quality or immediate deadlines.

Outsourcing is not always the best solution, but sometimes it’s the most appealing to management. This is because the cost considerations, the internal learning curve, and other projects that may be on the horizon could conflict with the outsourced job. If you decide to consider outsourcing a project, get a fixed cost from the vendor—especially when proposing a budget to management. You may need to work with the vendor, or several vendors, to negotiate a fair cost for services and manage the purchase of the hardware separately to get a better sum price. Many vendors will give you a break on the price if you buy the hardware and the implementation through the same source. I’ll discuss the gritty business of procurement in Chapter 6.

Estimating Work Hours

What’s the most expensive element in any project? If you said time, you are correct! Time is the one component of a project that is the most difficult to predict, the hardest to manage, and the easiest to lose control of.

Think about your own day as an IT professional. How many times have you set out to complete a task—for example, something as simple as troubleshooting a printer for a particular user—only to be summoned for more tasks along the way? You go to the printer to make certain it’s turned on, check the power, pop open the printer, and check the toner. While you’re there, two folks begin asking you questions about how to create a macro for column numbering. Now your phone chirps with a text message reporting that the SQL server is running out of disk space and the transaction log needs to be cleared.

The printer looks fine, but the user still can’t print. You get to their desk only to discover that their neighbor reports that their mouse won’t work. Get the picture? Or is it too close to reality? It’s just one thing after another all day long—and that user still can’t print.

As an IT project manager, your time is very valuable and has to be guarded from interruptions by users, texts, and yet more users. I can hear you now, “Yeah, sure.” Seriously, think about the percentage of your day that is committed to putting out fires in proportion to the percentage of your day that can be dedicated to a project. Now think of the people on your project team and the same interruptions and activities that may delay them from completing their project tasks.

While you, the IT project manager, may not be the individual performing each step of the project’s implementation, you do have to be available to work with your team, resolve issues pertinent to the project’s success, and have time to track and report the status of the project. In some organizations, the project manager may have to wear several hats, supporting the users, working on each phase of the project, and tracking the project status. In others, the project manager may have the luxury (or headache) of delegating the phases to individuals and managing several projects at once. In either situation, your ability to manage your time, and the time of your team, is crucial to the success of the project.

When you are budgeting a project, you can also use PERT or the three-point estimate approach for predicting team members’ time and costs. Most project managers have a range of variance assigned to labor costs. For example, the cost of labor will be $4,000 +/− $400. In the following table, examine how much team members’ average hourly rates cost the company from best- to worst-case scenarios to do a given task using a three-point estimate.

As the table illustrates, you can fairly accurately predict the cost associated with each team member’s time by using the individual’s hourly project cost rate; the time you predict it will take the team member to finish the task; and the best, worst, and average scenarios. This worksheet has been created for you in an Excel document called Estimating Worksheet that is part of this book’s online resources (see Appendix C). You will be using the worksheet in an exercise at the end of this chapter.

Another advantage of this worksheet is that it can help you determine which tasks should be assigned to which team members. For example, you may not want to assign Julieta, who has an hourly rate of $40, to pulling cable—a mundane and tiresome chore. A bigger bang for your budget dollars would be to assign this task to Holly or Selim. If you could, you may assign the task to both Holly and Selim, who have a combined hourly wage of $35. This would put two workers on the task and would cost less per hour than Julieta’s hourly rate. In addition, two people could, in this instance of pulling cable, finish the job in nearly half the time, or better, that it would take one individual.

Of course, you’ll have to consider a few things when assigning resources to tasks:

•   Consider skill sets. Can the resources you’d like to assign actually complete the project work? Just because someone is available doesn’t mean they’re able and willing to complete the assignment.

•   Consider productivity. Can a higher-paid resource complete the job more quickly and more cost effectively than a lower-paid, less-experienced resource?

•   Consider the law of diminishing returns. Just because you can add more resources to a particular task doesn’t mean the task time can be exponentially reduced. For example, adding two people to pulling network cable may ensure the activity is completed more quickly, but assigning four people to the same job doesn’t mean it’ll get done four times as fast.

Tracking Budgetary Expenses

It is very easy for expenses to spiral out of control. Imagine that you are buying a new server. You’re talking with your favorite vendor and he’s showing you that for a few hundred dollars more you can have eight processors instead of four. And you say, “Might as well.” Then the vendor shows how for a couple hundred more you can add 800GB more storage. And you say, “Might as well.” Then the vendor shows how for just a little more you can really up the RAM. Again you say, “Might as well.”

“Might as well” are some dangerous words when it comes to shopping, aren’t they? It’s so easy to tack on some bells and whistles for just a few dollars more. Before you know it, those few dollars more have stretched your budget so thin you’ll either have to ask for more funds or skimp on other areas of the project. And it’s just not shopping that can ruin your budget. It’s also personnel, human error, lack of planning, hidden costs, and general lack of research.

Not only do you need a detailed budget prior to making any purchases, but you also need a detailed method to track expenses as they are incurred. This is called working toward your BAC. By documenting each purchase as it’s made, you can check the purchase price against your initial budget to confirm that what you planned for is what’s actually implemented.

Runaway Projects

A runaway project, as its name implies, starts out well; gains speed, momentum, and scope; and then causes runaways with your budget, your work hours, and possibly your reputation or career. The biggest element of a runaway project is the budget. Project managers often try to throw money at a problem rather than completing root cause analysis. Too often in project management, there is an attitude of solving problems by spending more money.

Runaway projects happen for several reasons:

•   Lack of planning  Failure to plan for all aspects of the project can cause projects to fail in the beginning, not the end.

•   Lack of vision  Failure to create a definite purpose for the project can cause a project to fail.

•   Scope creep  Management and departments continue to add details and extras to an existing project scope without following the change control processes. Recall that the project scope is all of the required work—and only the required work. Scope creep is also called project poison, because it robs the project of time and monies for things that are in scope.

•   Lack of leadership  Without leadership, the project is bound to wander aimlessly and incur additional expenses.

•   Lack of a change control system (CCS)  A CCS is a formal process to evaluate, approve, or decline proposed changes and additions to the project scope.

You can prevent runaway projects by creating a definite, nearly unmovable plan for the project’s implementation, budget, and scope. Any additional attributes of the project that are not key to its success should be set aside, regardless of the requestor. In all projects, however, there needs to be a process that will allow changes to enter the project plan. Chapter 10 will discuss this change management in great detail.

Here is an example of what appears to be a simple change to a project’s scope: You are managing a project that will create an application with hooks into a SQL or Oracle database. The application will allow salespeople to place an order, check that order against warehouse inventory, and predict a ship date for the customer based on inventory or production.

The original plan of the application called only for tight coupling of the application and the database. (Tight coupling means the application has to be connected to the database to run.) Now, several weeks into development, management asks that you change the application to allow loose coupling. (Loose coupling allows the application to run without being directly connected to the database.) Can you see the problem now? Several weeks of development have been centric to tight coupling; now what appears to be a simple change does not reflect the work hours invested in the original application.

In this scenario, management is suddenly adamant about the loose coupling because it enables the salespeople to take their laptops into the field, take orders and store them locally, and then, once they are connected to the network in the office, actually synchronize the orders with the warehouse. The project manager must first meet with management and discuss the change and explain to management how the request will increase the scope of the project. When the scope of the project increases, additional funds will be required, in most instances.

Next, the project manager will have to meet with the developers and discuss the new application plans with them. The developers will, no doubt, curse management, slam their keyboards a few times, drink some sugary soda, and then start working the new plan into their project. Because of lack of planning, the project scope has increased, time has been wasted, dollars have been spent, and morale has suffered.

Keeping Track of Expenses

Before the project actually begins, you’ll need to work within your organizational policies on how project expenses will be tracked and monitored. In some organizations, budgetary concerns are handled by management with some input from the project manager. In other organizations, the project manager is responsible for the day-to-day accounting of the project budget. There are multiple tools available to help you track the project expenses, but whichever one you use to keep track of your project expenditures, you’ll need to include some basic elements:

•   Work hours  Work time is one of the most expensive elements to any project, so you should have a plan for team members to report their hours working on a given project. If you are working with vendors or consultants who will be billing by the hour, create a method for them to report their hours as well. You may need to create a formula to reflect overtime and weekend pay if that is applicable to your organization. Functional managers of your project team members will also want some accountability of their employees’ time on your project.

•   Burn rate  How quickly the project consumes the project budget in relation to the work actually completed is called the burn rate. The faster you “burn” through the project budget, the more likely it is that the project will be over budget. To calculate the burn rate, you’ll use the formula 1 / cost performance index (CPI). I’ll explain CPI in Chapter 9, but for now just know it represents how well the project costs are performing. A burn rate greater than 1 is not good, as it’s nearly impossible to recover the costs in future project activities.

•   Procured goods  Keep track of all hardware, tools, software, cables, and any other items that are purchased directly for your project. Your accounting software should have a method for entering any of these items. Also include petty cash items such as pizza dinners and miscellaneous items your team needs.

•   Software licensing  If your IT project includes software-licensing fees, be sure to document them. In some organizations, the IT department may pay for the initial licensing of the software, but as the software is released throughout the company, other departments have to pay to use the software from their budgets. An IT project manager should know how these fees are handled and from whose budgets these funds will flow.

•   Workstations and servers  If your IT project includes workstations and servers as part of the plan, document the purchase price and installation date of the computers. Obviously, in some plans the implementation of the workstations or servers may in itself be the project. The reason to document the actual expense of the computers is so that if they are recycled into other servers or workstations for future projects, you can reflect the original paid price of the PCs and then diminish the value of the computers in the new project. You likely won’t have to get into the details of single-line deductions versus double-declining deductions for tax purposes, but your organization’s accounting department may query your decisions and choice to recycle hardware.

•   Actual variances  Throughout your project, you may have small variances between what was estimated and the actual cost of the deliverable. For example, you may order supplies for the project at $440 and the actual invoice is $480. While it’s only a $40 variance, it’s still a variance that’s going to add up and count against your budget at completion.

You can use a spreadsheet like the following example to keep track of budgetary expenses. This spreadsheet is for the first of three phases for a software upgrade. The actual Excel spreadsheet, named Budget Worksheet, is available as part of this book’s online resources (see Appendix C). In this spreadsheet, you’ll see a predicted cost baseline and the actual costs. When you track the actual costs, you can create a burn rate for the project. As mentioned earlier, a burn rate shows how quickly the project is “burning” through the allotted budget in relation to the progress the project is making. Be wary of burn rates; while they seem like a good idea, many projects have up-front expenditures such as purchasing equipment, hardware and software, and other resources.

Each project will, of course, have different needs for computing the expenses committed to that project. This example shows work hours, hardware and software purchased, and any incidentals. The formulas reflect a running total of each week of the project and a total for the project’s expense at the phase the project is currently in. You will get a chance to practice creating a budget spreadsheet in an upcoming exercise.

As you can see, this project has ended phase 1 with a surplus of $102.11—an excellent reflection of planning and predicting by the project manager. While a surplus of this little amount is acceptable, a surplus of 10 percent or more of the predicted project phase budget is not a reason to celebrate.

Some IT project managers congratulate themselves for coming in under budget. However, there are several problems with large budget surpluses. The first problem is that it reflects poor planning on behalf of the IT project manager. An accurate plan will keep any surplus within 3 to 5 percent of the original budget, including the agreed-upon range of variance for the project. The second problem with surpluses is that they create an attitude of spending. Organizations with surpluses do not feel obligated to return the funds, but rather feel obligated to spend them to justify their original budget and to ensure that their budgets will be as fat on the next project. Gold plating happens when a project manager bypasses the change control processes and adds features to a project’s deliverable only to consume the entire project budget. Poor planning is not a reason to celebrate.

CompTIA Project+ Exam Highlight: Managing Project Costs

You’ll be faced with plenty of questions about cost management, creating cost estimates, and managing budgets on the CompTIA Project+ exam. You’ll need to be familiar with the terms and processes covered in this chapter and how these processes relate to other areas of project management, such as risk, quality, and resource management.

1.2 Compare and contrast Agile vs. Waterfall concepts  Adaptive and predictive projects, which CompTIA calls agile and waterfall projects, respectively, approach cost management differently. While predictive projects aim to predict the costs of all items in the project through intense planning, adaptive projects focus on delivering value as quickly as possible. Adaptive projects begin with a budget for the project based on the project vision and the product backlog. The team creates the items with the most business value first and then items with less value. Predictive projects create items based on phases and sequencing of activities to reach the end of the project, not to reach the business value. Neither approach is wrong or better than the other, but each approach has merits and advantages.

1.11 Explain important project procurement and vendor selection concepts  If a project is utilizing a vendor, there will be contractual obligations, cost of the procured resource, and payment systems to follow. It is not unusual for a project to hire contract labor through a vendor to help the organization complete the current project and maintain operational activities. In addition to contract labor, a project may need to purchase or lease physical resources such as hardware, equipment, or space for the project team to work. In the next chapter I’ll delve into more specifics on procurement management activities, but obviously procurement is related to cost management in any project.

2.1 Explain the value of artifacts in the discovery/concept preparation phase for a project  When it comes to determining the cost of the project, the organization will determine if the project is related to an operational expense or a capital expense. Operational expenses (OpEx) are the costs of maintaining the operations, such as payroll, facilities, and keeping the lights on. Capital expenses (CapEx) are often larger purchases, like equipment, custom software, or new facilities, that will be used by the organization for years to come. Operational expenses are ongoing, while capital expenses are a single purchase of the implementation.

2.3 Given a scenario, perform activities during the project planning phase  In a predictive project, cost planning is one of the most important planning activities. The cost management plan defines how the costs of the project will be estimated, budgeted, and controlled. In this chapter, I detailed several cost-estimating techniques that a project manager can use in different scenarios in the project. Recall that bottom-up estimating creates a cost estimate for each element of the WBS, while top-down estimating uses a similar process to predict the current project costs. Parametric estimating is an estimating approach that uses a parameter, such as cost per unit, to predict the project costs. Analogous estimating creates an analogy between the current project and similar, but completed, projects.

You also learned about three-point estimates and PERT estimates. Three-point estimates are really just an average of the optimistic, most likely, and pessimistic cost estimates. PERT, the Program Evaluation and Review Technique, uses the formula (Optimistic + [4 × Most Likely] + Pessimistic) / 6 to find the cost estimate. You can use PERT and three-point estimates for both costs and time estimates.

Often the project budget is consumed by the purchase of goods and services. The procurement management plan defines the complete procurement process, but I did touch on some key procurement information in this chapter. You learned about the need for purchasing goods and services and when it’s appropriate, best for the project, and cost effective. You also learned about the buy-versus-build scenario. Remember that to find the most effective build-or-buy decision, you’ll consider more than just the price. For the CompTIA Project+ exam, however, you may be faced with a decision to build or buy based on price only. To make the decision, find the difference between the build and buy costs. Then you’ll find the difference between the monthly fees for buy and build. Finally, you’ll divide the difference of the buy and build initial costs by the monthly fee difference. Sometimes it’s more cost effective to let the vendor provide the solution, whereas other times you can recoup your out-of-pocket costs and build the solution in-house.

Chapter Review

Technology is an investment, not an expense. One of your roles as a project manager is to safeguard the investment dollars and ensure that the project is implemented successfully and within budget. This includes the planning, testing, integration, and, ultimately, the implementation phases. In some instances you will be forced to alter the plan, which will most likely alter the budget. Of course, adaptive projects expect the requirements to change and they adapt quickly to customer requirements.

An effective project manager can work with bottom-up cost estimates to accurately predict each phase of a project and what expenses will be associated with each phase. Typically, zero-based budgeting will determine estimates for IT projects, and this will require that you and your project team research the true costs of each component of the project to ascertain an accurate price for the product implementation. In some instances, best- and worst-case scenarios should be used so that you can predict an average amount of time, cost, and dollars needed to implement the technology.

Finally, you will need a good flow of communication between vendors, team members, and consultants to keep an accurate record of time invested, dollars committed, and incidental expenses incurred in a project. By tracking budgetary expenses, you can see weekly, or even daily, expenses incurred throughout a project. This will also allow you to see a running total of a project’s phase and predict any overrun or the possibility of a budget surplus.

Exercises

These exercises allow you to apply the knowledge you have learned in this chapter and are followed by possible solutions.

Exercise Solutions

The following offer possible solutions for the chapter exercises.

Questions

1.   You are the project manager for your organization. Management has asked that you create a detailed cost estimate for a new solution they’d like you to implement. What type of project estimating must account for every expense within a project before the work begins?

A.   Bottom-up estimating

B.   Top-down estimating

C.   Zero-based budgeting

D.   Parametric estimating

2.   You are the project manager of the JHN Project. You have estimated the project will cost $129 for each unit installed. There are 1,200 units on this project. What type of estimate is this?

A.   Bottom-up

B.   Top-down

C.   Analogous

D.   Parametric

3.   Harry is the project manager for his organization. Midori, his manager, has asked that Harry create a bottom-up cost estimate for a new project. What is bottom-up cost estimating?

A.   Using last year’s budget plus 20 percent to equal the current year’s budget

B.   Using this year’s budget with a 20 percent plus or minus shift in the bottom line

C.   The process of working toward a zero balance as the bottom line in a budget

D.   The process of creating a detailed estimate for each work package in a WBS

4.   You are the project manager for your organization. Your current project is similar to a project you finished recently for your organization. You decide to base the current project cost estimate on the previous project. What type of cost estimating are you using in this instance?

A.   Analogous

B.   Parametric

C.   Definitive

D.   Rough order of magnitude

5.   What should a project manager do to predict the total cost of an IT implementation project accurately?

A.   List all of the expenses and add them up using best- and worst-case scenarios for each expense.

B.   List all of the expenses, including labor, and add them up using an average-case scenario for each expense.

C.   Divide the project into phases and assign a dollar amount to each phase.

D.   Divide the project into phases and estimate a dollar amount for each milestone within a phase.

6.   What is a fully burdened workload?

A.   It is when an employee has reached their maximum number of hours allotted for any given project.

B.   It is when a consultant has reached their maximum number of hours allotted for billable time for a project or task within the project.

C.   It is the prediction of the number of hours required by staff to complete each phase of the project.

D.   It is the record of the number of hours required by staff to complete each phase of the project.

7.   Why should an IT project manager use most likely, optimistic, and pessimistic scenarios when calculating the time required for a task?

A.   Some staff members will take longer than other staff members to do the same type of work.

B.   Each staff member will have a dollar amount assigned to the work hour. The optimistic and pessimistic scenarios can predict which staff member is the most valuable.

C.   The most likely, optimistic, and pessimistic scenarios allow an IT project manager to predict the average time expense required to complete a task.

D.   The most likely, optimistic, and pessimistic scenarios allow an IT project manager to predict the average amount of labor required to complete a task.

8.   Reynaldo is the project manager for his organization and is completing a project for a customer. He and his project team have completed the project scope, and they could turn the project deliverables over to the customer and close the project, but they still have $12,500 in the project budget. Reynaldo decides to add some features to the software that would make the software better and to consume the remaining budget. This scenario is an example of which term?

A.   Scope creep

B.   Value-added change control

C.   Configuration management

D.   Gold plating

9.   You are the project manager for your organization, and you’ll need to procure servers and workstations from the vendor. You’d also like the vendor to install the operating system on each of the workstations based on an image you’ve created. In your procurement process, you’ve specified that the vendor must provide a fixed quote for the work. What is a primary advantage of an IT project manager requiring a vendor to deliver a fixed quote?

A.   It locks the vendor into the project.

B.   It prevents the vendor from adding features to the implementation.

C.   It allows the project manager to use the quote for up to one year.

D.   It allows the project manager to incorporate the quote into a proposed budget.

10.   You are the project manager of an adaptive project. Your customer has requested several changes to the product backlog that they say are of top priority. You and the product manager agree and the product backlog is adjusted accordingly. Now, however, the project has insufficient funds to do all of the requirements in the product backlog. What should you do next?

A.   Refuse the changes to the product backlog that are causing the funds to be depleted.

B.   Ask the customer for additional funds.

C.   Submit a change request for additional labor to work on the new project requirements.

D.   Nothing. The most valuable items are completed first.

11.   You are the project manager for your organization. Management has asked that you use PERT for estimating the time it takes to complete the project. Using PERT, what time would you record for an activity that has an optimistic time of 25 hours, a most likely time of 44 hours, and a pessimistic time of 76 hours?

A.   44 hours

B.   46 hours

C.   48 hours

D.   76 hours

12.   What is the difference between a three-point estimate and a PERT estimate?

A.   PERT uses a weighted average of the most likely, whereas the three-point estimate is really just an average of all three estimates.

B.   PERT uses an average model to predict the most likely duration for time or costs, whereas a three-point estimate uses a straight average for the duration or costs.

C.   PERT and three-point estimates are actually the same model.

D.   PERT is used for time and cost estimates, whereas three-point estimates are used only for time.

13.   You are the project manager for your organization and are trying to determine if you should buy or build a solution. You’ve determined that your project team could build the solution for $23,500 and the monthly maintenance on the solution would be $1,200. A vendor reports that they could build the solution for $17,000 but their monthly maintenance fee would be $1,800. Should you buy or build this solution?

A.   Build the solution if you’ll keep it for less than 11 months.

B.   Buy the solution if you’ll keep it for more than 11 months.

C.   Buy the solution if you’ll keep it for less than 11 months.

D.   Build the solution if you’ll replace it in less than 11 months.

14.   You are the project manager of a project to install 8,500 workstations in an organization. You have estimated that the optimistic cost of the labor for each workstation will be $99, the most likely cost will be $149, and the worst-case cost for each workstation will be $225. What cost will you record for your cost estimate per workstation?

A.   $149

B.   $225

C.   $158

D.   It depends on the person doing the installation

15.   Which one of the following is an example of an estimate using a parametric model?

A.   The current project is similar to the past project, so the project manager will base the current estimate on the previous project.

B.   Each item in the WBS must be cost-estimated to create the project cost estimate.

C.   There are 7,100 network drops, and each drop will cost $175.

D.   The organization is charged a set fee for all the connections to a server.

Answers

1.   A. Bottom-up estimating requires the project manager to account for all expenses within the project to arrive at a grand total for the project.

2.   D. This is an example of a parametric estimate. The units will cost $129 each; this is the parameter. As there are 1,200 units on the project, the estimate is calculated by multiplying the parameter of $129 by the total number of units needed, 1,200, for an estimate of $154,800.

3.   D. Bottom-up estimating is a process that requires the project manager to create a detailed estimate for each work package in the WBS. Every work package can be cost estimated, and it’s the sum of the work packages’ cost estimates that help determine the bottom-up estimate.

4.   A. This is an example of analogous estimating. By creating an analogy between the current project and the previous project, the project manager can predict current costs. To use an analogous estimate, you must have accurate historical information.

5.   C. The project manager should not create one grand total for a project. In order for the project manager to see a true picture of the work, they should segment the project into phases and assign each phase a dollar amount based on the work to be completed within it.

6.   C. A fully burdened workload is the prediction of the actual hours required by the team members to complete a given project. This process allows the project manager to predict the financial obligations corresponding to time and create a sense of urgency as to when each task must be completed.

7.   C. Using the most likely, optimistic, and pessimistic scenarios allows a project manager to predict the average amount of time the team member requires to complete a task. The project manager uses this value to assign a dollar amount to the work to be completed.

8.   D. This is an example of gold plating. Gold plating happens when the project manager or team adds deliverables that were not in the project scope in an effort to consume all of the project budget.

9.   D. A fixed quote allows the project manager to use that dollar amount in a budget to predict the funds required to complete a project. It can also be used to determine which vendor will actually be awarded the job based on the price and hours to complete the work.

10.   D. The product backlog is always prioritized so that the items with the most importance and the most business value are completed first in the project. Requirements that are of less value shift downward in the product backlog and may fall out of the possibilities for completion. These additional items may be moved into a new project, such as a future release.

11.   B. The Program Evaluation Review Technique (PERT) is a time-estimating formula that accounts for the optimistic, pessimistic, and most likely estimates. The formula is P + O + (4ML) / 6. In this example, the closest result is 46 hours.

12.   A. PERT uses a weighted average to predict the cost or time of an activity. It’s considered weighted because the formula is P + O + (4ML) / 6. The three-point estimate is just an average of the pessimistic, optimistic, and most likely estimates.

13.   C. To determine whether to build or buy, first find the difference between the in-house solution and the vendor’s solution. In this example the difference is $6,500 more to build in-house. Next, find the difference of the monthly support for each solution, which is $600 more a month for vendor support. Divide $6,500 by $600, which tells you how long you’ll need to use the in-house solution to equate to the cost of the vendor’s solution. In this example, it’s nearly 11 months, which means you should buy the solution if you’ll keep it for less than 11 months (or build the solution if you’ll keep it for more than 11 months).

14.   C. If you use the three-point estimate approach in this example, you will calculate the average of the pessimistic, optimistic, and most likely estimates and record the cost estimate as $158 per workstation.

15.   C. A parametric model is a value that can serve as a parameter to determine the project costs. In this example, the 7,100 network drops at $175 each is an example of a parametric model.