The truth about managing software development projects in two charts

If you're running a development project or are working as a developer or architect or designer then you may want to take a look at the following two graphs.

The first graph shows a project in trouble. Especially pay attention to the red line which indicates the amount of trouble a project is in.

At the start of a project you're in a lot of trouble. You have to start building software and you don't have anything yet. At the end of the first month you have something. Next month you have some more.

But as the weeks and months go by the amount of trouble your isn't really reduced in a significant or useful way. If your project takes 12 months then by month 9 or 10 you should have a clear view on how to complete the missing features.

As you can see on the graph this project doesn't know how to manage its trouble. There can be several reasons why there is lack of progress:

1. Moving target, the customer can't make up its mind so you can't agree on the specifics that have to be delivered
2. You don't have the right people, developers and management don't have the right experience.
3. No leadership, management doesn't know how to deal with a bunch of developers.
4. No process, you don't really know how to successfully deliver software. Since you have no process you can't foresee what will go wrong during the course of the project.
5. You're not properly organized, related to point 4, you don't track bugs (properly), you can't successfully use version control, you don't build, test and release often enough.
6. You don't test, because you believe writing tests is a waste of time.
7. You don't know how to test, because that's not always easy and requires experience, leadership and constant follow-up.
8, You underestimated the amount of trouble you're in so the time you have to finish the software is not enough from the outset.

Hey, the profession of delivering software in team is not easy. The second graph shows a project that knows how to manage trouble.

Notice that at the start of the project the amount of trouble your in (red) takes a sharp dive. After this initial effort you have the time to complete the feature that are missing.

This is what you want. However, measuring the exact amount of trouble that remains is no child's play. It requires a lot of tests that are easy to maintain, regular releases and regular execution of tests, regular communication with the customer.

Also notice that the number of people in your team (green) and the remaining budget (blue) are unaffected by how you manage the trouble you're in.