Skip to main content

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.


  1. Nice article and seems a reasonable list of mistakes (Often they are realized as mistakes only after the fact)

    - Adding people to a late project(or is it adding people late to a project: What are the options available to a Proj Manager to bring the late running project back into the schedule?

    - Feature Creep : Given the market conditions, this is certain to happen for most projects. The question is how to allow or plan for feature creep in the schedule rather than calling it as a mistake and attempting to avoid it altogether.

  2. question: Adding people to a late project(or is it adding people late to a project: What are the options available to a Proj Manager to bring the late running project back into the schedule?

    Please refer to my article on Trying to understand why projects fail at the following link.

    There are two good options available to a project manager. one is decreasing the scope of the project, so that you deliver on the agreed date a project with decreased scope. This is the best option available to all the stake holders if acceptable.

    The other is modifying the end date of the project and delivering the entire scope on a date that is much later than the agreed date. Usually this option is not used as projects, if delayed have a business impact and hence the sponsors dont want the delivery to be delayed.

    The bad choice.

    The third option that is usually chosen is keeping the scope and the end date as the same and adding more resources. But what managers usually forget is that communication is an over head and there are other factors that people tend to overlook ( they look at everything in an optimistic manner) because of which the delivery date that is usually expected to be met is not.

  3. Feature Creep : Given the market conditions, this is certain to happen for most projects. The question is how to allow or plan for feature creep in the schedule rather than calling it as a mistake and attempting to avoid it altogether.

    It is true that as a project manager, you have to expect that change will happen and plan accordingly. The important point to note is that we have to differentiate between wanted changes and un wanted changes and ensure that the wanted changes alone happen.

    Also, note that if it happens to our knowledge, it is called Change Management and not feature creep or scope creep. :-)

    If it happens without the project manager being aware, it is called feature creep or scope creep.

    If you have a good change management process in place, then you can ensure that feature creep doesnt happen.


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 …