Plan to do New Mistakes...

Ever imagined yourself to be Michael Schumacher or Fernando Alonso when you drive your car? I hope most of the formula one aficionado at some point would have wondered what it takes to be a formula one driver. Other than amazing levels of fitness (click here to understand the level of fitness we talk about), a formula one driver should also be mentally strong, with supreme driving abilities and split level reflexes.

Compare a formula one driver to a good driver on the road. Though it is nice to have the talents and skills of a formula one driver, it is not necessary that all those are needed to be a good driver on the road. People say that you don’t have to do anything different, but it is enough if you avoid doing the common mistakes. The common mistakes can be anything like talking on a cell phone while driving or driving aggressively or over speeding or tailgating.

The point is that to be a good driver, you don’t necessarily need the driving skills of a F1 driver, and most of the times it is enough if we don’t do the well known mistakes. What holds for driving also holds for Project Management. Most of the projects that we do, doesn’t require the equivalent of a F1 driving skill in project management. It is enough if we ‘not do’ certain mistakes. If you are wondering what these ‘mistakes’ are, just read on…

Documented history of projects is available since 1960s. The study of the data available has shown that some acts of people are repeated often, irrespective of the fact that ‘it’ has an adverse impact on the outcome of the project. Books have been written around some of these topics. For e.g. the case of uncontrolled problem employees is covered by Gerald Weinberg’s Psychology of Computer Programming. Adding late people to a project is cited as a mistake by Fred Brooks in his book the Mythical Man Month. The effect of noisy and over crowded offices on programmers is studied in the book Peopleware by Tom DeMarco and Lister.

While browsing Steve McConnell’s book Rapid Development: Taming Wild Software Schedules over the week end, I came across this chapter called Classic Mistakes Enumerated. Steve McConnell* say’s that some of the mistakes are so often repeated (like adding more people to a project that is already running late or believing in Heroic Acts to salvage projects), that they deserve to be called Classic Mistakes. These are classified into four categories, namely

1. People related mistakes.
2. Process related mistakes.
3. Product related mistakes.
4. Technology related mistakes.

Following is the detailed list of those mistakes, listed under the four different categories.

People-Related Mistakes

• Undermined Motivation
• Weak Personnel
• Uncontrolled Problem employees
• Heroics
• Adding people to a late project
• Noisy Crowded offices
• Friction between developers and customers
• Unrealistic expectations
• Lack of effective sponsorship
• Lack of Stake holder buy in
• Lack of user input
• Politics placed over substance
• Wishful thinking

Process-Related Mistakes

• Overly Optimistic Schedules
• Insufficient risk management
• Contractor failure
• Insufficient planning
• Abandonment of planning under pressure
• Wasted time during fuzzy front end
• Short Changed upstream activities
• Inadequate design
• Short changed quality assurance
• Insufficient management control
• Premature or too frequent convergence
• Omitting necessary tasks from estimates
• Planning to catch up later
• Code like hell development

Product-Related Mistakes

• Requirements gold plating
• Feature Creep
• Developer Gold plating
• Push me – Pull me negotiation
• Research Oriented Development

Technology-Related Mistakes

• Silver Bullet Syndrome
• Overestimating savings from new tools or methods
• Switching tools in the middle of a project
• Lack of automatic source code control

I hope we get to manage most of the projects we do, by avoiding these mistakes and committing new mistakes (we all make them most of the time, don’t we?). Not only will the projects be successful, we also get to contribute to the History of Software Engineering, through a new mistake. Ok. That part was just a joke. :-)

I personally believe that the list is so comprehensive that any so called new mistake is actually a manifestation of one of the mistakes mentioned above.Most of the mistakes mentioned above are self explanatory. By understanding these mistakes in detail, I hope we won’t repeat these mistakes when we manage our projects.

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 [http://www.qsm.com]