How fundamental are the specifications

In the most popular models of software development, emphasis is placed on reviews that guarantee that the system meets the specifications of the project. But... Who checks that the specifications meet the objectives of the development?

Recently, the director of NASA, Michael Griffin, said in an interview that in his opinion the program of space shuttles was completely mistaken and that he believed that NASA's strategic plans has 'lost their way' in the 70s when they decided to terminate the Apollo moon missions. According to him, the shuttle program doesn't make any sense because it is based on vehicles that can only orbit the earth and isn't in line with the objectives of colonizing the moon and Mars that were announced by G.W. Bush in his electoral campaign.

This is noteworthy coming from an organization like NASA, a paragon of methodology and technology (not to mention science), but how many times have we seen this in the world of information technology? How many times have we seen strategic decisions go against the 'winds and the tides' and result in systems that don't have any relationship to the objectives of the business for which they were designed?

In some development methodologies we see evolutionary models (Microsoft and its MSF, or the CMMI model of the Software Engineering Institute among others) where systems are reviewed and evolved so that they continue to satisfy the requirements (objectives). But success at conforming with the specifications does not guarantee that the original specifications were appropriate for the real needs of the end users of the system.

There are techniques and tools, like JAD and others, that start in the analysis of users' requirements, and help launch development projects of the appropriate size and cost based on the needs. In my experience, these methods either are not used, or are used 'for show' in such as way that the possible benefits that could have been brought to the project are not realised.

Most methodologies, techniques and tools for system development start with the axiom that the specifications are the foundations of the system. Clearly, as in the case of NASA, this can lead to situations like that in the joke about a surgeon who came out of the operating room and reported to the patient's family, “Everything went splendidly, the operation was a success, but the patient died”.

Here are my principles for the period before starting a development project:

• Institute a cooling off period for the project sponsors. Sometimes management, caught up in a wave of enthusiasm, propose projects that begin to take off but end in failed developments. It can be better to look around before 'jumping in'. I think that this is a Zen principle (very much in fashion in new developments).

• Never put too much emphasis on a single contributor when collecting the requirements. If we base the project on a single viewpoint, we risk 'drinking from a polluted fountain'. We have all been in situations when the 'expert' assigned to the project takes more of a lead that he should, and from a desire to demonstrate his wisdom to the world ends up by sending the project into total disaster. Sometimes, the model so popular in American films of the inexperienced graduate having the 'good idea' actually occurs in the real world.

• Have a critical 'brainstorming' meeting about the requirements with the users and the sponsors of the project. This technique works better as a 'idea filter' than as a 'source of ideas'.

• Present the users with a version of the requirements that is written in everyday language. This leads both parties (the project team and end users) to begin talking about the same things using 'a common language', reducing the possibility that what is developed will be rejected by the users as, “This isn't what we asked for”.

These principles aren't a panacea, but as Napoleon said, “Dress me slowly because I am in a hurry”.

[Translator's note:
In spite of the fact that IT projects often affect the way in which a company operates (business change), I have often seen senior management announce a direction for an initiative and happily leave the definition of the project to the project manager. (Senior management, once they have spoken, tend to assume that it will happen and forget about it, only attending checkpoint meetings at rare intervals). The shrewd project manager then defines the project as something he can easily achieve. Unfortunately, management's intention and the project definition may not coincide. As an example from my own working experience, senior management once wanted the IT group to follow to a single in-house standard. The project manager should have addressed the numerous in-house standards already in existence that were not being followed. Instead, he defined the project to develop and communicate a new set of standards. The project was a complete success in these terms; it ran to time and budget and the new standards were communicated. But the company had yet one more set of in-house standards that were not being followed.]

Return to Extracts from Planeta Código

E-mail comments to: