Part Two

Controversies

"How a new information system will have to support our order entry activities for 24 hour deliveries. The new order entry activities as described in Large Document X and approved by Big Guy Y have to be considered." A purpose like that for your workshop, and you know you will have some trouble. Probably someone in the workshop is no fan of Big Guy Y. Thinks he doesn't know a thing about order taking. However, the Large Document X is approved and is the basis for the workshop. T, R, O, U, B, L, E.

Perhaps one of the workshops subjects is reorganized for the 100th time. Maybe "ISO Certification" is the "soup du jour" (hype of the day) at the company, so everyone just wants to write large documents. Possibly the same workshop has taken place last year, and no one heard a thing about that one… Controversies on the subjects of the workshops. Find them. You really need help with this one. Again talk to people and listen to them.

Strategy

Given the controversies and the list of subjects you put on the form in the previous steps, you should determine how to handle things, how to approach the subjects strategically. I know, I said the goal is to make everyone a winner. Take care of all stakes. But probably not every one in the workshop is feeling lucky due to the controversies. If people don't want to be concerned with the project in the first place, they can frustrate the process of conducting the workshop. If they are out to sabotage and are not into the win-win mood, you will not get them. Not during the workshop. You can handle them later on. Be pragmatic, you also need an end result, so don't let them block your workshop.

For the Big Guy Y hater, bring it as a given. This is it, you can't do a thing about it, so stop whining. Be passive, confronting, whatever flavor you have up your sleeve (smell that shirt!).

For this ISO thing, you might try making the issue bigger, bolder, more abstract. Like, if someone yaps about "documenting every thing", make it in little steps bigger: "Yeah, you are right. You should document it, and have a great structure to support that. You want every thing stored in one place. So you can access it from everywhere. But of course, to be effective, you should also register this, and that. So you can cross reference it with…." If you can avoid the sarcasm and sound sincere, they will bring up that they're not ready for it. I love this one.

The purpose of this step in the preparation of the workshop is that you think up front the strategies you might have to use. In this way, you can prepare some information or invite some one to the workshop to neutralize the controversy.

Result

What will be there when the workshop is over? The requirements of the end result can be written down as a story, as a formal specification in some cryptic scientific notation, or some cool graphics. There is so much research done on this subject. How to check the set of inconsistencies? How to create a graph from Here To Eternity?

Just use the medium the key stakeholders are used to. If they like to tell stories, tell a story. If they are mathematicians, use formal calculus. If they are computer scientists, use bloody graphs. I like to tell stories myself.

Specify how the result will look like. How you can read it. Close your eyes, and see it!

And finally, the rest

To close your preparation, you can specify the participants of the workshop. Who are they, what is their position within the organisation, and, most important, why are they invited for the workshop; what role do they play in the discussions; leader, chairman, scribe…

If you want to use tools, you should write them down, and arrange that they are there.

This one deserves some emphasis: On which way will the results be communicated back to the participants, and what are the next steps for these results?

And only at this stage, you are able to create an agenda for the workshop. Only here, at the end of the preparation you have enough information to create a good agenda.

Enough swimming on the side of the lake, let's jump in.

Part One

In the preparation of the workshop you can follow this checklist of aspects to consider:

• General information (title, place and time)


• Purpose


• Scope


• Subjects


• Controversy


• Strategy


• Result


• Participants


• Roles


• Tools


• Feedback/follow-up


• Agenda

In the remainder of this section the aspects will be treated in more detail. With these points you cover the basics for a successful workshop.

General information

Starting off with some general information, your workshop's got to have a title, a name to call the beast by. Make it short, clear and not a novel… "workshop on order entry" is a good one. Pick a date and place.

Concerning "time", I just want to mention that the unit of duration for a workshop should be a part of the day (two parts make one day, so morning and afternoon). Don't drag people out for one hour. That's not a workshop, that's a discussion.

Purpose

What is the workshop all about? Purpose, scope and subjects, that's what defines the actual workshop. The purpose is important to inform the workshop participants correctly up front, so that they have no wrong expectations, or at least make the chance on that a little smaller. By the way: you don't have to yank all info into one sentence. It's ok to make a paragraph out of it. "Partial requirements in the preliminary decision making phase" is a sentence, but it tells nothing. If the requirements coming out of the workshop are not final, but will be reviewed and approved by some hot shots afterwards, write it like that! It won't give you the Nobel prize for literature, but it sure will save your workshop.

Scope

The purpose will place the workshop within the context of the project, the scope tells us all about the actual content, e.g. "order entry for 24 hour delivery". The scope should determine the field that will be covered, including a good definition of it's borders. "How a new information system will have to support our order entry activities for 24 hour deliveries. Current activities may be subject to change." The second ("..may be subject to…") sentence is very important. If things may be altered, make them explicit, try to avoid that people have to read between the lines, or have to be sensitive to the words chosen. The opposite holds also, of course. If it's not allowed, state it. "How a new information system will have to support our order entry activities for 24 hour deliveries. The new order entry activities as described in Large Document X and approved by Big Guy Y have to be considered."

Subjects

To create a good list of subjects to cover, some homework has to be done. A good preparation would be joining stakeholders in their work for a short time, mentioned earlier in this section. In addition to this, you should talk with someone with knowledge about the scope. A good starting point, if possible, is to take the tasks that fall into the scope. Like, for order entry…

• Getting the order


• Finding the customer


• Checking for stock


• Placing the order


• Tracking the delivery

Another way is to make a distinction in categories of the subject at hand. If you order an ad in a newspaper, you have the little public announcements and the larger display ads. You can discuss about large customers and small customers. Blue balls and yellow balls. Take your pick.

So, there are a thousand ways to organize your subjects. They should be clear, logical, "feel good" and make immediate sense to the participants.

Preparing A Workshop - Educating

The end result of the requirements determination activities should of course be a set of requirements. The representation of this set will be treated later on in this chapter. A point to address at this moment is the depth of it all. How far should one go into detail? There is, as you might have expected, no concrete answer. The criteria one should handle at all time is that a requirement is unambiguous, that all stakeholders have the identical view on what the requirement means. You must use your own judgment on this one. To be able to judge, you must know the tasks that will be changed as part of the project.

And that's where it all starts. Educating the project manager. The project manager should follow the stakeholders for a while in their daily tasks. This is the only way to get a feeling for the subjects. How urgent everything might be, take the time to do this. It will pay off in the end. It helps building a sense for the processes, for the business case, for the entire organizational context. It is important to go at the issues from these angles, the wider and broader perspective.

Most users, and other stakeholders, tend to formulate their requirements based upon their current situation. They see where they are now, and can talk about the two or three steps they want to make from their current point. This is a handicap, because it limits the possibilities. Seen from a market, business and process perspective, more opportunities could be taken. Instead of talking about "extra data fields in our customer entry screen" one should address the things one wants to do with a customer, and reason from this back to what information is needed to do it.

It sounds obvious. It is. For an information analyst this might be peanuts. But for most people it tends to be very difficult. During the actual requirements determination you need the stakeholders to be completely holistic ("Ahum, let your mind flow freely in the space that surrounds you."). So, you have to educate the stakeholders before starting the phase. Let them visit a seminar on the future of the market, let them brainstorm about how their job is an integral part of the company's process, whatever. Let them view their tasks as part of the whole.

Stakeholders In The Mist

I have this friend who has a friend, who had a discussion with his girlfriend the other day. She accused him of not being romantic enough and that he never organized something nice for the both of them. So he replied a spineless "OK" and took her to this VERY expensive restaurant, with smooth music, wine and sophistication. She refused to go in, "cause it was too expensive and they could not afford it". He was like going "WHAT?!!"

Stop and think for a moment all the times that you thought you understood what someone was saying, and you later found out you were utterly wrong. Wilson, the neighbor of Tim Allen in Home Improvement would say: "The limitation concerns human bias in the selection and use of data. These biases arise because humans use less than optimal heuristics when retrieving and processing information." Basically, we are too narrow minded and not open enough.

At this point in a project we have to determine what the requirements are for the end result. We have to get it out of the heads of the stakeholders and on a piece of paper. For this, a lot of communication is needed between very different people. As a kid I played this little game at school we called 'telephone line'. Twenty kids were hurdled up into a circle. One started by whispering a sentence in the ear of his neighbor, so the other kids couldn't hear what was said. The neighbor would say the same sentence to his neighbor, and so on, until the sentence was 'round circle'. The fun of the game was comparing what the last one had heard with what was originally said. Mostly, they didn't even come close. Kids and stakeholders are almost the same. The sentence of the first stakeholders is often different from the software the last user will see.

The most widely used and efficient way of getting the requirements is by asking. By talking to key stakeholders, like future users of the system, the needed information will emerge. It might seem obvious that this should be as accurate as possible, however it is crucial to do it correctly at this stage. Although information systems are expensive to develop, changes made once a system has been completed are 50 to 100 times more expensive than making the same changes during the requirements determination activities.

And that's a hell of a job. We already mentioned the difficulties in understanding each other. But there is another catch also, you have to anticipate the ways the tasks will change when they are running under the new system. Watts Humphrey would even go this far in stating that…

…requirements by their very nature cannot be firm because we cannot anticipate the ways the tasks will change when they are automated. … Unless the job has previously been done and only modest changes are needed, it is best to assume that the requirements are wrong. (Managing the Software Process)

In this section the determination will be done by means of a workshop with the key stakeholders. A workshop is a kind of a discussion between key holders, with a conductor who manages the process. It is dynamic. It should be fun. White boards are used. Big screens and flashy presentations. People should walk around. And, of course, this show should produce a real end product; a set of requirements.

It can be one workshop or multiple, depending of the scope of the project. This chapter will handle preparing and conducting a workshop, and what to do with its results.

One thing should be stated at this point: the workshop mentioned in this chapter aims to handle requirements made to the end result of the project (the product). Requirements made to the way the project is conducted (the process) can be handled by the same concept as described in the section.

The activities in this section are not necessarily pure project management tasks. Of course the planning part is, but conducting the workshops isn't. However, because of its importance and the impact of requirements on the complete process of the project (remember, they're still a reflection of the stakes of the stakeholders), the software project manager should at least be aware of it's pitfalls. If the project is large (read "small") enough, it is recommended that the project manager also conducts the workshop, or is present in its discussions.

Related links

Specifications and Productivity and Defect Rate

And now you have read all this paperwork. You talked with all those people. You asked "what do you want?". "What can I do?" Now it's time for your gut feeling.

Do you trust the statements made by the stakeholders? Do you think top management will stick with you? Do you honestly believe the project has a chance to succeed?

Now is the time to know. It is late, but you can still get off the train. After this, it's your ass that's on the line. When this project is mentioned, it's your face the people see.

Related Posts
Project Management Code: Why Do You Do What You Do?

It makes no sense to associate yourself with a project if you think it's a Titanic or Mission Impossible IV. Don't make the mistake thinking your effort will be appreciated, even if everything goes down the drain. Failure is an easy thing to remember. The true professional knows his limitations, and the only responsible thing to do is, either configure the project in such a way it stands a chance, or return it to the sender.

A quote is always great, but this one from US judge Jackson to Microsoft during the trial over their monopoly position is in this context even perfect:

The code of tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. (But lawyers) often try other strategies with dead horses, including the following: buying a stronger whip; changing riders; saying things like 'This is the way we've always ridden this horse'; appointing a committee to study the horse; … declaring the horse is better, faster and cheaper dead; and, finally, harnessing several dead horses together for increased speed.

If you take it on, don't forget to include your own stakes: be a winner yourself!

And, if you are a winner, and higher management is committed to you as a project manager for the project, make sure they send a memo or an e-mail to all stakeholders, announcing you as the new king, the main man, the ruler of your universe… or something more "office like".

Darwin's natural selection is a great thing. The shape of every species is crafted over thousands of years, to get the functions it needs to survive in the environment it operates. If it does not have the necessary skills, it just dies and is doomed with extinction. All the beautiful, blonde, long legged creatures survive.

The Homo Projectus is an ugly thing. It survives in extreme situations, where dirt has to be shoved. In this case it has the aspects of a hog. But to get the right features to have a party of hogs operating in such a way the pack will survive, is something completely different. We cannot wait until nature has killed all unsuccessful project organizations (the hog party), so the software project manager has to help nature a little bit, tinkering with the organization, so it might have a chance to survive in the corporate jungle.

Links of Interest

Stratification: Organizational Structures In A Pond

A project organization is a temporary thing. It will only exist from the projects start until its end. All the project team members are coming from different organizations of part of the organization. They will all have a temporary assignment to the project. So, they have not only a project boss (the project manager, that might be you), but also their 'normal' boss, who orders him around when the employee is not in the project. These 'normal bosses' are an important group of stakeholders.

The project organization should be a result from the project strategy, it should be constructed in such a way that the strategy can be implemented within the environment of the project ("look what the dog brought in, a presumptuous sentence"). A very obvious example: if the strategy contains an aspect of having independent reviews, the organization should support its independence, by creating a separate working group with no ties to the other team members, e.g. But, I'm a little too far now mentioning working groups and the like.

The project team that does the work should be as small as possible. Small is beautiful, and effective. Don't start inviting everyone to the organization. Only people who have an added value and will spend a significant amount of time to the project can be in the core organization. Try to avoid going overboard on working groups. Working groups can drown a project in communication overhead. If there should be that much discussion anyway, postpone the project and first make up the minds.

Next to the people who do the work, are the people that have some influence on it, but do nothing; a large part of the stakeholders. The project organization can be used to satisfy some wishes of stakeholders to create the much needed win-win situations. In its most simple form, you can create a project trashcan ("The Project Tactical Non-Binding Advisory Committee") where you put in the people who just want to be involved in the project (to save their territory), but which you have no use for.

Be creative while constructing the project organisation. Take the Bob Ross way to paint your organization: "This is a sweet little project staff. I put it here next to the tracking and control group, so it has a friend."

By now you should have an idea about…

• what the goal and reason of the project should be;
• who's involved in the project, direct or indirect;
• within which constraints you have to operate;
• what you can and must alter, and
• some background to anticipate current behavior.

The next step is to determine what strategy the project should take. What kind of steps? In which sequence? With who? I'm not talking about a fully detailed description; "George will walk to the bathroom. George will take his trousers down." I'm talking about real strategy!

The 'traditional' steps within a software project are something like:

• we think about the subject
• we specify a solution for the subject
• we implement the subject
• we activate the subject in the organization.

In project management lingua we call these steps 'phases' and have cool names for them like 'analysis', 'specification', 'implementation', 'roll-out'.

At this moment you have to determine the 'phases', or mayor steps, you will take. A strategy would be to follow the steps as mentioned above (the 'traditional' one). You could do this, if what has to be done is absolutely clear and everyone agrees. If not, this is not the way to go. By the time you want to implement the stuff, what has been written in the specification is not valid any more, the people changed their minds. Because this is often the case, more common is a strategy where these steps (or some of them) are repeated several times. So, for example, instead of thinking for 6 months about a subject, and specifying a year, the project will go through several steps of 2 weeks thinking, 4 weeks specifying, etc. With every reiteration the specification gets more and more detailed, and you would benefit from the results of later steps.

The project strategy, like any other strategy, should be simple and logical; you must be able to explain it to someone not related to the project in 2 minutes. So, don't go rushing into methods and the technical talk, like incremental, spiral, tornado, waterfall, it is only camouflage for when you have no idea what your talking about.

If the goal is very unclear, the scope is totally undefined, the strategy would be to

• first get the goal clear,
• determine the scope,
• adjust the project according to the outcome of the previous step,
• execute the remainder of the project.

It's ok to have the later steps more general then the first ones. It is a very simple strategy, but you can explain it to everyone, and it makes sense. If you don't know exactly what to do, you first try to get that clear.

The strategy should be a result of all the information about the stakeholders you have collected. Consider the following situation. A chief of some users has a formal role in determining the requirements for the product. You, and some other people, fear that these requirements will go beyond the scope of the project. Intervening continuously with the user chief, may be considered as a threat to his independence or formal status. By creating some periodical steps to review the requirements in relation to the scope with stakeholders concerned, this problem can be overcome and result in the needed win-win situation. The decision of having these review steps for this case, is also an important part in determining the project strategy.

Related Links
Using Iterations
Method Components Have a Reason: Scrum
Agile Or Plan-Driven Project Management: One Size Doesn't Fit All

Psychotherapy tells you what you already knew: all your current problems are the result of your troubled childhood. You are now harassing your employees, because in high school the popular boys always bullied you. Your children wonder why you always provide them these trivial and obvious advises (actually, this is their problem, not yours). For the answer they should ask grandma how she succeeded so perfectly with her brainwashing their father/mother. You see, current problems find their origin in history.

By now, you know that I will make the bridge to software projects at this moment… so, yes, the same holds for software projects. This financial geezer sits on top of the budget (current problem) because the last project he controlled went way over the price (history). When we later on handle the subject of requirements determination you will see that most requests from users are caused by problems in their current systems. If they keep on emphasizing that new billing-system X should have perform check Y, you can bet your money on it in their current situation the lack of check Y is causing them a lot of extra work.

You could ask every stakeholder "Where were you on the night of…?", but something tells me this kind of McCarthyism is not beneficial for your start at the project. The most effective way is to have an informal talk with a senior and relaxed employee of the firm, who knows most of the important stakeholders and has been around in the organisation. Talk about the financial people, the bosses, the maintainers, the user groups and especially their managers. Where do they come from? Were they around last time a project was conducted? How did that come out?

Another way to get some taste of the history is to review old documents. Project plans, evaluations, strategic memo's, everything that is available and is somehow related, could be of use to build a view on the past.

Of course, if you are the senior and relaxed geezer of the organization, you already know its history. In this case, just refresh clearly your memory.

They decided to make no fuss about the wedding. A very small event for a few special friends. After a visit to her mother it was two small events, one wedding at city hall, one at the local church. When they left his mother, all old aunts were invited, and, all being of high age, would of course stay the night. The day she spoke with her best friend, so had to have this great dress, which would need three bridesmaids to carry the thing…

Sounds familiar? You don't have to plan a wedding to see something so elegant and easy, grow and grow and end up getting completely out of hand. You probably heard stories of people wanting to fix a dripping shower and ending up with a complete revision of their bathroom. You must know where to stop and then just simply stop.

With a software project it is essential to know the borders up front. Which aspects are allowed, which one are off limits? If the goal is to cut cost, you can just fire every one. One could image that these kind of changes in personnel are not within the scope of a project. However, switching to a different technology would be. You are allowed to change internal procedure, but not the interfaces with external parties. "The Project Scope" can contain all kinds of statements. The trick is to get it as detailed as possible already at this stage. Together with the goal and constraints it provides information of the room to move.

The project scope can be too large to fit in a certain time frame. The scope can be too small to satisfy the goal. In determining the scope you talk with parties concerned and ask two types of questions:

• Can we change this?


• Must we change this?

You should use the stuff you can change but not have to change, as ammunition to get the needed win-win situations, to be able to change the stuff you must. Wow, play this sentence again, Sam.

Suppose you are allowed to change the scope of training sessions, but you don't have to. Suppose you must change the way a certain department works, administrative procedures now done manually should be highly automated. Employees might become reluctant to become just a typing goat. By providing extra training that makes the employees more state-of-the-art in their field, and focusing on the fact that the time saved by the new system will be used to let them handle the more "challenging" cases, might create the win-win situation you need.

In this way, you should hammer a scope that fits the project goals, constraints and expectations of the stakeholders. To avoid your aunts visiting, send them a piece of the wedding cake instead!

The bearing of a child takes nine months, no matter how many women are assigned. (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)

This is one of the most insightful observations made in the last 25 years on the subject of project management. It originates from 1975, and is written by Frederick Brooks in his article "The Mythical Man-Month". Welcome to the age of rocket science…

In the communication on the timing aspects of a software project, many mistakes are caused by the use of the unit man-month. Like the word says, it indicates actually "a month spent by one person". To determine the cost of the project, it is a fairly good unit: building the darn thing takes 3 man-months. You know what a guy costs per month, so you can do the math. But while the time passes, this statement will be shortened into "three months", either in written word, or in the minds of the people involved.

"How long does the project take?" "Oh, 3 months."

And then the fun starts.

"We need to finish the project sooner." "We'll add a resource. Problem fixed."

The problem with this kind of reasoning is the fact that some tasks cannot be split. Because of sequential dependence, or just because it is not possible (like the birth-thing). The trick is, that a man-month is an indicator for cost, and not for progress. So, while looking and discussing on time, be aware of this communication trap.

This may be the most valuable lesson, but it is not the only thing to consider about time at this moment. At this stage a detailed planning will not be created (luckily), but a global time-frame, with start- and end-date will surely be available, at least in the minds of the stakeholders concerned. Here holds the same thing as discussed in the 'money' paragraph: try to get a fix on 'why' these dates are chosen.

"It should then be finished because…"

• the most important manager takes a holiday (paid in advance) afterwards
• another project will start directly after it, and people are already allocated for this
• someone just yelled this date one day, and everybody uses the same mantra ever since

See if the deadline stated holds with the cause and target for this project.

You may perhaps miss something about planning and estimating stuff, this will be treated after the requirements are known (chapter "Project progress"). However, at this point in time some statements will be made about time, money and effort. If you have to rely on the input of experts for this (programmers, analysts), the best, and only thing you can do, is to talk to them and get an estimate

While doing this, focus on why they think this particular amount, is it similar to what they have done in the past, change some of the stuff you tell them, to see how that changes their behavior. But most of all, listen seriously to them, let it be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time.

Related links

Why The Customer Always Wants His Stuff Tomorrow