The truth about managing software development projects: what's your strategy?

My previous post The truth about managing software development projects in two charts got buried quite heavily on dzone.com. User gfxmonk commented:

how is looking at two made-up graphs going to be of any use? The author doesn't even outline what was done differently...

while user Mihai Campean said:

Simply a poor written article...

I guess what was missing - in hindsight - is a proper conclusion. These graphs are based on the collective experience from several projects I've been involved with. It doesn't really matter how they were done differently.

The conclusion that comes with these two graphs is: what's your strategy? In other words: which decisions will you take to ensure the plunge will happen at the start of your next project?

That's an open ended question which if fine because how to do any project successfully is an open-ended question as well.

I ask four questions to help determine the strategy for each project that's started at my company:

• What will be done?

• Who will do it?

• How will it be done?

• What do we anticipate to go wrong?

What will be done?

To answer this question you need an reviewed, validated analysis. The best way to validate is to prototype potential solutions.

Who will do it?

Sure enough these are the people on the project. Do they have the right experience? What's their mindset? Are these people exclusively assigned to this project? How will management be involved in the project?

How will it be done?

What's the process? Which tools will be used?

What do we anticipate to go wrong?

Which requirements to we expect to conflict? How did previous projects with this customer go? Can we reasonably expect to make it within the available time frame and budget, with the available people and with the selected tools?

Conclusion

I find these questions a good place to start before asking any other. Unsatisfying replies are a sign of trouble which is why these questions are important. At the start of a project you still have time to maneuver.