Sequence diagrams express interactions among classes in terms of messages exchanged for a period of time, and, as we've seen, they fall in the category of interaction diagrams.

When you're done with the robustness analysis, you have defined most of your objects, their static relations and some of the dynamic relations. Now it's time to refine the diagram again, and to bring it closer to how the actual code will look like. Sequence diagrams can also be used to validate use cases.

You have four types of elements in a sequence diagram: objects, methods, messages and text. You will take the objects from the robustness analysis, and you can include their class, if you need to. The methods are shown as rectangles, while messages are arrows (messages are what stimulates an object to perform a certain action). Finally, the text comes directly from the use case.

This is the moment when you're most likely to get stuck, particularly if you've made mistakes so far. Make sure you allotted enough time to this stage to go back, if necessary. You will definitely need for attributes - check them out carefully, particularly if you plan to skip the class diagram and to move directly to the code after this.

When you draw the diagram, leave the methods last. You will need to check them with the controllers from the robustness analysis, but remember that one controller may translate into more than one method. Also, this is where you may decide that you can use some patterns already available, or that you can create some new ones that would be helpful.

As long as the use case diagram corresponds to the robustness analysis and the analysis corresponds to the sequence diagram, you are following your requirement specifications and will obtain what the client wanted. Otherwise, go back and see what you've done wrong. You cannot be sure that you've covered everything until you've drawn sequence diagrams for each use case, and then check the diagram with the text from the original use case, just to make sure that you didn't get "lost in translation".

Check your message carefully, and make sure that, for each of them, you understand which object is in control (and why, for all that matters). This is where you make some crucial decisions for your code - try to estimate how long a method takes, and if there isn't a shorter option available. Also, check the potential blocks or bottlenecks where your application will choke, and correct them at this stage. The sequence of the diagram is no longer an abstract drawing - this is what your code will also look like. Make sure you apply correctly all the principles of object-oriented design - you can't enforce them later on.

When everything was checked one hundred times, you can move on to the class diagram - which describes the types of objects and the relationships among them. It used to be called "object model", because this is exactly what it does - it models the class structure and content. This is the actual model of the code. All classes have names, attributes and operations, and the relations among them are the typical ones, such as inheritance, association, aggregation and containment. For complex classes, you can use a statechart diagram.

The use case diagrams are, of course, commonly used in the requirement management process. The use case diagram describes the relations among actors and use cases - and these will be the two main elements of this diagram.

You should not confuse the actors with personas - a term first introduced by Alan Cooper in "The Inmates are Running the Asylum". A persona is an embodiment of an imaginary user, described quite in detail (his tasks, goals, knowledge level, skills, you can even name him, if you want).

It is safe to say that a persona is to an actor what is a usage scenario is to a usage case - an instance, or a "snapshot". If your marketing department has some statistics or demographic data, this is the place to use them. This may look like an office game, but correct use of personas can alter your perception of the application considerably. For instance, think that you have two users who have to perform the same action (two instances of the same actor), but one of them is computer illiterate, while other uses the computer regularly. And perhaps a third persona, who is a familiar with the previous version of your program, as well as with the software from your competition, because he has worked in this field all his life. They are the same "actor", but their interactions with the application will be completely different. This will give you a pretty good idea how the users react. If you use them, make sure you create the person before, and the use case later, based on the persona. You don't need to write all the possible scenarios - in fact that would be impossible - but make sure you include some of the most likely failure options.

The use case diagrams are quite simple and intuitive - they include the actors, the use cases and the boundaries of the application. Actors are always placed outside the boundaries, since they will always be external to the application. You can use lines or arrows to indicate the relations among them - in UML, indicating the flow is not mandatory. You can also compile an additional glossary of the terms used in the diagram, which may prove useful later on.

The key word in this phase is always "interaction". How the actor interacts with the application, what the application detects and what is its response.

When you are satisfied with the use case diagram, or everybody has had enough of the brainstorming for creating imaginary friends, you need to check the result using the robustness analysis. If everything works well, you can move on to the sequence diagram, if not, you can return and work on the use case diagram some more.

For the robustness analysis you need to identify the objects (which are still depicted in the form of literary text in the use cases) and to divide them into three main categories: boundary objects (that the actors use to interact with the system - interface, menus), entity objects (which belong to the domain model) and control objects or controllers (these aren't necessary objects, they connect the objects from the previous two categories; also, they are used to localize and store changes, sometimes, they disappear when the process comes to an end).

There are two main reasons for performing the robustness analysis: to check that you didn't let yourself carried away with the use cases and include actions that could not be performed by the respective objects, and to refine the model obtained, if it proves correct, to bring it closer to the design stage.

Now, in order for the robust analysis to validate your use case diagram, the relations must be in the correct sequence: the actors can interact directly only with boundary objects; boundary objects interact directly with actors and controllers, controllers can interact with boundary objects, entity objects and with other controllers, while entity objects can only interact with controllers.

Some quick hints before you get lost here: if you wrote the initial use case correctly, in the active voice, you probably find a lot of sentences that include the sequence Subject - Verb - Object, which, in the robustness analysis, corresponds with the sequence Boundary object - Controller - Entity object.

Usually, you need between three to five controllers per use case. If you have fewer, you probably didn't include all the options, if you have more, you need to break down the use case is smaller bits.

When you're done and everything falls into place, you can move to the sequence diagram.

We have mentioned UML a couple of times before, it's time to take a look and see what it is.

UML stands for Unified Modeling Language - a standard language for specifying, constructing and documenting all sorts of systems, software or other types. UML was initially developed by James Rumbaugh, Grady Booch and Ivar Jacobson in order to give all developers a standard communication language in which they could discuss the general architecture of the program and the best solutions available. As it proved a remarkable software design tool, UML became the official standard for software architecture in 1997, after receiving the support of the biggest names in the industry, such as Microsoft, Oracle and IBM.

UML is independent of any programming language, but it encourages the use of object-oriented tools. The notation is big, but very flexible - that's the idea when being "universal", of course. So, UML is a notation - not a methodology, not a process or anything else, and that's important to keep in mind. You will still need a modeling process, and how you approach it is entirely your choice. Basically, UML defines a number of diagrams and their meaning. It may not seem like much at first glance, but it means you've never had to work with large teams of developers - who, basically, speak different languages, making communication impossible. Each diagram was created with the purpose of allowing all the developers, as well as the clients, get a view of the system. How abstract is your representation is your decision alone.

There are twelve standard UML diagram types, which fall into three categories. The model management diagrams include Models, Packages and Subsystems. The structural diagrams include Class, Object, Component and Deployment. The behavior diagrams include Use Case, Sequence, Activity, Collaboration and Statechart.

These diagrams should not be scary or confusing, on the contrary, even if some of them may get really big. Keep things simple and organized with some very simple tricks. For instance, use colors to draw attention to one thing or another. Don't let your lines intersect, this is messy and confusing. If they must cross, use a "bridge" to show that they do not intersect, in a three dimensional view. Make a different diagram for the primary structure and behavior and then move on to present the details on a separate diagram.

No matter which method you use, it's generally a good idea to start with the dynamic models, such as the use cases, ad to move on from them to static models, such as class diagrams. In this way, you won't have to "guess", by looking at the static model, which class could be used for which operation. The use cases, which are driven from the real needs of the clients, will guide you through the process. Also, in this way you will make sure that everything can be easily traced back to its origin quickly.

The UML 2.0 specifications are even more focused on architecture and will allow even easier control and organization, with the introduction of Infrastructure, Superstructure, Object Constraint Language and UML Diagram Interchange.

If you've been around for a while, you've probably heard about patterns. As the name implies, patters help you cut time and costs by re-using the same solution, whenever the same problem occurs. So, a pattern identifies the problem and its context, and the best possible solution to it, in such terms that you can apply it again whenever necessary. In software design, patterns can be lines of actual code, but, more often, they are a textual description of the solution.

The pattern craze originates in 1977, in Christopher Alexander's "Pattern Language", and has continued since, with patterns used when they are necessary, and sometimes in excess, just to show off. A pattern language is the collection of the patterns used to address a bigger problem, such as, in our case, requirements management. All the stages necessary for solving a problem, as well as the actors, objects and tools necessary, are described in the respective process.

There are some tricky issues in using patterns. First of all, you have to identify them - which is done by analyzing the case model or the event response. When you have a pattern, you need to define it in such a way, as to allow instant recognition whenever you are faced with the same problem again. This is done by using several modeling methods, sometimes combined, in order to avoid the work of re-analyzing and re-defining a pattern, once you have already dealt with it.

Because they are not bits of code, but literary descriptions, the patterns are very flexible, and can be modified and adapted as the context of the problem requires. You should not think of a pattern as a solution to your problem, but rather as a step-by-step guide to solving the problem.

There are many good books out there that contain very useful, common patterns. You should start by reading some of them, until you are familiar with the concept, and able to identify at least some of the most common patterns. "Design Patterns: Elements of reusable Object-Oriented Software" by Erich Gamma, Addison-Wesley, 1994 and "Object-Oriented Software Engineering - A Use Case Driven Approach" by Ivar Jacobson, Addison-Wesley, 1992, are two very useful books for object-oriented developers. "Data Model Patterns - Conventions of Thought" by David Hay, Dorset House, 1995, provides a wider background, with solutions for different types of businesses.

Since the key to using patterns it to think abstractly, you'll need to do a bit of reading in order to familiarize yourself with the concept, and to understand how to make useful abstractions from a given problem. It will be a while before you can use patterns efficiently. In most cases, you will not be using the patterns created by other people, but your own, the ones you have been faced with before, because these are easier to remember and, probably, specific to your line of business. Usually, a pattern is considered as such when it has been used for at least three times to solve a similar problem. On the long run, patterns can save you a lot of time, but the main problem is that you are probably running a tight deadline and under a lot of pressure from the very beginning, and thus you don't have time to look which pattern should be used for which situation.

All patterns look a bit similar, even if they are literary texts. All of them have a name - if you are able to name them suggestively and consistently, you are more likely to find what you need quickly. They include a description of the problem, of the context, and of the intent (this is actually a sentence or two about what the pattern does). Then you have the so-called "forces" - which are a bit like guidelines for how to implement the solution. They help you keep everything in order and under control. Of course, you have the solution, since this is the whole point, and the resulting context, which describes the state of the system after the use of the pattern. You can also include examples and samples of where you've used the same pattern before, in order to make things clearer. Try to keep your document as short as possible - you don't want to read a short novel, when time is of the essence. A good method to identify when a pattern can be used is to match its name, or any other of the above elements, to patterns already created (assuming you've named them correctly and consistently) and to check if you apply it to the given situation.

In writing software requirements, patterns are useful precisely because you don't have a lot of time to complete this stage. We've seen how important it is to prioritize your requirements, but this is a time consuming process. Sometimes it's a good idea to use a pattern to do this for you, in the same way as emails are prioritized according to different criteria. Another pattern available for the requirements is called Presentation, and it allows the display of data, when it is necessary to communicate it to human users. The Presentation pattern was created in order to allow you to focus on what data must be displayed, and not the method how to display it.

As you get more experienced in the use of patterns, you are sure to create some of your own, custom made for your specific needs and easy to identify and use whenever necessary. It may be a while before you can use patterns for their full benefits, but then you'll see it was worth the patience.

We've seen before that you will need to take some vague specifications from the client, and turn them into complete, measurable, traceable and unambiguous requirement specifications. No need to panic; you can make your life easier at this point with a use case report.

A use case is used to define a series of interactions between external actors (the users or another system) and the system in question (your piece of software). The use case always focuses on a goal, and it ends when this goal is completed. Besides the main series of interactions, it can also include alternative versions (other series of interactions that will fulfill the goal) and versions that will cause failure. In the end, it will give you a very clear sequence, written in natural language, easy to understand. You can move on by taking a "snapshot" of a use case, called a scenario - which is one specific instance of the use case - one single path that takes you from the beginning to the end, selected from the various paths and combinations available to fulfill the goal.

Use cases are the basis for creating patterns, or you can organize them into diagrams - in many cases, a better alternative to long text in natural language, or use them in connection with UML - we'll cover all versions later. They are a good tool to help you keep track of each requirement and its current status.

Once you have a use case, you need to make sure that it is indeed important, not one of the useless conditions that crowd your project, even if nobody can remember where they originated. A very simple and effective method, called Quality Function Deployment (QFD) will help you identify which are the most important options for the client, and which can be eliminated. Give users (or user surrogates) a list of the use cases and a certain number of points (or a sum of cash, to make it even easier to understand) to assign to the use cases, in order of the importance. Make sure you include all the types of users (every group of actors involved), otherwise it's not relevant. In some cases, you may need to organize a hierarchy of the groups of actors - for instance, give more points (or cash) to the group that is likely to use the program more often than the rest. Balance the number of points obtained by each function against the costs of developing it. After that, the results are pretty obvious and easy to interpret.

Because the use cases are so focused on the client, they are often turned into help files later on. In fact, this is one of the key aspects of working with them - you actually write the help files and the user documentation before you even started work on the program. It may seem a bit backwards, but it is a great method of insuring the client's satisfaction, which is, after all, the whole point.

While you are having fun with points and evaluation, don't lose sight of a major issue: the use cases have to remain testable and traceable, otherwise they are useless.

Pay attention when you write the use cases, and don't make them too abstract. The client should be able to understand them at all time. If you find yourself using the passive voice, you made a mistake - you need to describe what the user does, and what the reaction of the system is. Do not write from the point of view of the system, but make sure to include its response.

Also, you need to know when to stop - you can't possibly model all the situations, and you don't need to, since you can include them, in a form or other, in a use case. So, make sure you don't have so many use cases that they waste you more time than they might save.

You can use a prototype whenever necessary. There are various opinions out there about how a prototype should be used. The most common approach is to use the client's specifications to quickly design the interface, then use this prototype for the use case report. From this point on you no longer need the client's input (hopefully) and you can turn the use cases into UML diagrams (we will cover these later on), such as the robustness diagram and the sequence diagram, both of which are dynamic. These turn into a class diagram, which is static and can be turned into code.

After collecting the data from the customers, it's time to write them down, in plain English (or whatever other natural language) for the developers. Now, if you are really good at creative writing, this is not the place to show off your talents. Keep everything as concise as possible.

When formulating a requirement statement, you have to think of several elements: the actor (or the owner), the action performed, the target (or, again, the owner, as the case may be), the object, the localization and the constraints that apply. A statement may not contain all of these elements, but, if it refers to them, make sure they are specified.

Make sure your statements are not too long. One rule says that, if a specification has three or more punctuation marks, it needs rephrasing. If you have more things to say, break them down into several phrases, even if that means repeating some of the words. Also, check to see that you didn't include two different requirements in the same sentence - this is a sure way to make the developers ignore one of them. If you can think of many different tests and measurements for the respective specification, then probably it contains more than one constraint and need to be re-phrased and broken into several pieces.

When writing in the natural language, use the words as precisely as possible. Avoid the office slang, even when you are pretty sure that the entire team will understand it. The IEEE standards have pretty clear definitions for words that you are sure to use, such as failure, error, fault - make sure you stick to those definitions. It's very easy to get carried away, particularly when you know exactly what you want to say, and you "assume" that everybody will understand it, because it's so "obvious". Guesses, assumptions, taking the obvious for granted - these are some of the most common mistakes made in defining the process requirements.

Use the correct grammar, punctuation, spelling, even pay attention to typing mistakes - they are known to alter the final meaning with great ease. Pay attention every time you use conjunctions "and" and "or". Often they indicate that you need to break the respective statement into several shorter ones. Never use words like "etc", "and so on", which leave a lot of space for interpretation and personal preference.

Give as many examples and create as many scenarios as possible. You can test your work, particularly when you're new at this, by asking several people to read your requirements and to tell you what they've understood and how they see the possible solutions. Ask people from several departments, just to make sure that they all understand the same.

Again, cooperate closely with the client to make sure your requirements are correct. As long as they are written in the natural language, it's likely that the client will still understand them, even if this phase. Also, keep a close contact with the team of developers to make sure the requirements can be implemented, and you're not asking for too much.

Also, it's vital that your requirements can be tested and measures, otherwise they are simply useless. We will cover the tests in a different chapter, for the time being, just think that you can't measure if one solution is "the best" available, "the most efficient" or the "quickest" one of all.

When you have the full set of requirements, make sure it is complete, at least from the point of view of the current stage of the project. Now, check them one by one and see that they don't contradict each other. This happens a lot more often than you may think, and, in many cases, people don't realize until it's too late. Don't make the set too rigid, leave room to maneuver in case you need to modify or put in new requirements. Remember that the requirements have to make sense as a whole, as well as each taken individually. Also, all of them and each one separately have to be measurable and verifiable.

When you agree that software requirements are necessary, make sure you understand what the word "requirement" means. If you ask ten people (starting with the developer and ending with the client), you will see that each of them understands something else. Make a quick note, this will give you an idea of one of the biggest problems you'll have to face: different people use the same words with different meanings.

Usually, the requirements are divided on several levels. The first level consists of the specific business requirements - business background and market needs, objectives, dependencies, scope and constraints. These are usually beyond the control of any stakeholder, but they should never be self-implied. They need to be discussed and detailed like all the rest, and included into a document usually referred to as the "Vision and scope document". This is the place to discuss the operating environment - something that will have a major impact on everything else. For instance, it the client plans to implement the software in China, it may be a good idea to find out now, since this will impact on every other aspect. Or, another example, if there will be many users and they will need different access and security levels, again, it may be better to plan in advance.

Now, when this is settled, it's time to discuss the user requirements. As said before, clients are not always very cooperative at this point, and it will be your job to convince them. Don't take for granted everything they say, insist on every single detail, and insist on talking directly to the final users of the program, or on getting information from them in one way or another. In the end, if something goes wrong, it will be your fault, since you can't blame the client.

Users will use all types of meaningless words, such the "the best", "the easiest", "user-friendly", "fully compatible with", and so on. It's your job to turn these into clear, measurable and traceable requirements. You cannot tell your client frankly that he won't get "the best" feature, but you can't tell the developer that he needs to "do his best", either. This is more or less similar to translating from one language to another. Fortunately, there are specific methods of doing so, and we'll look at them later.

You will turn the user specifications into functional requirements and quality requirements. Sometimes there's no need to bother with the difference between the two, but, in most cases, there is, because you'll need different measuring instruments once you start implementing them. Also, here you need to consider other external, non-functional requirements, which are not related to your client.

Now it's the time to turn all of these into software requirements specifications (SRS) and to hand them over to people who need to use them. It is vital to prioritize them - be realistic, some things may not be ready in time, others may not even to possible. Decide which requirements are absolutely necessary, which are necessary, but can be implemented later on (after making sure that everything else works, or even in a later version of the program), and which would be really useful to have, but, if the deadline is tight, may be skipped altogether. While you are doing this, check to see if there are some requirements that are not necessary at all - this happens more often than you may think. Sometimes the clients insist on functions they don't really need, in other cases you "assume" or "guess" what they need, and sometimes unnecessary requirements are leftovers from constraints that have disappeared or changed in the meantime. Make sure you can trace each requirement back to the constraint or function that generated it. If you think the client insists on an unnecessary requirement, check with your developers how long it takes to implement it, and then inform the client of the additional costs. Usually, when faced with the cost/usefulness ration, many people change their mind or review the situation more carefully.

Up to this point, you had to perform an appraisal for a program that did not exist; from this moment on, you will mainly need to evaluate what has already been created, to test and verify that the requirements were implemented correctly. Of course, you may still need to modify them or to ad new requirements when this is the case.

When something changes, make sure everybody is aware it, don't just inform the developer directly about what has changed. The entire team should have a strict set of rules, and all the changes should be written down for every stage affected. For every requirement document you write, make sure you also record, right on top, which version it is and when it was written/modified. Organized, efficient communication is vital. Also, this will prevent people from returning to mistakes which have already been eliminated by introducing a new requirement.

Make sure you check all the processes and instances affected by the new change. One of the worst things that can happen is to have a requirement implemented in one process, but ignored in all the other processes related to or deriving from the first one. For complex projects, it may be a good idea to organize a control board to approve or reject changes at regular intervals, and to make sure everybody is informed about the change and its status. There's no need of making it a very formal affair, or a very large board, as long as it does its job correctly.

Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well - only they did a different job from what they were supposed to.

The definition of a successful program is that it is 100% compliant with its initial requirements. But it those requirements contain mistakes, are unclear or poorly defined, then there is very little one can do to correct the problem later in the process. So, a bit of advance planning simply doubles the success changes of any software project.

The persons in charge with writing the requirements should be the project managers and the team in charge with software engineering, all the stakeholders, the clients and the end-users. Writing good requirements takes time and practice, and, even with all the new tools designed to help you, it will not happen overnight. You need a good, clear, organized mind, good programming knowledge (because you'll need to know exactly what your team of developers can do, and you need to make sure that you speak the same language with them) and, to a certain extent, good people skills. You will need to get in touch with the clients during this period, and to find out exactly what they want and how they want it. Some of them are not capable of explaining what they need, others don't have the time to meet you and look over the drafts, other thinks they know better and they give you all the wrong ideas, and others will simply be very happy to approve your specifications without having a second look at them. You need to persuade all of them about the importance of this step, hold long, boring meeting, and then "translate" their needs for the programmers and developers. If customers or end-users are not available, despite your best efforts, you can use "surrogates" to simulate the actual users.

Make sure you remain in close contact with the client for the entire duration of the process. Their needs may change, or they may find out about something they forgot to tell you in the beginning - so inform them that you will always be available to meet with them and look at all the options again.

Also, the quality testing department needs to be informed about the requirements from the very beginning, because they will design their tests accordingly, and also they may have some details about what can go wrong in some cases.

One of the biggest issues is the time you have available for writing the requirements. Sometimes, when the deadline is very tight, the developers may start working before you completed the requirements, and this can cause a lot of problems later on.

The process of requirement management ends when the final product is shipped, and the customer is fully satisfied by it. However, the fewer modifications your requirements will suffer, the better for everybody. You should be able to trace your requirements all the time, and we'll have a look, later on, at the tools that enable you to do this.

In some cases, when a client comes up with an additional issue, it may be too late to change a requirement or ad a new one - the workload and the costs are simply too big to make it worth it. This remains subject to negotiation between you and the client - but your task is to know exactly what would be the effect of implementing new requirements, and to translate it into the language of the client (meaning that the client may not be receptive when he sees how many code lines need to be changed, but he may understand when you tell him how much this will cost).

Tracing requirements also involves additional tests, performed from time to time, to insure that the process runs smoothly and errors are identified and corrected early on. When faced with a big project, you may have different sets of requirements, some that apply to the entire project, and some for parts of it. When a certain design is implemented for a certain requirements, make a note about the effects and the alternatives - it may be useful for future projects (or even for the same project, if the client is not satisfied with the result).

So far, we've seen what software requirements are. In the following sections, we'll show some tips and tools about what good software requirements are. If this section is your responsibility, the wisest thing you can do is to get the IEEE Software Engineering Standards Collection. At 400 dollars, it may be somewhat expensive, but it will give you a lot of useful details about terminology, processes, the quality assurance and the user documentation needed. Also, the standards are conveniently given for each separate unit of the process - the specific part about software requirements specification is IEEE STD 830-1998, which describes the content of good requirements specifications and provides some useful samples. The guide is designed for in-house software, but it can be used for commercial software as well, with minor changes. Another useful reference is the "Standards Guidelines and Examples of System and Software Requirements Engineering" by M. Dorfman and R. Thayer, a compilation covering all the major standards (IEEE, ANSI, NASA and US Military). These are all flexible instruments, and should be used as such.

Bottom up: knowing what you do

Raising a child has its problems. You can tell 42 times "don't run, you might fall", but actually having a little (innocent!) fall makes a more lasting impression. This doesn't mean that the parent is better off throwing the kid on the pavement. The parent tries to guide the child as good as it is able to, through the process of learning and experiencing. And this wisdom from someone who hasn't kids.

Links of Interest
Bottoms Up: Leadership Style For A Better World

Back to the kids in the organization. Starting the "new way of working" at the individual employee level raises the critique that the employees are too stupid to change. "They perform this job in this way for 30-years. These guys are too old to change." And more arguments like this one. Instructing employees to deliver you a process description that complies to a project-approach doesn't work. I agree. But a little guidance in the activity creates miracles.

The guidance should consist of answering the big 'why': why do we need a new process? Why should it look like this? You could provide everyone with this fabulous book. People should know why the game is played like this, that's the key to success.

To middle management who will get the role of customer 'visibility' should be the mantra. Schedules, budgets and results will be transparent. Issues will be made clear by the project manager, to avoid as much surprises as possible. That will probably sell itself. Some discipline from the customer is of course required. Ambitious goals with no budget and a very narrow timeframe will be killed from the start. The only thing made transparent is its impossibility. The visibility also makes it difficult to change your mind. Middle management can change their initial thoughts, but it's 100% clear minds are changed; it's impossible to claim you are saying the same thing as you always did. This can be a drawback for managers.

For technical employees, like programmers, the trick is to show them "better planning, is more relaxed". If for example programmers can provide the project manager with a perfect estimate on how long they need for a certain job, they can do their work in their own pace, without time schedules slipping and pressure building. Assuming the project manager doesn't slash every estimate by 50%. When this is clear, just show them the way to improve their ability to plan. Watts Humphrey [1995] has constructed a complete process for this. The essence is to let people record what they are doing, and how long it takes. They can see for themselves which tasks consume most time, so they can take action to improve them. It makes visible how long a certain tasks actually takes. When asked for an estimate they can make a more informed guess, based upon their records on previous tasks. "System X cost me 1 month. This one has a little more functionality, so I would estimate for this system 2 months."

So, filling in time sheets is the way to go? Not if you put it like that. Just read the previous paragraph again and compare it with using time sheets to control the programmers in a directive manner: "You are late! Why?", "This takes too long! Why?" You will be heading for a disaster.

Top down: best practices

Having all those individual employees improving themselves is not enough. First of all, from the top down incentives must be provided to keep the people going. It is after all extra workload, so someone should better appreciate it.

Finally, let someone in the organization collect all the lessons learned from the individuals, and summarize it as an integrated and coherent set of best practices. For this purpose, best practices are always better then a complete method, as the best practices are really invented here!

Until now it was all about what you could do as a project manager; the approach was self-centered, like a self help book: "How to get rich in a millisecond." You will come a long way on your own, but you will never reach the full potential, the fullest effect you can reach with this kind of negotiating style of software project management. This section will provide some insight in how to introduce some "elements" of projects into an organization and its employees.

Links of Interest
Social OODA Super Speedway
Driving On The OODA Highway

Don't think when your organization is already accustomed to doing projects, this section is not relevant for you. Surely, the "official way" of performing the projects is not in line with "The Flow of Stakes" (see chapter 1), and new people will always be added to the organization.

Not invented here

Do you know the best way to frustrate a perfectly good process? Give a directive. Tell the employees they have to work in a certain way. Tell them they must. You will see your oiled machinery get sabotaged and run into a definite hold. People are funny in this respect, if it concerns their own work, they want something to say about it. They want to determine how they work. When introducing a project style of working into an organization this is one of the main causes for failure.

Some years ago I experienced an organization where all projects were torpedoed by changing requirements. In a need to get a grip on the situation the project managers looked for techniques to control the situation. They found out they had it all, they installed already every procedure that they could find in literature. And still, the projects were sinking under the heavy burden of continuos change. By accident they stumbled across a project team member at the coffee machine claiming that "the procedure was installed, but no one was actually using it. The project manager issued this procedure out of the blue, so, it's his darn thing. Not mine."

This phenomenon has actually a name: the not-invented-here syndrome. Not accepting something because it's not yours. It's around you, more then you can imagine. Why am I telling you this at this moment? Because a lot of introductions on doing projects are directives from above: "starting next month you will have to make a plan for every work you do; you have to record all the time you spend on tasks." And like I started out this section, that is a good way to frustrate a process.

Next to this "acceptance" issue is another argument to let the people involved determine the way thy shall work… who knows better how to work, then the people performing the job?

If giving a directive is not a good way to introduce it, what will be the alternative for the top down approach? Well… How about bottom up?