Recap

I've frequently been called in late in the software development cycle when projects are in trouble. Often, it is difficult at first to judge the depth of the yogurt. Usually the developers are focusing on how much they are "behind," as measured in things that are coded but just don't work, and things that are not coded at all but should be.

While this is one important aspect, I always begin to also look at the health of the build process. If the build process is non-existent or badly broken, it needs attention immediately. The reason for this should be obvious; at this stage of the proceedings, the lack of a reliable, repeatable build process will impede all further progress. You can't test what you can't build, and repeated testing is a necessity at this point; else, how can the developers know what they've fixed and what remains problematic?

Sadly, in many organizations the build process is something that is relegated to the B Team. This is a huge mistake. You must have A-list players in this part of the organization. As soon as people understand how much you as the senior manager appreciate the contribution of this team, you will have no problems getting volunteers.

The other thing that proves very slippery is answering the question, "How do we know when we are done?" Getting agreement well in advance on some clear criteria is incredibly useful; such agreement reduces the odds that the bar will move radically up or down as the ship date looms. One of the major objectives when moving into the Transition Phase of iterative development is to define reasonable criteria for shipment. Without a clear "exit plan," the project risks a series of never-ending last-minute slips.

Thus ends Part 2 on the basics. In Part 3, I will look at software development from a project management perspective.