A project goes off track 1 day at a time

http://www.dreamstime.com/royalty-free-stock-photo-flag-beach-image4485135If you have been in the software development business for a few years, you most likely were involved in a project where there were multiple technical challenges, lots of requirement changes, new requirements being added two days before the release and team members start blaming each other for bugs and mistakes. In the end, you had to work long hours and sacrifice week-ends to make it all happen.

Sounds like a familiar scenario? Don’t worry. You are not alone.

According to a recent research made by the McKinsey & Company on software development projects:

  • 66% go over budget
  • 33% go over schedule
  • 17% deliver less value then predicted

Despite these scary facts, few people are willing to admit the possibility that one of their projects may fail. The psychology is exactly the same as wearing a helmet while riding a bicycle or in-line skating. It’s hot, uncomfortable, and you tell yourself that nothing will happen. You have been cycling since your early age and you are now riding slowly on bike paths.

Most people don’t want to wear a helmet until they have witnessed or have been involved in an accident. This mostly occurs because of our past experience, overconfidence in our skills and ego. They may also feel that admitting the possibility of failure will distract them from achieving their goal.

Many project failures could be prevented if a business and technical risk assessments would be done prior the project’s launch. Once the project is launched stay alert, watch, listen for warning signs and be willing to take action.

The main issue with projects in general, is that there are only two statuses: On track, Off track. Just like the frog in the boiling water, you never realize your project is heading for the wall until it’s critical. Here are few reason why this is happening:

  • Trust
  • Estimations & buffer
  • Communications

Because of the creative nature of software development and with the arrival of new technologies, it’s very difficult to accurately estimate a project. You need to plan for unexpected issues, calculate the project’s complexity, plan your resources will executing the project as you estimate. This is very important since a person with less experience will take more time to accomplish a given task than a more experienced developer. Also, the quality of the work may differ due to the lack of experience. For this reason, you will have to plan more time for quality assurance. This is why project managers secretly add extra buffer’s just in case developers underestimate the time required. Finally, the product owner will most likely add more buffer just to be on the safe side. So far, the process is fairly normal since you can never be too cautious.

How did we get there?

As the project moves forward, various technical problems occur which may or may not be reported in daily status meetings. Most developers will wait until the buffer is almost all used up before raising the issue with the team lead. Some issues (technical or not), may be raised and fixed right away. Other will come back and haunt the project for a long time. Since the project manager & CTO have an overall buffer for the project, in the grand scheme of things individual issues are not really a problem until the buffer is entirely gone.

Upper management is known to be very patient and tolerant, until it starts looking at the project and realize the true progress or the overall budget. Only then, the project gets flagged as an off track.

The main issue here is that most people count their buffer as part of the overall budget/time allowed to complete the project or task. This results in people not raising the red flag until they start digging into their buffer or even worse when their buffer is no more buffer. In this case, raise the flag is too late. In reality, the buffer should not be seen as part of the overall budget but rather as an emergency reserved.

You should only pull your money out in case of emergencies or unpredictable scenarios!

How can we prevent overtime, headaches and project failure?

The very first rule, is to break down your large projects into smaller ones and do an estimate for each one. This makes it much easier to estimate and reduce the risk of the overall project.

When doing an estimate always provide 3 scenarios and color code them (green, yellow, red) : optimistic, normal, pessimistic. Reserve one column in your project management software for each of these estimates and track the progress. Closely monitor the progress or your project for any yellow flags. Request that any access to the emergency fund be logged and require approval by one of the superiors.

Here are a few additional things you can do:

  • Watch and listen for warning signs
  • Do not discard information that is accompanies each sign.
  • Keep the upper management in the loop and involved in the project
  • Be honest with all team members including upper management
  • Raise the yellow flag when you are at 50% of your allowed budget/schedule
  • Raise the red flag at 75% of your allowed budget/schedule
  • Get an unbiased opinion from someone outside the project or the company regarding the status

Keep in mind that a projects never goes off track in one day. It goes off track one day at a time.

Every time someone says this will only take a few extra hours to do or fix, it really means those extra hours will eat your buffer and that you may trigger the project to be yellow or red flagged.

What signs should you watch for?

Join me this October in:

  • Cape Town, South Africa on October 3rd-4th at PHP South Africa
  • Johannesburg, South Africa on October 9th at Tech4Africa
  • Budapest, Hungary on October 11th-13th at RuPy

You will discover

Can’t make it to those events? I will be publishing a book on the warning signs in IT projects soon.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>