Skip to main content

A Graph and trying(!) to understand why projects fail...

PMBOK mentions Scope, Time and Cost as triple constraints. A project manager has to handle Quality and customer satisfaction in addition to the triple constraints, if he/she has to manage the project successfully. Project quality is impacted by balancing Scope, Time and Cost. High quality projects deliver the required product, service within scope, on time and within budget, leading to Customer Satisfaction.

But if PMs think of it, Cost can be represented as a function of ‘Standard and Nature of the Resources used’, ‘Time the resources is used’ and ‘the scope that is achieved in the said time and using the said resources’. To represent mathematically, Cost = f(Resources, Time, Scope).

The premise of this article is that a PM has to understand the relationship between Scope to be achieved, Resources and Time available, at any given point during the life of the project, to ensure that the project is under control and the project objectives are met.

Let us elaborate on the concept. Scope, Time and Resources can be represented as a two dimensional graph as shown below. Resources are shown on the vertical (Y) axis. Time is shown on the horizontal (X) axis. Scope is shown as a curve illustrating the relationship between the time and resource on a given set of requirements. The point to be understood is that a project will succeed if only if, the intersection of time and resource lands on the intended scope curve.

The figure above illustrates three fundamental truths

  • No matter how many resources you add to a project, there is an absolute limit to how quickly the project can get done, i.e. the curve will never intersect the X axis (Time) and Y axis (Resources).
  • The second truth is that if you take away enough resources, the project will never get done.
  • The third truth is that when all three are fixed by management (scope, time and resource) there is no project management to be done.

As long as two of the three variables of time, resource and scope are fixed, the third can be manipulated to complete the project successfully. If time and scope are fixed, you can increase the resources (more people, more skill, more overtime, better equipment and so on). If resources and scope are fixed, you can lengthen the time to delivery. If time and resources and fixed, the scope can be varied. But unfortunately, this is not the case and most of the projects fail because change in resources, time and scope happens in a manner that is opposite to what is mentioned above. This results in failed projects. Let us use the same graph (slightly modified) to understand why.

The simple graph above provides an elegant illustration of why projects often fail.

  • The requirements increase via ‘Scope Creep’, but the due date and staffing level aren’t changed. Most of the managers don’t get to prove that the scope has increased because they fail to baseline the scope of the project. At some point in time during the early days of the project, the project manager has to announce to all the stake holders the requirements that would get done with a set of people and the time within which it would get done. He/She also has the responsibility to tell the stake holders that any change in any of these three variables will have an impact on the outcome of the project. Most of the fixed Price projects fail because of poor change management. Though we have a Change Control Board in place, the lack of a baseline will prevent us from delineating what is in scope and what is out of scope.
  • The due date is moved up, but the resources aren’t increased. Scope of work remains same. Because of lesser time, lesser amount of work (the scope) is completed and hence the project is a failure.
  • The resources are decreased, but the due date is not extended. Scope of work remains same. Because of lesser resources, lesser amount of work (the scope) is completed and hence the project is a failure.

Note: I read this concept in the Cutter IT Journal March 2003 edition. The first graph is credited to Larry Putnam []


  1. Nice explanation JR. Often top bosses tend to assume that "10 women team will deliver a baby in one month's time". I think this graph explains the things neatly and objectively.

  2. Not all the projects will visit every stage as projects can be terminated before they reach completion. Some projects do not follow a structured planning and/or monitoring stages. Some projects will go through steps 2, 3 and 4 multiple times.


Post a Comment

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …