Andrew Stellman and Jennifer Greene have an article in the June 30th Dr. Dobb’s Journal on a topic they call “Quick-kill” project management. This is a technique they have distilled for managing projects on impossible schedules. I think “distilled” is the right word here, since the three components of the process, vision/scope definition, work structure breakdown, and code reviews are certainly not new. The authors of O’Reilly’s “Applied Software Management” are well-qualified to advise on the topic of managing to ridiculous timelines, but I do have one or two quibbles with their recommendations.

My biggest issue stems from the tactical nature of their approach to handling high-pressure development scenarios. I don’t have any problem with the constraints on their artificial example, i.e. finish the project to management’s timeline or lose your job. We can agree that a higher level strategic approach of trying to educate management falls outside the traditional boundaries of “project management” and is something that should occur at stakeholder level earlier in the game. However, let’s put this whole thing in proper perspective. We can start by throwing out the latter two steps of their process. Work structure breakdown (what I would have called functional decomposition and module design) and code reviews are entirely tactical efforts. The authors are right that, in the presence of relatively decent requirements, decomposition can be done in a few hours. Code reviews are also a good thing. Neither, though, have much to do with the basic problem.

That problem can be stated as follows: the aspiring owners of the system want more than can be accomplished in a given time, and understand less than they need to about what functions are really essential. Stellman and Greene assign an estimated 6 hours to the task of dealing with the last component of this issue: incomplete requirements. They achieve this by limiting the analysis to the level of “vision/scope.” Now abstractions are funny things. The higher level ones are attractively easy to define and manipulate, but leave impressive amounts of wiggle room when it actually comes to construction. The key is, as they point out, assumptions. But rather than focusing on the tactical assumptions as they do (i.e. whether a given function needs a command-line or GUI interface), I would suggest that it is the strategic assumptions that kill projects.

An incomplete analysis is an incomplete analysis. You can call it anything you want, but it represents a lack of information that may be critical. Agile methods suggest that we can begin with this, and drill down. I agree. The authors suggest that in the presence of ridiculous timelines you can make do with an incomplete analysis, and on that point they are only sometimes right. I say this because there are cases where a smart team of developers can “get to the heart” of a problem by interviewing a few key users and then factoring out a system that achieves a certain vision of a problem space. The system gets deployed and the users, who never fully-understood what they were trying to achieve, are happy with it. This happens, and fairly frequently, but it can only happen with something that users don’t completely comprehend. As they become more knowlegeable they become more specific in their desires. Try this approach with building a house sometime, and see what happens.

But there is another case where this method fails dramatically. In that case a system must meet key functionality markers. These markers might be process-oriented, compliance-oriented, legal, financial, etc. In a large organization the knowlege of these functions may be distributed through different facets of the company. Some of the know-how might be in accounting, some in IT, and some in audit, for example. These users all know exactly what they need, but nobody has the whole picture. Identifying the scope, and using this to locate and interview stakeholders, is something that takes a lot of time, and for just about any non-trivial system you would be hard-pressed to get a good start on it in six hours. You then have to iterate as you design, because even the most gifted software analyst is not going to get Truth all the time, from every interviewee. It is these misunderstandings that kill projects, not debates over how to implement a data access layer.

None of which is to suggest that I don’t find value in the piece, and in the authors’ viewpoints. I do. But this happens to fall squarely in the middle of one of my pet peeves about software development: people do not understand the stuff. If someone asked you to build a house on a ridiculous timeline, would you: a) promise it to them based on a high-level “vision” of what the house should be, then build it and hope they liked the end result; b) promise it to them knowing full well that they will constantly revise the design and will take delivery much later than they expected; c) tell them that the goal is unreasonable, and try to explain why. In many companies the answer is (a) or (b). In most it should be (c), but I understand that in this case the owners may just call another contractor.