In this section I described this pandemonium where everyone is sharing, "show me yours, I'll show you mine", and in general providing feedback. I discussed the need for feedback, and some ways the feedback can be given. The result of it all is change. Changing requirements, changing realization of these requirements. I quoted before: "Unless the job has previously been done and only modest changes are needed, it is best to assume that the requirements are wrong."

There are several reasons why requirements change:

• Stakeholder changes his mind. By discussing, thinking about it and reflecting on the subject, a stakeholder can change his mind on what he wants.
  


• Project team interpreted requirements different than intended by stakeholder. Two people don't understand each other.
  


• "Forgotten" requirements pop up. During the project intake and the requirements determination the scope is determined and the initial requirements are written down. In this process you can forget one or two requirements that appear during the phase of feedback.
  


• Changes in the project surroundings. Things happened outside the project that can affect the project directly. A merger or reorganization, a new policy for buying supplies, a new law, etc. The fluctuation in the surroundings can change requirements. The longer a project runs, the more vulnerable the project is to this type of changes.

The software project manager has to roll with the punches; these changes are a fact-of-project-life, so he has to deal with it. However, to be able to construct something, requirements should be relatively stable, at least long enough to build and test stuff.

This stability, can be forced by not allowing changes to the requirements, they are frozen. Requirements in a project will have alternating periods of change and freeze. It's the role of the project manager to manage this process. It's called "change control": the process by which a change is proposed, evaluated, approved or rejected, scheduled and tracked.

The key issue is to install a change control procedure that forces people to go to one central point of entry for the project. E.g. project management will decide if a change in the requirement set is accepted or rejected. Only one person is allowed to change the set of requirements. This is one procedure I really recommend putting in place.

Links of Interest
The Secret To Coping With Change: MIND + NETWORK

In the previous section the main focus is on having feedback on principles, ideas and look-and-feel. You need this. But it's only the start of it all. While engineers are building the system (or merely configuring it), extensive testing has to be done. Does it work, and does it work properly? You might perhaps consider this as not being part of the feedback loop to the stakeholders, but consider the requirements "it has to work" and "I don't want to reboot my system three time a day". If these requirements are explicitly stated, you are lucky, mostly people assume that it speaks for itself (pity the poor fools!).

Technical software testing

As a project manager you have to be aware that testing happens. Not just checking if by pressing the button the wheel spins, but also looking if the roof is not collapsing because there happens to be some relation between the wheel and the roof (yeah, a far fetched example). Look if the parts are tested, and the whole of the parts. Don't trust developers if they say they don't need testing ("software is like bananas; they ripen at the customer"); it's a complex task and the discipline is just a few decades old. By the way, it is a discipline, that starts at the level of the individual developer.

Functional software testing

This technical stuff is all fine, but what happens if the system (or parts of it) comes available from the developers? You now have to test of it is functional. Does it perform what is supposed to, and in a way it is supposed to? It is the big final feedback to the stakeholders.

To do this properly you have to prepare in advance. Think of the real life situation of the system in the future, and come up with some scenarios that can be considered as an archetype situation. Try to write scenarios (including human aspects and handling) that cover all the major aspects.

When testing an editorial system for newspapers (the big word processors on steroids) role-play is used to construct all archetype pages, including someone writing, someone correcting etc. This is the big acceptance test. You need therefor to construct the scenarios with all stakeholders concerned. If the system passes the test, they just have to sign for final acceptance.

I ask myself sometimes disturbing questions like "You know the software business. You know how systems are built. Are you now comfortable, sitting in this airplane, 10km high in the sky, flying on systems that some software geezer constructed?" Uuuhhhr, honestly I don't know. The best thing is not to think about it too much.

What I know is this: after designs are made (or even during) software engineers have to try things out. They are not always sure that certain concepts can be done at all, or wonder how it will act in reality. To stay in the language used in this course: they need feedback on the parts and principles they are supposed to implement. And these trials are not always thrown away… like they should.

Pilot, prototype and Hollywood

Brooks has a very clear opinion on this matter:

The management question, therefor, is not whether to build a pilot system and throw it away. You will do that. … Delivering that throwaway to customers buys time, but only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down. (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)

You will create pilots for trying things out, but the pilots are focussed on this particular aspect that they are attempting to prove. They are not designed as a part of a whole, which makes them a nightmare to use in a complete system.

But before throwing them away, these exercises are crucial for your project. They provide at an early stage the first glimpses of the requirements in a product. If you take a trip to Hollywood you should visit the Universal Studios. There you can be guided through the studios. You will see all those little streets you can see in movies and TV series. Even standing before a building, you can appreciate the look and feel, you can sense the ambiance. If you turn the corner, you see that the street consists of only the front of the houses. Disappointed? No. The mock-ups serve their purpose.

A prototype is a mock-up of software, a Hollywood system. You can use it in an early stage to give users a sense of what the end will look like. Mostly it's just a window with buttons that don't do anything. But a user can mentally walk through the system. Don't forget to tell them it's a mock-up, to avoid later disappointment. Feedback time! And if they like it, get it signed!

Proof of concept and benchmarks

A couple of years ago I did a project where we implemented a system that consisted of multiple remote databases that had to be synchronized. Perhaps for you that is peanuts, but at that time we had no experience in this concept. Ok, it was done elsewhere, so it had to be possible. The supplier of the software had done a small exercise in this area with an administrative system they used internally for tracking the projects. It consisted of one central database and small databases on laptops of the engineers. This provided a perfect feedback to the customer that the concept could be done, a so called, proof of concept.

However, skepticism arose on the scalability of the concept. It might perform well with a few users and data, but how does this perform with heavy data traffic and hundreds of users? This matter was handled by building a pilot(!) that just synchronized databases with a lot of data, and a simulated workload of a user making updates and queries. The time it took for results came back for the simulated user, and the time it took to synchronize (and some other technical measurements) were used as a reference for the future system. It was considered a benchmark. Those measurements on the pilot were acceptable, so the system to build was regularly checked against the benchmark. It provided a feedback on the scalability and on how far the actual system was away from the acceptable measurements.

Plan it

The activities described on in this section, they will be performed. It is how software people must work, and it is how you can provide proper feedback to your stakeholders. Listen to Brooks: don't deliver the throwaway as a final system, you will lose in the end. It will happen, so plan it in advance, make it an official part of your project… Plan time to try things out, you will, anyhow!

Links of Interest
There Is No Box: Agile And Plan-Driven Project Management Do Not Exist

Once in a while we have these live debates of our government on television (remember I'm Dutch). It's a rare chance to see democracy in action. Party A states something. Party B is "in principle not negative in respect to the suggestion". Party C "can imagine an agreement with consideration of aspects that are currently not known, but could arise in the future, possibly, or not all." You watch this soap opera and you think they all agree. You thought wrong. Weeks later, they have the same discussion and you have the idea that they don't agree. Wrong. They do. Do they? And after four years of discussion we get a new government.

Links of Interest
Management And Meditation
Filter And Drainage – Trust Running Through The Team

Ever have this meeting where during the meeting you are quite sure that you know where the other guy is standing? That you exactly know what his opinion is? You walk out of the room, you drive home and you reflect on the meeting and can't remember an exact statement that supports your feeling? If you haven't, just do a software project and you will.

Get it signed!

It's very important that the stakeholders get the feedback from the designers, but it is in the same level of importance that the project manager gets the feedback that the stakeholders were happy (or unhappy) with what they saw. Don't forget, you, the software project manager are also a stakeholder, and you should also take care of your stakes. You have to make sure you make progress within the project. That small steps are taken in the right direction, and you got to have this feedback in a non disputable way. You just have to get it signed!

After some feedback to the stakeholders, let them sign that they agree on what they saw. That what they saw, takes care of their requirements. If they state "That's a nice design", your answer has to be "That's nice, please sign here." If people are forced to make a formal commitment to a piece of paper (or electronic equivalent of paper), they read more carefully before they commit, and after signing they stick longer to their statement. It's not a matter of cost, we will handle that in the next section, but it's a way of getting some stable points in an otherwise dynamic (or chaotic) environment.

Get it signed!

Of course, the procedure of what to sign should be in relation to the size of the project. It doesn't make sense to sign every paragraph, but don't wait until the end, when everything is ready. Get intermediate approvals.

In some weird way, most people are reluctant to put their commitment on paper. It's just a signature. But the request alone can be considered an insult. "My word should be good enough for you." Well, actually it shouldn't. Never trust a used car salesman who says "trust me". If you can't get in place a good approval structure, leave the project, go home, you loose in the end. Every one will bend and twist and everything will move consistently, with the exception of yourself. Remember, you are a stakeholder, so take care of your own stakes.

While you are in this process, just think of one thing: GET IT SIGNED!

After reading the previous section, I know you get my point. However, I will spend some more text on the matter, because it's too important, and the natural tendency within software projects is to consider software design documents as a product of their own. "We design to create a design." Wrong, wrong, wrong. A design is a medium to tell how the requirements will be translated to the real world. And there lies the problem for project management with specifications and designs; the designs are considered to be a word passed from one technician to another. The global expert, tells the detailed expert, who tells the developer what to do. And they pass their message by the medium 'design'. They leave out the non-technicians, the 'normal' people…

During the actual construction of the design documents the software project manager will not be involved too much in the discussions. And if he is, it's not because he has the role of project manager. The biggest challenge for the manager is to make sure the communication to the stakeholders is done effectively and timely. He should make sure that once in a while the software gurus come out of their cave and tell in understandable words what they are envisioning. These discussions are legendary, two different worlds meet each other. Try to order something in Paris and you catch the drift.

Enhancing the chance of success

The project manager can do something to enhance the chance of success of this process. First, to be aware… and that you are now. Second, the choice of the guy or gal leading the design activities should not be solemnly based upon his technical know-how, communicative skills weigh even stronger. And, last in the 'open-door' series, take more time for the software design documents than you think you need. Take the time to create designs. You will earn it back later on. However, use the extra time for communicating with the stakeholders, not to make your graphics look more slick.

The communication between the designers and the stakeholders can take place in workshops and other kinds of meetings. So, the project manager, that means you, can check if such meetings are planned and held, or can even actively schedule such sessions or emphasize the need for them. After such a meeting is held, schedule a talk with one of the stakeholders to see if he got the information he wanted.

Document it all

To ensure that the information is presented in such a way, that the stakeholders can understand the specifications, the designers should keep track of all the decisions they made, and, more importantly, the arguments why they made a certain decision. If they decide to use Super XMLParser sub-system GNA (don't try to find this one) somewhere should be recorded that they intend to use it, and further more, the arguments on why this sub-system and not an other one. If they talk with normal people, then at least they can keep up the appearance of knowing what they are doing, to be aware of their actions.

But stakeholders just want to know one thing: "What the heck happened to my requirements?" So, the next log the designers have to keep is the one containing relations between the design decisions and the requirements issued. A paragraph in a design on the generation of an error log file in HTML on some server, should be linked to have an "easy to access medium to verify incorrect responses of export to the other system." The latter being an example of a requirement. In preparation for one of the feedback meetings a designer just has to see who's coming, extract their requirements and present the information on what he did with them. That's feedback especially tailored to suit you.

As a closing remark for this section, remember that designing is an iterative process; you design, you discuss, you throw stuff away and put new consideration into it. You win some, you lose some. Keep this in mind, when you design the process to perform these activities. Brooks (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition) even states that you have to plan to throw one away. You will in the end anyway!

The first requirement is put up by city hall: the art piece should reflect the struggle between man and the water (we live at the coast you know, 'the struggle between man and the government' would be more appropriate). Next, ten artists are asked to put in their suggestions. Vague drawings of holes and squares, circles and sockets, black and blue blurbs. Intended is that the inhabitants get an idea of what they can have in front of their doors. Everybody can vote (I make no funny remarks about the US 2000 elections, and that's difficult).

The three winners go to the next round. They make a detailed work drawing of the actual construction of their art piece. Is it steel? Is it placed in water? Is it green? Is it ugly? Based upon the final drawings the government chooses. Steel, water, green, ugly? Yep, yep, yep and yep again.

Software design and requirements management

You know, creating a piece of software is also a work of art. Luckily there is no voting with the residents, otherwise no system would ever be build. But the mechanism of taking a requirement and creating first a global drawing and afterwards a more detailed sketch is similar. We wouldn't be fair to the profession if we hadn't a great name for it: a design.

If we have good requirements, they will not say too much on how a system should be built. It should provide us statements on what it should do, in what context, and perhaps, sometimes, how it should be performed. All technicians that read the previous chapter would have wondered "where is my design?" Well, here you are.

Designs are in fact a way of communicating how a software system should be constructed. They are a description of what will be the end result. In this way, it's one of the earliest points in time, when stakeholders can see some glimpses on what is done with their requirements. So, when all the techies go to work, the project manager should make sure they maintain relations between the design choices and the original requirements.

Global and detail

What is global and how deep is detail? There you got me. Draw a line somewhere where you feel natural. If you look at a system as boxes, the global design places the boxes within a certain context, and their dependencies. The detailed design fills the boxes.

Another way of looking at it, is by functional versus technical aspects. The first design (or specification, for now the differences are too tiny to discuss) masters the points on how to handle the system from a user perspective; what should the user do and what will the system do? The second phase covers the technical implementation of the functional one. What data to manipulate? Which file to copy where? This approach reflects the opinion that techies can never lead the design process, the functional aspects rule!

Any way, you start your translation of the requirements to the real world by making designs or specifications. It is of course a communication tool for the technicians within their own species. But stakeholders want to see what happened with the things they yelled, and this is their first opportunity, so you better take care.

Related Links
Big Design Up-Front

How many times did you bring your car to the garage for a check up, to hear later on from the mechanic that he took special care of the noise he heard? You are going deaf, or this guy is hearing sounds that are not there, anyway you have to pay for this extra 'service'.

How many times are kids getting a dog because "I wanna doggie" is yelled by some 10 year old, so that the kid can later realize he didn't want the doggie itself, but the soft feeling of fur? You may think you want it, to find out later you had no idea what you were actually wishing for. Having the kid itself falls into this category.

How many times must a man…

Meanwhile, back in the jungle…

In the jungle of software project management the fierce full application developer is searching for requirements. After a good hunt he is dragging a bag full of statements back to his cave. There he grunts for weeks, he picks every requirement up, looks at it, smells it and takes it apart. After months, the creature sets foot for the first time outside his cave. The daylight is hitting hard on him. With him he drags a large ball made out of pieces of requirements. The pastry is the results of his craftsmanship. He shows it to the rest of the tribe. Holding it up, shining in the sun. The tribe leader looks at it, smells at it, sets fire to it. Anthropologists are still trying to figure out, if the leader communicated his disapproval or that he provided warmth to the tribe.

Expectations

The central issue here is "expectations". You imagine a certain situation in the nearby future. You close your eyes and you can actually experience it. You open them again, and try to describe what you saw to some one else. He will hear the same words, the same sentences and you might even share the same enthusiasm for it. But if you both think about "a nice woman" or "a nice man", you both having the same warm feeling doesn't guarantee you that the color of the hair of the imaginary friend is identical. It probably isn't. Communication is always influenced by interpretation of a person. Requirements in a software project are not different in this respect. An "easy to use interface" can be interpreted in hundreds of ways.

So, there is nothing you can do? Wrong. You can do a lot, but it will take some effort. You can provide feedback by using a mechanism, which is not affected by interpretation, or at least less affected. Exchanging pictures of your idea about "a nice (wo)man" can solve the hair color issue. There are several available you can use on the product requirements of a software project. And that's what this section is all about.

Good idea, bad idea

It's not only the talking with people that can cause problems. It's also your own imagination that plays tricks on you. What may seem nice in your head, me be in reality a disaster. Even if the other person understood you correctly. Feedback is also here the magic word. It can help indicate that you, or any one else, was wrong with his idea of the future at a relatively early time in the project.

Requirements validation is all about feedback. Is the interpretation of the requirements to the real life situation correct, and, are the requirements still valid? It's now "feedback time"!