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)

The human nature is not always direct. So, it's not always clear what the stakes are. Sometimes stakeholders communicate them directly, most of the time they don't. The level of communication is indirect; stakes are contained in requirements made to the project, process and products. Requirements are always a clearly defined state that is desired. This is in contrast with stakes, which are generally vague and abstractly formulated (if formulated at all).

An oversimplified example: a stake of a programmer is "to be also involved in way cool new technologies like my brother-in-law", say Java; the corresponding requirement could be that "the system can only be programmed in Java". The requirement can be stated surrounded by other technical arguments, but it's only the stake mentioned that caused it to appear.

So, the project manager has this project, surrounded by requirements he has to take care of. But, remind yourself, they are not the stakes, they are not the crown jewels you may not touch. So you can mess with the requirements? Can you?

Related links
Project Management Communications Bible
Communication Failures between Team Members

The entire process of software projects is strongly stakeholder-driven. It's their wishes, fears, dreams, their stakes (hence the name) that determine the course of the projects. A stakeholder can be a project team member, an employee of the user organization, or a senior manager. Virtually, it can be anyone, as long as they have something to do with the project.

The stakes are the crown jewels of the holders. They stick to them, they defend them, they are married to them. They also make up the words to formulate their expectations. The individuals will take all actions necessary to defend their stakes, or to get near the realization of them.

Stakes can be in two directions: fears or wishes. With the first there is a stake to lose, with the second there is something to gain. Either way, stakes are sacred things; anyone, including a project manager, should not try to mess with them.

Again, in order to do anything with the stakes of the holders, the project manager should be the greatest negotiator he possibly can be.

For long, the art of the management of a software project is really an art, it's a trick that's difficult to master. The difficulty lies in the central problem the software project manager is faced with; appropriately named 'the software project managers' problem' [1]

Everyone effected by the project, direct or indirect, has something to say, again direct or indirect, and will do so. Everyone wants to get the best from this project for him personally, or for his (part of the) organization. It's the job of the software project manager to see that everyone gets what he wants, in one way or another. He has to "make everyone a winner" [1]

In this respect, the role of the project manager becomes that of a negotiator. The customer always wants to have it all for free, the user wants to have to greatest functionality, the programmer doesn't want to document, but wants to use the coolest compilers. The software project manager has to make them all happy.

[1] Boehm, Barry W. and Rony Ross. "Theory-W Software Project Management Principles and Examples." IEEE Transactions on Software Engineering. 15.7 (1989): 902-916.

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