Do you know where your developers are?

A few years back I was brought in to recover a project gone bad. The project manager was stretched thin across multiple projects and delivery of this one project was totally dependent upon one lead developer. The application looked disturbingly unfinished, but the developer assured everybody that the project would be done in two weeks. Two weeks passed with no result, and the developer again insisted that the project would be really, truly finished in two weeks this time, definitely. The second deadline disappeared without trace. Shortly later, so did the developer

The project manager was left in a desperately embarrassing situation. He had an angry, mistrustful client on the verge of terminating the business relationship, and no way of assessing the codebase to really tell how far from completion the project really was. How bad can it get?

Let’s jump straight to the answers: the project was actually six months from completion. There was no source control and there were no tests. I found 26 copies of the source code in folder names like Project_X_Final_Friday_v2_Copy_master and there were no tests. There was a document vaguely outlining business-level outcomes, but no kind of work breakdown, no estimates. Nothing that could be used as a measure of progress.

What could have been done to prevent such project carnage? Aside from at least putting in place some kind of source control, the PM could have done these things:

• Worked with the developer to break down the job into small pieces

• Estimate those pieces.

• Allocate contingency time for the “known unknowns”

• Ensure that for every promised functionality, there is at least one test (automated or manual) to verify it.

• Plan short sprints and review progress after every iteration

• Tick tasks off as they are complete (because they were small enough to be complete-or-not, right?)

• Verify everything claimed as complete actually passes a test.

• Compare elapsed time against the accumulated estimates for the fully-completed tasks

Each of the above is a simplification that represents at least a two-beer conversation (which I'm very happy to have, by the way), so I won’t even start to expand on that list.

However, even with the above in place, the project still lacked critical control mechanisms. It would have still been at risk because:

• The schedule was not synced with requirements change (so the estimated end date becomes quickly unreliable)

• The tests were not keeping up with requirement change (so "finished” could mean “two months remaining”)

• There is no way of capturing whether individual estimates were accurate (so, no idea whether the estimated end date is reliable)

• There is no way of knowing how the contingency allowance was being consumed (again, no idea whether the estimated end date is reliable)

• Project sponsors not being automatically kept up-to-date with requirements change (the project sponsor might not like the way the project has changed)

There were commercial risks left open, too. The timesheet system was pretty basic, so there was no ability to extract costs arising from customer change requests. And there was no foolproof non-repudiation mechanism to protect the team from the “I didn’t really ask for that” responses from the customer.

So, although the PM could have covered off that project to a much greater extent, he was also hampered by the methodology and the tooling of the day. There simply did not exist a software-specific project-management methodology (and toolset) to deliver fully-functional projects on time and on budget.

Sadly, in 2017 the same is still true. Just putting it out there...