The Wrong Questions

Walking around the office this last week, I've begun to notice some things I've forgotten about large bureaucracies built around IT projects. Everyone has great answers, but they're answering the wrong questions.

A couple of examples. We're collocated within a division who manage the development and deployment of large projects within the company. Walking through the office last week I saw a large poster of the "Rational Unified Process - Process Made Practical". Now I've never developed under any Rational process (or tools for that matter), but the idea of something that calls itself the "Unified Process" (complete with caps) struck fear in my heart.

In a previous role, we had the experience of receiving several functional requirements specifications that were not suitable to develop from. They missed several key requirements, did not accurately describe the current system and contained lots of diagrams that were nothing more that pretty pictures. One of these specs was a 30-odd page Word file that when distilled contained a page and a half of requirements in bullet point form.

Now, from a business point of view I'm sure these specs were of value, but for their intended purpose they were of little. The problem was, the documents were produced within a process that did not take into account their value to development, only on their adherence to documentation standards. In one case, the requirements had not been gathered from the customers, and the touch points with the function and capabilities of the current system had not been checked with those who knew it best. The document was derived in complete isolation, from a higher level document alone.

Now I don't think that anyone truly believes that we know how to develop software. Those of us who practice XP would like to think that agile is the way and the light. I believe it's a great step forward - and a step that practices self review and the infamous continuous improvement - but it may not be the best way to develop all software.

All in all I have the sinking feeling that there are lots of people are all busy doing a wonderful job that contributes little to the effective delivery of a software project. There are lots of great answers, but the questions being asked are not the ones that should be.