RELATIONSHIPS AND TRADEOFFS
James A. Ward, PMP
Project Management always
involves effectively balancing the scope of effort with the resources available
and within an acceptable or pre-determined time frame. I’d like to discuss with you the real
relationships and tradeoffs between the three key variables of Work to be done,
or scope of effort, Resources devoted to that work, both personnel and dollars,
and Time, defined by the project schedule or ship date. How can we manage these relationships
effectively to consistently deliver projects that meet customer objectives on
schedule and within budget?
By
way of introduction and background, I am an independent consultant specializing
in Information Systems project management and the implementation of Quality
initiatives with Information Technology organizations. Like most of you, I started managing
projects early in my career with almost no training or guidance. Starting in the Corporate Information
Systems department at Motorola and then moving to a small data processing
consulting firm in Chicago, I managed projects by the seat of my pants.
Then,
I had the good fortune to join a prestigious international management
consulting firm. I like to say that
there I was not trained in project management, I was indoctrinated. “Plan your work and work your plan” were our
constant marching orders. Every
consulting assignment was a project and every project was done on a fixed price
basis. And, if you’re going to make money
on fixed price project work, you’d better be able to manage projects.
Our
goal was to bring projects in on a consistent basis at plus or minus five per
cent of our bid, based on our internal billing rates. As an example, I worked on a project for a state government
agency that was bid at $100,000. When that contract was signed off, we had
consumed $97,000, based on our $800 per day internal billing rate. We were then
awarded a follow on contract for $500,000, which was also completed on schedule
and within budget.
In
general, plus or minus twenty per cent is considered excellent (and of course
it’s always plus – never minus). Cost
or schedule overruns of fifty per cent are common and generally acceptable.
Our
consulting firm offered a two day seminar in project management methods to our
clients. Since that time, I have had
the opportunity to teach project management seminars and workshops, implement
project management methodologies as both a consultant and systems manager and
write articles on the subject as well as manage dozens of projects in many
organizations.
Why Do
Projects Fail?
It
has been my experience that projects fail in almost every instance 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 different times in the project life cycle.
· Work
Work is the total of those tasks which must
be performed in the course of a project to deliver the product. In our world this product is most commonly
an information system. We can define
the amount of work in different ways. Usually, it is a series of “system
development life cycle” tasks that must be accomplished. Some organizations define the amount 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 work. Work is not the scope of the deliverable
product, but it is directly correlated to the size of the scope.
· Resources
Resources are allocated to and consumed by
any project. 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.
· Time
Time can be defined for our purposes as
elapsed calendar time, usually defined by the project schedule or target ship
date.
How Do We Determine the Relationships Between Work, Resources and Time?
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 define this is “How little RESOURCES and TIME can we
expend and still accomplish some useful WORK
in the direction of our ultimate objectives.”
4.
Given
a certain feature set (WORK), what is
our budget (RESOURCES) and schedule (TIME) 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 WORK, RESOURCES,
TIME, plus two gauges – representing quality and risk. If we set one of the three knobs, say WORK, we can then adjust the other two, RESOURCES and TIME, 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 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, the only way to succeed is to invoke Jerry Weinberg’s 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 WORK, for
example) and attempt to optimize a second variable (schedule – or TIME) and determine the required level
of the third variable (RESOURCES). “If I want to ship this specific product by
a certain date, how much resources will it take to meet that date?” At least as common is to constrain both the
work and the resources and let that determine the time it will take to
accomplish the project.
On most projects, the WORK is defined and RESOURCES are limited, so the TIME
is dictated by the other two variables.
For some organizations, usually producing shrink wrap software, the
resources devoted to a project (or product) are constrained and there is a
regular release schedule that is maintained.
Therefore, the variable that is negotiable becomes the feature set
(hence, the work) that can be contained within a given release.
How do these variables work
together at project inception? I’ve
mentioned “within certain limits” that control these variables. You’ve probably
all 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 or 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 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, for
those of us without a calculator handy.
Any more 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.
Note that the above refers
only to personnel resources that are devoted to performing tasks on the
project, the “WORK” that we are speaking about. Management and customer
involvement are not included, but certainly such life cycle functions as
quality assurance and testing are included.
Why 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. Tasks cannot be easily divided after a
certain point 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 fit
together well.
Too many resources will, in
fact, lengthen a project. Remember the
law of diminishing returns. Well, at some point, the contribution of that next
resource is actually negative.
How does a project manager,
in the planning process, translate a defined amount 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
no one can be 100 per cent productive all the time.
The estimate of ten man
months of work has not factored 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 worked recently 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 to 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.
On most projects, the work
to be done starts as a given, and is related to the scope of the project, the
requirements of the system to be built and the feature set to be
implemented. Resources are always
constrained. So the variable to be
determined is the Time, or project schedule.
How many of you have ever
worked out a project schedule, presented it to your management or clients, and
were then told that you haven’t allowed enough time - lengthen the schedule by
a few months.
Think about those three
knobs. Work and Resources are set;
little can be done about them at this point.
The result – management
exerts schedule pressure. No matter
what your original estimates say, management always wants it sooner. Why do they do this? They may site pressure from their
management, customers, the marketing department, etc. What they probably believe, at least subconsciously, is that
you’ve padded the schedule and they are merely asking you to remove some of
that padding.
Why would a project manager
pad a schedule? Well, you may be forced
into estimating before you know enough about the Work or Resources to give
truly accurate estimates. You may also
not have used a productivity factor, but know from experience that your
resources are not 100 per cent productive.
You may also know of the tendency of developers to be overly optimistic
in their estimates; they never foresee any problems or delays. Ideally, you should address all of these
factors in your planning, before you provide a project plan and schedule.
Another factor that may lead
to padding the schedule is anticipated changes. Remember that I mentioned that as a consulting firm we were
expected to hit our project estimates at plus or minus five percent on fixed
price work? Well, if you’re going to do
anything close to that you’d better aggressively manage change of scope. Don’t anticipate, but do adjust, even for
the most minor changes.
Schedule pressure can be
insidious, and impossible to resist. I
received a newsletter from Pat O’Toole, a fellow consultant, who claims that
what management and clients really want is predictability. They think that if you give them a plan for
12 months and they insist on having the system in 10, that maybe they’ll be
lucky enough to get it in 15. Look at
your organization’s track record. Once
you establish a record of delivering projects on schedule, schedule pressure
will cease.
I once delivered a system on
schedule in a large insurance company and was told that in no way was anyone
ready to start User Acceptance Testing.
They said that in the history of the organization no one had ever delivered
a system less than two years behind schedule.
When I reminded the client of his insistence on needing the system by a
certain date, he responded that they didn’t really believe the date could be
met but they might get it sooner by insisting on that date.
When can a system
development project really be considered to be delivered late? I have a quote from an article I read when I
was just getting started in this business that I think says it best, “ The only
time a project can be truly said to be late is when the project team has wasted
time through lack of initiative or through poor planning.” Plan your work and work your plan.
Schedule pressure, if not
resisted and eliminated through effective project management, leads to
predictable results: Quality suffers,
products ship “late” against an unrealistic schedule, budgets and RESOURCES are exceeded, the system does
not meet requirements as the WORK
gets curtailed to meet other constraints, and projects are canceled, usually
because quality and risk were unmanageable given the pressures and constraints.
How many of us have seen
projects where first the schedule was adjusted, possibly several times. Then more resources are added late in the
game to try to give “the big push” to the project – of course, Brooks’ Law then
takes over and the schedule gets adjusted yet again. Finally, the scope is cut back, usually to the point where the
system no longer meets the objectives that originally justified undertaking the
project in the first place. But the
system, such as it is, gets implemented anyway and we charge on to a new
project. Or, if we’re really lucky, we
get to tackle Phase 2.
A recent client implemented
a system months behind schedule, but had already initiated phase 1B, to correct
the known deficiencies in the original implementation. Phase 2, where the real benefits to the
organization were to be found, was delayed indefinitely – except by the Product
Manager, a VP in new product development who insisted that the time be made up
and phase 2 go in as originally planned – of course being staffed with the same
people who had established the exemplary track record thus far on the project -
GOOD LUCK.
If you find you’re running
out of time, it’s almost certainly because you have other problems on the
project that have remained unaddressed as you continued to extend the schedule.
Lack of time is the reason that most projects are forced to face other factors
causing project failure.
Task splitting is a project killer, it acts very much like Brooks’ Law. It is the bane of the project manager’s existence. If you could go back to your organization tomorrow morning and change just one thing to increase productivity, my recommendation would be to eliminate task splitting – the insidious practice of assigning people to multiple projects.
Why do I say this? The effect of task splitting is very easy to
work out. Let’s say you’ve calculated
your organization’s productivity factor at .7, leaving your staff 3 ½ days, or
28 hours per week to work on projects.
Numerous studies have shown that task splitting further steals
productivity. Assign a person to one
project and that person can devote 100 per cent of that 28 hours per week to
that project.
A good rule of thumb has
been postulated and corroborated by observation. Assigning a person to two projects reduces overall productivity
to about 80 per cent, due to increased interruptions, conflicting priorities,
changing gears, etc. Assigning the
person to three projects further reduces productivity to 60 per cent, leaving
about 20 per cent of 28 hours, or a whopping 5 ½ hours per week of productive
time for each project. Assign an
individual to four or more projects and results are indeterminate. And you wonder why those seven projects George
is working on never seem to get done?
Want further examples?
Let’s say you have a project estimated at one man year, 12 man months,
of work. Assigning one person to that
project and applying your productivity factor of .7 will mean that the project
can be completed in 17 calendar months.
Assign two identical one man year projects to the same person and both
projects will be completed in 3 years and 7 months. For three projects, the time frame will be over seven years. This exceeds the expected employment of most
I.T. professionals. These three
projects are never going to get done.
Even if they are completed, how much would a project started today be
worth to your organization in seven years?
Also note that by tackling
these projects consecutively rather than simultaneously the organization has
the benefit of the first system within a year and a half.
Why do we do it? That’s easy. I.T. management wants to tell all their users that their projects
are actively being worked on. “We haven’t
forgotten the accounting department’s requests to put all our resources on
manufacturing’s project.” We should
know this is nonsense. Getting on my
soapbox a little here, if I.T. management can’t figure out how to leverage its
scarce resources to be the most productive and to provide the most benefit to
the organization, then get some management that can do this. You think I.T. steering committees are the
answer? Forget it, most of those make
the US Supreme Court look apolitical.
And just try explaining Brooks’ Law or task splitting to a steering
committee.
What other factors affect
the key project variables? Definitely
the project environment. How many of
your developers have offices where they can work extended periods of time in
relative isolation, uninterrupted by outside influences? Every industry guru who has looked at the
software development environment – DeMarco, Lister, McConnell, Gilb, Boehm –
has concluded the same thing.
Developers need isolation and time to think for extended periods of
time.
Studies have shown that the
average manager usually works on one thing for periods of less than five
minutes. Developers need uninterrupted
blocks of time from 2 to 4 hours. Early
in my career I was introduced to the Unit of Work concept – plan a block of
work that can be completed in one sitting, and complete that work before taking
a break or leaving work for the evening.
We would design our programs and decompose them to the point where we
felt comfortable that we had defined them in units of work. By doing so, we never had to return to
unfinished work and waste time figuring out where we left off.
Use of a contiguous work
area for the project team has an obvious positive effect on communications and
teamwork. Flextime is not appropriate for
this type of work. Where you must use
it, expect that productivity will decline, and use a lower productivity factor
to compensate. This will, of course,
lengthen your project schedule. Initial
studies with virtual teams and telecommuting have also indicated significantly
lower productivity, although some of this may be offset by the ability to work
in relative isolation for extended periods – but who knows enough about the
environment of telecommuters to say for sure.
How Does Project Size Affect
Work, Resources and Time?
The larger the project, the
lower the average productivity of project personnel, resources are less
effective and time is extended. Also,
very large projects have better than double the chance of being canceled. Remember earlier when I said that 25 per
cent of projects are successful? Well,
that number has doubled since 1980.
Capers Jones says that the biggest reason for this is that projects are
smaller than they used to be, not that we are any better at this work than we
were 20 years ago. He also says that
the larger the project, the greater likelihood of its being cancelled. In the study I sited earlier, projects with
over 5,000 function points were cancelled 50 per cent of the time and over
10,000 function points were cancelled 65 per cent of the time.
An easy explanation for this
is that our current methods and tools are insufficient to control very large
projects. Small errors or
mis-communications can be fixed on small projects but may be catastrophic on
very large ones. Project size is our
enemy. Slice and dice, implement in
successive iterations so you can maintain control. Tom Gilb, in “Principles of Software Engineering Management,”
says that any project can be easily decomposed into successive small releases
of usable functionality, and gives a method for accomplishing this.
A Few Other Project
Management Factors
As I mentioned earlier,
using small amounts of voluntary overtime can extend resources and/or shorten
calendar time. However, excessive
overtime will have the opposite result.
Productivity, per hour worked, will decrease and error rates will
skyrocket. Gerry Weinberg, my second
favorite Information Systems guru, says that people work overtime on projects
in trouble less to accomplish something than to not be blamed for project
failure.
I mentioned the project
manager’s control panel, with three knobs and two gauges. You must always pay attention to quality and
to risk factors – low quality and high risk can sink a project. When developing system requirements,
attention is paid to functional requirements but rarely to quality attributes,
such as response time, maintainability, etc.
When taking over a project for a client, the first thing I always ask
is: Who is the Quality Assurance
Manager on the project? If the client
doesn’t have one, I make procuring that person my first priority. On smaller projects, you’d better be your
own Q/A manager. Quality must be
managed from project inception.
Likewise, risk must be
actively managed. Identify the most
likely project risks and take steps to mitigate those risks. Do contingency planning. Two areas I always examine for risk are
project turnover and the six level two Key Process Areas (KPAs) specified by
the Capability Maturity Model. Until an
organization can adequately demonstrate that these six areas have been
addressed, consider each a risk to the project. For those who are not intimately familiar with the Capability
Maturity Model, the level two KPAs are (1) Requirements Management, (2)
Software Project Planning, (3) Software Project Tracking and Oversight, (4)
Software Subcontract Management, (5) Software Quality Assurance, and (6)
Software Configuration Management. Whether you subscribe to the SEI CMM
approach or not, these are all important things to do, and risky things to
ignore.
To summarize, a project
manager must be able to define and control three key project variables: the work to be done, the resources assigned
to perform that work and the time it will take to accomplish the work. To do this job effectively, the Project
Manager must understand and control the relationships and tradeoffs between
these variables. At the same time, the
Project Manager must actively manage both quality and risk.
I hope I have given each of
you at least one idea that you can think about and apply to your own
organization to improve the quality of information systems delivery, on time
and within budget. Thanks very much for
giving me the opportunity to speak with you.
ABOUT THE AUTHOR
James A. Ward is an
independent consultant specializing in systems development project management
and implementation of quality and process improvement initiatives in
Information Technology organizations. He holds a PMP certification from PMI. He
can be reached at (904) 273-8777 or soozward@earthlink.net. Visit
his website at www.JamesAWard.com.
Jones,
Capers (1994). Assessment and Control of Software Risks, PTR Prentice
Hall, Upper Saddle River, New Jersey.
Brooks,
Frederick P. Jr. (1975), The Mythical Man-Month, Addison Wesley,
Reading, Massachusetts.
O'Toole,
Pat (2001), “Do's And Don'ts of Software Process Improvement #3 DO: Take Time
Getting Faster,” Privately Distributed Newsletter from PACT.
Spett,
Milton C. (1969), "Standards For Evaluating Data Processing
Management," Datamation, December, 1969.
Weinberg,
Gerald M. (1992), Quality Software Management Volume 1 Systems Thinking,
Dorset House, New York.
DeMarco,
Tom & Lister, Timothy (1999), Peopleware (Second Edition), Dorset
House, New York
McConnell,
Steve (1998), Software Project Survival Guide, Microsoft Press, Redmond,
Washington.
Strider,
Wayne (2000), Comments made at the AYE Conference, Scottsdale, Arizona.
Carnegie
Mellon University Software Engineering Institute (1995), The Capability
Maturity Model, Addison Wesley, Reading, Massachusetts.
Gilb, Tom (1988), Principles
Of Software Engineering Management, Addison Wesley, London.