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

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