Until now it was all about what you could do as a project manager; the approach was self-centered, like a self help book: "How to get rich in a millisecond." You will come a long way on your own, but you will never reach the full potential, the fullest effect you can reach with this kind of negotiating style of software project management. This section will provide some insight in how to introduce some "elements" of projects into an organization and its employees.

Links of Interest
Social OODA Super Speedway
Driving On The OODA Highway

Don't think when your organization is already accustomed to doing projects, this section is not relevant for you. Surely, the "official way" of performing the projects is not in line with "The Flow of Stakes" (see chapter 1), and new people will always be added to the organization.

Not invented here

Do you know the best way to frustrate a perfectly good process? Give a directive. Tell the employees they have to work in a certain way. Tell them they must. You will see your oiled machinery get sabotaged and run into a definite hold. People are funny in this respect, if it concerns their own work, they want something to say about it. They want to determine how they work. When introducing a project style of working into an organization this is one of the main causes for failure.

Some years ago I experienced an organization where all projects were torpedoed by changing requirements. In a need to get a grip on the situation the project managers looked for techniques to control the situation. They found out they had it all, they installed already every procedure that they could find in literature. And still, the projects were sinking under the heavy burden of continuos change. By accident they stumbled across a project team member at the coffee machine claiming that "the procedure was installed, but no one was actually using it. The project manager issued this procedure out of the blue, so, it's his darn thing. Not mine."

This phenomenon has actually a name: the not-invented-here syndrome. Not accepting something because it's not yours. It's around you, more then you can imagine. Why am I telling you this at this moment? Because a lot of introductions on doing projects are directives from above: "starting next month you will have to make a plan for every work you do; you have to record all the time you spend on tasks." And like I started out this section, that is a good way to frustrate a process.

Next to this "acceptance" issue is another argument to let the people involved determine the way thy shall work… who knows better how to work, then the people performing the job?

If giving a directive is not a good way to introduce it, what will be the alternative for the top down approach? Well… How about bottom up?