This is the first of a two-part series of articles. For part 2, click here.

PMP Training – Resources (Intense)

Introduction: Project Management always involves effectively balancing the SCOPE of effort with the resources available (COST), within an acceptable or pre-determined time frame (SCHEDULE). PMI refers to these three variables as “The Triple Constraint.” I’d like to discuss the real relationships and tradeoffs between the three key variables of scope, cost and schedule. How can these relationships be managed effectively to consistently deliver projects that meet customer objectives on schedule and within budget?


Why Do Projects Fail?

It has been my experience that when projects fail, in almost every instance it is because one or more of the key project variables are not managed effectively. In many instances, the relationships between the variables are poorly understood and not managed at all.

Capers Jones, the software measurement guru, cited a study in a recent article that claimed only 25 per cent of all systems development projects were successful. Jones goes on to say that 25 per cent of projects fail to produce any useful results and 50 per cent are challenged–he defines “challenged” as exceeding either schedule or budget by 100 per cent.

Of course, we all know that projects don’t fail, people do. People fail to effectively manage projects.

What Are the Key Project Variables?

I’d like to define these key variables and then discuss how they relate to each other at various times in the project life cycle.

  • Scope of Work

Scope of work can be defined as those tasks that must be performed in the course of a project to deliver the product or service. In our world this product is most commonly an information system. We can define the scope of work in different ways. Usually, it is a series of “system development life cycle” tasks that must be accomplished. Some organizations define the scope of work by the feature set to be contained in the deliverable system. The greater the number and complexity of features in a release, the greater the scope. Scope is not the requirements of the deliverable product, but it is directly correlated to the size and complexity of the product.

  • Cost of Resources

Resources are allocated to and consumed by any project. All resources have costs. These are most commonly personnel and dollars, but can be raw materials, purchased software, tools, office supplies, computer time, travel expenses, etc. Resources are reflected in a project budget by either dollars or man hours.

  • Schedule

Schedule can be defined for our purposes as elapsed calendar time, usually defined by the project schedule or target ship date.

The Relationships Between Scope, Cost and Schedule

In framing these questions, we often substitute the terms work, resources and time for scope, cost and schedule.

Think of your role as project managers as if you were sitting before a control panel with three large knobs on it.
  1. Usually our management says something akin to “What is the most WORK we can get done with the fewest RESOURCES in the shortest TIME?”
  2. Or “How much WORK can we accomplish within some critical constraint (RESOURCES or TIME) and at what level of expenditure of the remaining variable?”
  3. Another way some organizations say this is “How little TIME and RESOURCES can we expend and still accomplish some useful WORK in the direction of our ultimate objectives?”
  4. Given a certain feature set (SCOPE), what is our budget (COST) and SCHEDULE for delivery?

And, as project managers, we must accomplish this at an acceptable level of quality and within an acceptable level of risk.

We can think of our role as project managers as if we were sitting before a control panel with three large knobs on it, labeled SCOPE, COST, and SCHEDULE, plus two gauges, representing quality and risk. If we set one of the three knobs, say SCOPE, we can then adjust the other two, COST and SCHEDULE, to give us a workable project plan and a good chance for success. Of course, we can only adjust them within certain limits, which I will discuss.

At least one of the variables must be fixed, or constrained, to provide a basis for planning the project. It is possible to constrain two of the variables, again within certain limits, if the third variable is unconstrained. If all three are constrained, there is probably no feasible way to accomplish anything meaningful; your project is in trouble from the very start. A colleague, Wayne Strider, told me recently that a project manager must have control over at least one of the three variables or he should walk away from the project. Without that control, the only way to succeed is to invoke the zeroth law of software, “If the system doesn’t have to work, we can meet any other constraints.”

A common approach is to constrain one variable (the SCOPE, for example) and attempt to optimize a second variable (SCHEDULE) to determine the required level of the third variable (COST). “If I want to ship this specific product by a certain date, how much will it cost to meet that date?” At least as common is to constrain both the SCOPE and the COST and let that determine the SCHEDULE it will take to accomplish the project. “If I have a specific budget for this project, how long will it take to get the job done?”

On most projects, the SCOPE is defined and COSTS are limited, so the SCHEDULE is dictated by the other two variables. For some organizations, such as those producing shrink wrap software, the COST is constrained by the amount of resources devoted to a project (or product) and there is a regular release SCHEDULE that is maintained. Therefore, the variable that is negotiable becomes the feature set (hence, the SCOPE) that can be contained within a given release.

You’ve probably all heard Brooks’ Law: “Adding resources to a late project makes that project later.”

How do these variables work together at project inception? I’ve mentioned “certain limits” that control these variables. You’ve probably heard Brooks’ Law: “Adding resources to a late project makes that project later.” Well, that law holds even before a project begins. There is a limit to the amount of resources that can be effectively applied to any project at any time. Theoretically, we know that we can reduce the overall time schedule by increasing the amount of resources devoted to the work. We also know that each additional resource will make less of a contribution to reducing the schedule, but will still decrease calendar time. This is referred to in economics as the law of diminishing returns; each additional increment contributes less to the whole.

However, at some point this relationship ceases to work, and additional resources will not contribute to reducing the schedule. Where is that point?

Empirical evidence has shown that the optimum number of resources (personnel) that can be devoted to a project to shorten its calendar time is about the square root of the number of man-months of work effort estimated to complete the project. Therefore, if you have a 10 man-year project, or 120 man-months, about 11 people is the number you can effectively assign to the project, eleven being the square root of 121. Any more resources will not be able to effectively reduce the overall calendar time. Therefore, you’d better plan on a minimum of 11 calendar months, 120 divided by 11, to complete the project, regardless of the number of resources at your disposal. A few extra resources may be used productively but will not shorten the project schedule. Beyond that point, continuing to add resources will increase, rather than decrease, the project time frame.

Too many resources will, in fact, lengthen a project.

How do we know this is true? First, the need for effective communications within the project team and complexity of those communications is increased each time a person is added to the team. Communication takes time and resources. Second, there are many task dependencies in a system development project; the outputs of one task are the inputs to another. After a certain point, tasks cannot be easily divided to allow two individuals to work simultaneously. More resources on the project means more idle time, or more re-work as communications break down and pieces don’t mesh.

Too many resources will, in fact, lengthen a project. Remember the law of diminishing returns. At some point, the contribution of that next resource is actually negative.

Productivity Factors

How does a project manager, in the planning process, translate a defined scope of work with an assigned number of resources into a workable calendar schedule? You’d better use something called a productivity factor. What is a productivity factor? Suppose you estimate that you have ten man-months of work to do; how long will it take one person assigned full time to complete that work? Definitely longer than ten months. That’s because a person is not 100 percent available to work on the project.

The estimate of ten man-months of work does not factor in holidays, vacation time, sick time, staff meetings, the United Way fund drive, training time, recruiting and interviewing, and many other work-time activities that decrease the time an employee can be productive.

Productivity factors will vary by organization and by type of employee. Contractors are generally more productive because they are exempt from many of the administrative functions that employees must participate in. I recently worked in an organization that calculated their productivity factor at 60 per cent, meaning that a full-time employee was available to perform project work on an average of three days per week. Therefore, a task of ten man-days would consume about 17 calendar days and a ten man-month project could be completed in 17 calendar months.

About the best productivity factor I have seen is with contractors hired specifically and exclusively to work on a project. This factor was about .8, or four productive days per week. We could increase this to about .9 by authorizing one hour per day of voluntary overtime from the inception of the project. Most contractors are happy to work these extra hours, especially if they believe that it could save them from the 60- to 70-hour weeks during project crunch time.

To convert a task from man days of effort to duration in calendar days, simply divide the total work estimate by the productivity factor. In our earlier example, 10 months divided by .6 is 16.67, or 17 months.

In part 2, we will discuss schedule pressure, task splitting, and project size and its impacts on scope, cost, and scheduling.