Every zoo tries to get a very nice and balanced variety of animals to present to its visitors. Species are grouped together, in a coherent way, and if you follow the tour that's laid out for you, you flow through nature in a natural way. But there is always this small pavilion at the back of the wall, in the shadows of the trees, where they keep the ugly and weird animals. They must be in the zoo for completeness, but they never fit anywhere in the normal tour. If you insert them anywhere, they interrupt the flow.

Links of Interest
Lessons From The Pond For The Project Workforce

My last section is the pavilion in the back of the course. It tells two stories that have to be told, but only fit at the end of the text, on their own. They tell the stories of doing the projects within your organisation. Your organisation is not a person, it's a collection of people, but even this non-human institute has stakes and requirements. They are called policies. The first story is about handling policies issued on what software you may make or buy.

The second member of the pavilion is the introduction of a project style of working within your organisation. It's nice if in the end you know as a project manager what to do, but if more people within your organisation are in tune with how software projects should be done, it would increase your effectiveness significantly. However, traditionally this is done from the top down, as a directive from above. And this is the most fundamental mistake you can make.

Dealing With The Unknown

You have come a long way, all the way up to this chapter. I have discussed expectations, estimations and anticipations withing a project. I tried to make it sound as good as possible, but let's face it, it's all vague stuff. You have to think about how someone else thinks, and base your complete approach on that assessment. We handled requirements, and stated that it's best to assume that they are wrong and will change anyway. It, it's like flipping a coin or laying cards.

Software project management cannot be performed without a good practice to handle all these unknown parameters. A project manager has to be able to live with uncertainties, and have a good way to structure his approach to handle them. The first is a personal aspect, which you have to do all by yourself. The latter is where "project risk management" comes in…

"Project risk management focuses the project manager's attention on those portions of the project most likely to cause trouble and to compromise participants' win conditions." [Boehm,1989 ]

So, in other words, it's a set of actions which helps the project manager structure his approach on dealing with the unknown or the "things not sure".

"… we define risk as the possibility of loss. We obtain an instance of risk by specifying values for the risk attributes of probability (the possibility) and consequence (the loss). Probability is the likelihood that the consequence will occur. Consequence is the effect of an unsatisfactory outcome." (Hall, 1998)

So, the idea is to specify explicitly the items that you are not sure about and define what will happen if what is expected (or assumed) is not true.

If you are not sure about the estimate ending of a certain task, you can define the risk for this situation as follows: delay of the actual end of the activity * very likely to happen. What the consequences and advantages are of this approach, is the subject of this section.

Risk is not a bad thing

The problem with risk management is the negative image of the word "risk". Of course, unless there is a potential for loss, there is no risk. The loss can be either a bad outcome or a lost opportunity. The tendency of most stakeholders is to jump very stressfully at the statement "this is a risk". Therefore most of the time it's not very easy to discuss about risks, because that's always a conversation about problems. It's very important the risk is not perceived as a bad thing, but as a positive attitude to make sure everyone will become a winner in the end.

Remember, risk management helps you being aware of the goals you have to achieve, and what can happen if you don't satisfy the goals. It supports you in making the right choices!

So, risk is not a bad thing! Say it loud! Spread the word!

Related links

Numbers Are Useless To The Novice

Human Failure Modes

In October 2000 I went for the first time to the US. Together with my then girlfriend, I flew to Las Vegas for a month's trip into Nevada and California. We married in Las Vegas and afterwards hit the road towards Reno, NV.

I had spoken to a lot of people before we took the trip. They told me "you can drive there for hours and don't see anyone". Being from Western Europe I thought "yeah, sure, right". In my area the best you can do is not seeing anyone for 10 minutes in the neighborhood of nuclear waste disposals. So, I hit the road Jack. Rental car, newly wed wife next to me, climate control to the max, Rick James funkin' from the CD-player, driving through Nevada. You know these postcards where you just see a road going straight to the horizon and then disappear, with nothing but nature next to it? That's what I got for two days.

When they mean nothing, they really mean nothing. I had most of the time no idea how far I was, how much time I needed for getting gas, coming to a town bigger then two houses. Just this one road, and once in a very long while you hit upon a landmark (e.g. old mine), and I was able to determine "ok honey, we can go to a bathroom within 2 or 4 hours." The advantage of one road is, you cannot go wrong. No exits, no decisions, no errors.

Driving from Las Vegas to Reno is easy compared to driving from my hometown to a customer I once worked for. It's only 50km distance, but full of turns and twists, detours and uncharted roads on newly built industrial areas. Every 500 meters you have to make a decision.

Driving Miss Project

Project progress is all about driving the project on the road towards its final destination. Where are we and how long do we still have to go? Attached to the answers of these questions are the requirements of the stakeholders towards the process of the project: Are we still within budget? Do we make it on time?

The project progress is an indicator relative to the path from the start to the estimated end, is an indicator where you are on this path, it's always a comparison between two situations, e.g. the start and the end. Project status on the other hand, is a description of a certain moment in time, it's a snapshot of a particular situation. Status is "we spend $300,-", progress is "we spend now 40% of our total budget, and we are on 30% of the total duration".

Feedback all over again

I hope you first read the previous chapter on requirements validation. There the issue was giving feedback on the product requirements. In this section the mantra is "giving feedback on process requirements". And frankly, the experience is that this particular feedback loop is the more appreciated one, it's high profile, if you really succeed in this one, your career is set. So, it's a good way of helping your own stakes.

In this chapter I will talk about schedules and budgets, just simply because it's the way to communicate the feedback on the project progress. I will even go this far in yapping on Gantt, not because "Gantt is project management", but just for the fact that it's an accepted way of communicating; most of the time it's even because some stakeholders do believe "Gantt is project management", and it's always easier to communicate within the expectation of the other party.

But remember, it's feedback time all over again.

Links of Interest

Executing The Plan
The 1:10:100 Rule
Project Management And Feedback

How many times did you order in a restaurant this very nice meal, which was described on the menu as delicious, to later find out the cook went completely experimental on it? I read this incredibly great description for a main course involving the better parts of a lamb. When I got it, I noticed it wasn't actually cooked; I like my meat extremely well done, nuked to the bone. I remembered, a menu is not a meal.

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"!

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

Movies are great. Women get pregnant and 5 minutes later their kid goes to college. One moment the family has the need for a vacation, the next shot they're floating on the canals of Amsterdam. And that's all just swell. Not many people want to view the hours of discussions around the kitchen table on deciding what country to go to. Not many people want to see every moment of a woman in labor, and watching the growing pains of a teenage kid, for hours and hours. Living a movie is great, you can skip the boring parts.

Being in the highest ranks of management is great. One moment you're in a wooden cabin in the mountains together with your fellow priests reflecting the need for the strategic development of a new product line. The next moment you're reviewing the results after taxes the new product line brings in. Life is good being at the top.

Meanwhile back in the jungle of middle management, lesser gods are struggling to pick up a vague comment made up in a wooden cabin up in the mountains, make something of it, and turn it into reality. Being a software project manager you meet strange objects thrown toward you from above. It could be no more then a little statement, or it can be a complete part of an organization coping with the remains of old mission impossible. The thing they have in common though is their label: project.

If you're a permanent member of the organization, you're just new, or you're from a third party supplier, the moment a software project manager comes into the picture, there is already something labeled as project. The 'chicken-or-egg-first'-dilemma does not apply to project management; first is the project, secondly the project manager. Sadly. The first task of the software project manager is to reengineer the situation that led to the project. The stakes of the people who initiated the activities now labeled as project should be clear. The requirements resulting from that should be known. These are the tasks during the intake of the project.

All may not be crystal clear. Time schedules may already be stated, without any one knowing what should be done in the first place. Goals can be formulated with such an ambiguity that anything produced satisfies the goal. The sad part of it is that stakeholders have already formulated their requirements. They may not have communicated them, but in their minds expectations are already in a particular direction. You should sort it out. It's a dirty job, but someone's got to do it.

At the end of the intake the project manager has aligned the project in such a way that he/she is willing to take the commitment for it, or he/she found out it is impossible and gives the job back (Yes, you have that choice!).

Related links

How Do You Describe A Project Problem?

Towards Speedy Assessments Of Project Problems

Staging The Project For Your Audience

The thrill of having tickets for the opening night for Andrew Lloyd Webber's new play on Broadway is in no comparison to the performance on amateurs night in our local town hall. Both are plays, both have players who conduct a series of lines to an audience. Prices differ, the quality of the players and props should give a serious gap in comparison. However, is there a difference in the appreciation of the audience? Is the night of those who went to Broadway more memorable then those who didn't cross our county line?

Most people would argue, it depends. It depends on the expectations of the audience. If they pay a bundle of money just to see some famous actor, they should be on Broadway. If it's people having fun in acting they want to see, amateurs night is surely the way to go. The staging should fit the expectations of the audience, and all is well.

A project has some aspects common to plays (not just tragedies). Some tricks are performed by members of a project team (the players) which are closely observed by people with stakes in the project, the stakeholders. As long as the players perform as expected by the audience, everybody is happy. The principles presented in this section aim at precisely that.

This guide covers the subject of software projects. Any project which has a larger part concerning software in it, can be categorised as such.

You will be introduced to the central principle of this course: the "flow of the stakes"; a software project manager should know the flow and have it printed in his brain, it should be his mindset. It is a way to catch the expectations, to integrate all expectations of several people, the stakeholders, and to make sure the project stakeholders know that their expectations are taken care of.

The main function of this section is to make you aware of this principle, to let you know there is a flow. It is not intended to provide a full depth analysis of every aspect of it. I try to do that in the other sections, but the true depth you can only view in practice.

"A basic principle of Lao-tse's teaching was that this Way of the Universe could not be adequately described in words, and that it would be insulting both to its unlimited powers and to the intelligent human mind to attempt to do so." (The Tao of Pooh)

It is perhaps a little much, but it gives you a certain idea; well, any way, see the flow as the apotheosis of this chapter, first we build up some context around project stakeholders.

Related links

Why Plan Driven Theories Stink

WTF: Project Management Theories?

CMM Revisited: Oh Yeah, There Is Something Outside The Project