Money is the universal language. Or is it sex? I always mix 'em up… Sex on a project can get you in jail, so I stick for the moment with 'money'. Everybody can relate to an amount of dollars. Function points, lines of code (LOC) or mean error deviations on mantissa buffer overflows (MEDOMBO, yep, made this one up) may mean nothing to people; but money talks!

This is probably why stakeholders around a project put such a big emphasis on this subject. It is finally a language they can understand. The great thing is, most items can be expressed in money. So, money is truly the universal language.

During the actual running of the project, the project manager should watch that not more money is spent, then is given to the project, and he should create nice graphs to see how the projects' balance sheet looks like. Duh! Perhaps, we will spend some time on this subject later, perhaps not.

At this moment, when the project is not actually started yet, or hardly, we can consider the schizophrenic situation where money talks heavily, and the thing to construct is not specified (this will be done during requirements determination). This is more a conversation between a dad and his son, where the son is going to buy a car…

Son: "It must cost at least $ 50.000,-."

Father: "You must have a car in the range of $25 till 30 thousand."

(I have no idea what a car costs in the US)

Neither of them said something of a little red Corvette or a little Purple Pinto. But they express their stakes directly into a metric, which they can compare. Dad has been ripped off before by his daughter with her car, and promised his wife that he wouldn't make the same mistake again, but he wants to pay some. Son just wants to cruise for babes, and assumes daddy is picking up the tab. So, if you were a negotiator on this one, forget the absolute amounts, and focus and learn from the stakes.

If, for example, a system has to be built for a customer, where the specification for it is 4 lines, and the customer wants it for not more then $ 10.000,-, the origin of this '10.000′ would be the most valuable information a software project manager could get from this statement.

• The previous project that the financial controller handled, was originally estimated for $10.000 and went way over budget.


• There is a procedure which allows a certain level of management to make investments until $9.999, and for higher amounts one has to be a level up in the hierarchy.


• Five years ago the company asked for a quote on a completely different kind of system which was $20.000 and the brother of the nephew of the vice president said that this system was half the complexity of the other one.

By knowing the reasons you can deal with the amount. E.g. in the first case you can talk about a good way of tracing and tracking of the budget with the controller to avoid an unexpected overrun. Be creative.

A great source of information is the way a deal is either constructed, or how the customer (can also be an internal customer) wants the costs to be constructed: fixed price or time-and-material (T&M) based. In the first case, an exact amount is determined to deliver a certain good or service. In the second, the cost depends on the time and material actually spent, and will therefore be calculated after the job is done.

With fixed price, you really have to be sure you exactly know what you want as a good or service. Otherwise, you know exactly in advance what you have to pay for a system you don't need. With time-and-material you must be able to manage the project in such a way, that it really ends and doesn't drag on for years and years. If you view statements about the construction of the cost in this light, you get more and more insight in the truth (it really is out there, you know).

To summarize, in relation to the 'money' aspect, you have to answer the following questions:

• Which financial statements are already made in respect to the project?


• Who made these statements?


• Why did they make these statements (stakes)?


• Are there already statements on cost structure (fixed price vs. T&M)?


• If yes, why are these statements made (stakes)?


• How can you satisfy these stakes in such a way that there will be some room created to change absolute amounts?

Note on the last question: creating some room does not mean that you are actually going to change the amounts. The goal is to provide yourself with enough room to operate.

We Dutch are cheap, or at least that is what is suggested. In Belgium, it is claimed that the Dutch are buried face downwards to create more slots in which to park our bicycles. I think you can say that we try to avoid spending too much money. If you managed a software project here in the Netherlands, you would see a very strong tendency to save as much money as possible. However, I've never heard of a place where there is an unlimited budget.

My cheapness (from being Dutch) is an illustration for the more earthier matters concerning a project: trying to get a fix on the limited mundane stuff you need to proceed to the more noble cause of building a system. Whatever you have to create, whatever the reason for the project may be, there will always be constraints set for the project. These conditions determine the space in which the project organization may operate. Therefore, you might think of this part of project management as the "party pooper segment", as constraints always spoil the fun.

Project constraints consist of the following elements:

• Cost: This includes everything that costs money, like people and equipment.


• Time: What is the time frame in which every activity should take place?


• Quality: What is the level of quality the project has to reach?

Constraints are not independent from each other. Reaching a higher level of quality will cost you more money. If you want to use less time, you need more people (later on in this chapter, you will see that adding more women to give birth to one child does not shorten the nine-month gestation period; this is rocket science project management). The point I'm trying to make is that constraints are interdependent.

A classic way to show this interdependence is through use of the Project Constraints Triangle, or Iron Triangle. Imagine a 3-D space where the x-axis represents the amount of cost, the y-axis the amount of time, and the z-axis the level of quality for the project.

The project is represented by a triangle within this 3- D space. The size of a project is displayed as the square of the triangle. The size is determined by complexity and the amount of the product to realize. As you might understand, quality is a product requirement, and size can be viewed as the scope of the project.

A project with a constant size can have altering constraints. However, altering one constraint has influence on the others because the square of the triangle stays the same. The constraints are reflections of the stakes of the customer, but keep in mind that regardless of how boldly the constraints are stated by the customer, they are requirements, not stakes, so there is room for some negotiation. Playing with the aspects of the project triangle (including size) may also satisfy the stakes of the customer and therefore are more likely to be accepted.

It seems that every customer wants the best product tomorrow, and it may not cost a penny. I'm sure these customers do exist, but most top managers have a more realistic view of the matter. They know constraints must leave some room to operate. This doesn't mean they will ever admit that.

Think about your project as a Shakespearean tragedy. See it as a play with all your stakeholders on a stage, wearing tights, big floppy hats and all talking in this weird language, "Wilt thou be gone? It is not yet near day." It helps you to put things into perspective, and it will not be far from reality.

During the project intake the software project manager should create a picture of who the stakeholders are. Before the play can start, you should at least know your cast. D'Herbemont and César call it "the field of play":

In theory, nothing is simpler than to draw up the field of play for a project. It defines itself. (…) A new information system is to be introduced? The players are the computer suppliers and the users. (…) However, defining the field of play always throws up surprises. One starts by working very calmly on a clean sheet of paper on a flip-chart. Soon there are ten sheets stuck to the wall on the meeting room, each filled with arrows, crosses and question marks. At the end of the day, there are still unanswered questions. (Managing Sensitive Projects)

So, basically what you do, is stand in front of a white board and start drawing relations between parties and people, indicating why they are a stakeholder in the project.

The field of play consists of groups and individuals. However, when we talk about demands, only individuals should be considered. When it seems a group makes any demands, or indicates other kind of properties normally associated with individuals, one has to look for a leader of the group, a representative, and substitute this person for "the group". It is not a group that has dreams or wishes, it is a person.

In this way you also avoid assigning stakes to people based upon an assumption related to the group. This kind of "stereotyping" can cause bad decisions of the project management; what is seen as a win-win situation, may be regarded by the individual as a complete disaster.

There is a meaning to life. If you have a religious or scientific point of view, there is a way we're all going. There's some purpose to what we do. And that's nice. The days that we did something just because someone told us to do so, are over, I hope.

All activities should have a goal they support. And, even better, a goal that is seen as useful and achievable. Digging a hole, so another poor fool can fill it again, is a goal, but fails the other criteria. You may laugh at this, and wave it away as trivia and as a far stretch from reality. You poor soul, you are probably not long out of reality back here in the asylum.

Projects, being a collection of activities, have goals. They should be the answer to every 'why'-question about the project. Reviewing several projects, you will probably find some statements about the goals to be achieved. I'm sure searching information about the cause of the project however, will give you less data. And it's the cause that provides you with some hint about the usefulness of the goals. It can give insight on dependencies with other projects; so you can avoid another project filling the hole you just dug.

The following questions may give you a start in your search for the answer on the big WHY:

• What strategic decision lead to this project?
• How does this project relate to the business plan?
• Is this project the follow up of another project?
• What will be done with the results of this project?
• What will happen if this project doesn't happen?
• Is this project related to other projects that take place in the same time frame?
• Does the competition address the same issues taken on by this project?
• Why was such a project not performed earlier?

Related links

Tool Tip: Communicating The Bigger Picture
Return Of The Project Goals Video

For All The Right Reasons

Doing projects is hip. At least, that's the impression one might get given the number of projects and project managers around. It's not that surprising when you keep in mind that our ever changing world asks for activities with ever increasing complexity. We have to keep reinventing the way we do things. Invent it, and then throw it away, because of it's obsolescence; what works one time, has no use a second time. It's the environment where projects survive as the fittest.

Links of Interest
Project Management Code: Why Do You Do What You Do?

A project, by definition, is a temporary activity with a starting date, specific goals and conditions, defined responsibilities, a budget, a planning, a fixed end date and multiple parties involved. You know what you have to do, do it, once, and that's the end of it. That's a project. However, being hip has it's disadvantages. Our local housing office has a permanent project manager for financial controlling. This is a on going activity for the office, and the project manager does it as his full time, never ending job. What ever he's managing, it surely ain't a project.

There is no real harm in naming a tiger an elephant or vice versa. No one gets hurt by naming his job a project, even if it doesn't fit the definition by a mile. But don't be surprised if techniques for projects don't work on 'projects-just-by-name'. Don't be amazed when applying the techniques may seem like killing a bumble-bee with an machine gun. Don't get mad when other people don't know why you're doing an easy job the hard way, by making a project out if it.

Start a project, but only for the right reasons. Not for the heck if it. Not because of the cool acronym. Or the status.

For a project definition, look for the following aspects:

• Starting date
• Specific goals and conditions
• Defined responsibilities
• A budget
• A planning
• A fixed end date
• Parties involved

And then, if it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck. However, if it doesn't come close, raising the question of treating it like a project is the right thing to do. There may be an easier and much simpler solution.

Often (…) top management has no project; it merely has a problem and does not know how to, or does not want to, find a solution. So, it expects the players to find the way. Much social and industrial unrest can be caused by top management not having real projects, but only having the desire to get rid of a problem. (Managing Sensitive Projects)

If you don't find all the aspects named above at this moment in time, it is possible. Wait, and make the final judgement at the end of the intake. Working on one of the subjects, might cause one of the aspects to popup.

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

So, now you know the flow. For the coming days, try to fit all that surrounds you into this flow, view the world through these glasses. As you already might have guessed the concepts behind The Flow are not limited to software projects.

The principles on how to invent win-win conditions are discussed in general books like Getting to Yes: Negotiating Agreement Without Giving In. They even mention its use in hostage situations.

The indirect communication of stakes can even be viewed in Men Are from Mars, Women Are from Venus: A Practical Guide for Improving Communication and Getting What You Want in Your Relationships. If a girl states to her boy-friend "I want you to listen to my problem" (requirement to the process) the stake of the girl typically would be the reduction of her stress by talking on the subject, the boys' typical interpretation of her stake would be "she wants the problem fixed." To know exactly how this works, just read the book.

The point I want to make is that you don't actually have to work currently in a software project to try The Flow. Try to view as much of life as possible with your glasses colored by the concepts presented. I'm not claiming these concepts should guide your normal life, it is just an exercise! This is still just a guide on software project management.

Having said all this, where does it leave the software project manager? In order to have a "happy project" a software project manager should respect the flow of the stakes, as illustrated in the diagram below, and must ensure that stakes go "full cycle".

Uhhr, well, let's describe this "flow" in a few steps:

Links of Interest
3 Steps Towards Becoming An Agile Project Manager

• Stakeholders have stakes
• Stakeholders communicate their stakes by means of requirements to the process or the product
• Project management should make every stakeholder a winner by accepting and inventing requirements that keep satisfying the stakes of individual stakeholders and are not conflicting with the general process and product
• Project management should give continuos feedback on the state of the stakes
• Based upon the feedback, the requirements might change. In this way, a new cycle starts.

You must know this flow!

The first influence of the stakeholders on the project is usually the most influential. And it's at the start of the project. The demands and constraints issued on the process and the products they produce sets the stage for the entire duration of the software project. The primary task of the project managers should be to reassure the stakeholders that their stakes are taken care of, that what they said, is heard. For the entire project the project managers task consists of giving the feedback to the stakeholders of the state their requirements are in.

Feedback could take the following form:

• Tests
• Test results
• Prototypes
• Reports
• Evaluations
• Plans
• Benchmarks

This part is essential, but easily forgotten. If the project manager does not keep giving feedback, the slightest hint (or rumor) of not sticking to the stakes, may set a stakeholder on the war path against the once so happy project.

Related links

Deviant Behavior In Project Management

Why Suits Create Suits

Sounds simple, however, getting the requirements is one, finding out their corresponding stakes is another. Why bother anyway, what is it worth? A lot. As mentioned earlier, one can't effectively change the stakes, but one can change the requirements as long as they keep on supporting the stakes. In this way there is room to negotiate a set of requirements to the project, which do not conflict, match the stakes and thus making every one a winner! Right?

Taking it one step back. A stakeholder formulates a requirement for the software project. E.g. senior management states that "the project should be finished before the end of August." The project manager has to deal with it. When this deadline is no problem, he can rest assure. However, it's a software project, so the deadline will be a problem. The way to handle it is to get some information on the stakes that caused to formulate this requirement.

Perhaps it's the old "don't want to loose my face when my projects get delayed." That being the case, the project manager can offer alternatives that don't violate the stake, like keeping the deadline, but postpone a subsystem. Changes are that alternative requirements that keep supporting stakes, are accepted. Maybe not easily, but a project manager should do something to earn it's money.

An example, taken from Brooks:

… the reluctance to document designs is not due merely to laziness or time pressure. Instead it comes from the designer's reluctance to commit himself to the defense of decisions which he knows to be tentative. 'By documenting a design, the designer exposes himself to the criticisms of everyone, and must be able to defend everything he writes. If the organizational structure is threatening in anyway, nothing is going to be documented until it's completely defensible.' (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)