Project Turnaround Specialist Challenge 1. The Project is Late.

I see this problem all the time. And I also see all the cliché knee jerk reactions to it: hiring temps (never works, Fred Brooks in “The Mythical Man Month” actually found out that adding resources in the middle of a software project slows the project down). Threating developers with dire consequences if they don't finish their tasks on time. And the crowd favorite, starting a death march with twice daily status meetings (one at 7:00 AM and the other at 7:00 PM) that everybody is required to attend.

If you are going to remember anything from this entry, remember this: Problems with the project schedule are the project's manager or team lead fault. You can't blame the team, can't blame vendors, can't blame senior management, can't blame other stakeholders. If you are in charge of the schedule it is your fault. Senior management will hold you and no one else accountable. Moving to the good news, you get a second chance to fix the project. If you read my last blog, you know you will not get a third.

This is what you need to do:

a) Find out how much work in relation to the total has been done. You need to be able to tell senior management with the backing of numbers that X % of the project is done. For example, if you are using Extreme Programming as your software process, you need to rate the user stories by difficulty and then calculate the teams user story velocity. User story A takes 1 unit of time, story B takes 2 units. Then if you are done with user story A, you are 33% done. This is the type of logic and numbers you will need to present to senior management to give them confidence on the state of the project.

How yo calculate where you are depends on your software process, historical data, etc. For example, you could a system like COCOMO II to get and estimate on time with an input of lines of code or function points. Again, this is not about how you calculate this number, there are countless methods, even I contributed to the literature with an article on how to use Design Patterns to Estimate lines of code in a project.

b) Once you know how much of the the project is done, create a new schedule with that number as a reference. The completion of the project will now be past the original deadline. With your numbers you can defend your position that the current scope will not be completed until the new date. If the stakeholders want a product by the original date the will have to reduce the scope.

This is the part in your negotiations that I call cliché storm. The stakeholders will come up with all kind of ideas on how to “motivate” the team to produce more. Be ready, read Fred Brooks, read “Death March”. In these books you will find suitable answers to most “motivational” techniques. Microsoft did a study to find out how many hours their software engineers really worked during the day. Because of the culture many engineers were at the office for 10 to 12 hours every day. What the study found out is that only 8 hours were actually productive, the rest of the time was used doing personal chores, gossiping, water cooler talk, etc. It is very difficult for an information worker like a software engineer to be productive for more than 8 hours a day. Find research like these on line and in books, be ready to show it.

If you can't sell the new schedule or reduced scope, your project is doomed. There is no “Magic Silver Bullet” (another great Fred Brooks book). New resources will not help, “motivation techniques” will not help (they will actually hurt because of turnover and poor quality to meet deadlines). You need to change the scope or the schedule.

Comments

[Nike Shox]

i agree with your views from here.

[Coach Outlet Online]

cooler talk, etc. It is very difficult for an information worker like a software engineer to be productive for more than 8 hours a day. Find research like these on line and in books, be ready to show it.

[Dr Dre Solo]

so good