« Managing Risks of Fixed Schedules
Selecting Project Managers - Project Management As it Ought to Be »

Don’t Add Developers to a Late Project

September 30, 2007 | Author: admin | Filed under: Resource Constrained Projects, Performance Reporting

Don’t Add Developers to a Late Project
By David Carr

In my experience, there appear to be three types of manager when it comes to a project that looks like it is about to overrun. Here is my simple classification:

Panic Manager

This manager sees a project that is about to overrun and starts adding resources and chopping back on testing. We know that it is bad to cut back on testing; those bugs won’t find themselves! (No, the customer will find them and then our late project will become a late, inaccurate project).

Used-to-be-a-Programmer Manager

This chap knows the problem. However, he has bigger managers above him that like to twist the screws, turning him into a Panic Manager.

Pragmatic Manager

This manager is a useful ally. She will contact the customer, manage the problem through, deliver slightly late but everyone will be (reasonably) happy with the end result.

OK, I have seriously over-generalised here so what is my point?

I have just witnessed the completion of a reasonably small project with two developers providing the coding and one project manager. The project overran but the project manager was scared of the customer and so used the get-out clause of “let’s add more development resource and speed the project along.

The metrics for the project made very interesting reading and a mathematical argument for why you should not add developers to a project that is running late. Here are the facts of the project.

The project was estimated at around 100 days of development, including testing. As there were two developers available and these developers are also involved in third line support, it was deemed that they could be 60% efficient. This means three days per week each. A simple calculation:

100 / 6 = 16.7

The project was therefore planned to take 17 weeks. This was a key mistake as there was no contingency time planned. However, the project progressed on this basis.

During the first couple of weeks, the programmers reported that everything was on track. In fact, most jobs were not being completed. The programming was done but the testing was not to the expected standard (if done at all).

This continued for several weeks with the programmers still feeling that they were on track. They had evidence to prove it in bunches of UML diagrams, developed classes and screens, etc. However, all was not well and programmers can be far too optimistic.

After ten weeks, 60 days of development should have been completed, unit tested and debugged. This was when the project manager finally understood that things were going wrong. The current build did not build. The parts that did showed obvious bugs and flaws and on further examination it was determined that only around 50 days of development on the project had actually been satisfactorily finished.

This is the point at which the project manager needed to communicate with the customer and both parties needed to show a little pragmatism. Unfortunately the project manager discussed it with the team, added a few harsh words and under pressure, the programmers said they thought they could make it up.

Two more weeks passed and the 60 days were done and tested. However, by this time 72 days were needed. The team had now slipped by an additional two days. This is were the mistake crept in. The project manager did some poor maths and decided to add another developer.

Here’s the theory:

  • We needed six days per week but got only five.
  • We have forty more days to deliver and only five weeks left
  • With three developers we get nine days per week
  • Nine days per week for five weeks gives forty-five days; we win!

The first two items above are fact. The last two are fiction and are for people who only believe in fairies. So what actually happened?

To the amazement of the programmers and the project manager, no work was achieved in week 13. Unlucky for some but obvious to others. All of the time was invested in getting developer 3 up to speed on the design and the code. Developer 3 also made mistakes that had to be rectified with the assistance of the original team. This pattern is not unusual and not a reflection on the developers. It happens 99% of the time in my experience.

For the remainder of the project, the programmers achieved an average of five days per week. By adding a third developer the company achieved a zero improvement on output. Nobody could explain where the time went. It just went. Again, not at all unusual.

The end result was a project that was delivered almost four weeks late. An overrun of over 20%. In addition, we supplied additional development resource that could have been earning fees. The customer was unhappy and the team was unhappy. The project manager was bemused. All of which could have been solved with a little up-front communication.

What made it particularly unfortunate was that the customer sees this project as a failure when actually it was a success. The product delivered is performing well in testing and is looking like it will save the customer’s business many tens of thousands of pounds.

If there is a moral to this tale then it is this. Adding resource to a project that is running late will make the project run later. If you are to add resource, front-load the project. That is, plan for many more developers than are needed at the start of the project so that you can over-achieve and build a contingency.

David Carr is a Software Development Manager responsible for team management, project management and software development using Microsoft technologies. This article was reproduced with permission from his blog, which can be found at http://david-carr.blogspot.com/.

Article original source: http://david-carr.blogspot.com/2007/08/how-to-say-no.html

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

This entry was posted on Sunday, September 30th, 2007 and is filed under Resource Constrained Projects, Performance Reporting. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories