I am currently preparing an introduction for IT people in PM methods. While struggling to come up with a way to provide a fast overview of a method, I came up with the following: the four mechanisms of PM methods. A short description of how these mechanisms function within a certain method, works quite well as a fast introduction.

Decisions: A project is a game of trade offs. There is always a need to balance resources, money and time towards certain goals. Because nothing is unlimited, because you are dealing with scarce resources decisions have to be made for which purpose resources are allocated. A method provides a mechanism to make those decisions.

End Result: The goal of a project is to solve a problem or to take an opportunity. There is a reason why a project is performed in the first place. With all decisions that have to be made, with all the changes in the environment that take place a method provides a mechanism to keep the eye on the price, to keep a project pointing to a certain direction.

Resilience: "Change" is a projects middle name. Uncertainties and changing certainties are the environment in which project have to operate. That is just inherent to the nature of projects. How a project deals with changes, how it absorbs or adapts to uncertainties and shifting targets is a major component of the method.

Tailoring: Not all situations are created equal. Different circumstances make different projects. What is effective and desired in one situation may be complete irrelevant and harmful in other situations. A method will provide a mechanism to tailor the method itself to the circumstances.

There are not many books available that cover the topic of when to apply an agile or plan driven method. In my opinion the selection of when to apply a certain technique or process component remains the most difficult area of Project Management. I only know of two books that cover this in detail, my own and "Balancing Agility And Discipline" by Barry Boehm and Richard Turner.

First of all, the fact that the book is written by Boehm and Turner is remarkable. Boehm wrote the classic "Software Engineering Economics", formulated Theory-W, invented the spiral model, a true influential pioneer. Turner helped shape the CMMI model. So, both respected "old school" software engineering professionals. The fact that they try to have an impartial look at agile is an accomplishment on its own.

The book provides insights in when to apply agile methods and when to apply plan-driven methods. The authors argue that for every type there is a kind of project that is suited for one of the approaches. Or a kind of combination.

Five factors are considered influential when considering an approach:

• Critically: if the end result doesn't work, are people going to die or is it a minor inconvenience?
• Personnel: how good are your people?
• Dynamism: are requirements changing all over the place?
• Culture: do people like change or do they need order?
• Size: how many people are involved in the project?

Presented is a risk-driven approach to select the proper method. Some general project environment risks (E) are considered, risks associated with the use of agile methods (A) and risks that occur when plan-driven methods (P) are used. An assessment of these risks should help you to make a proper choice of method.

The risks are:

• E-Tech: Technology uncertainties.
• E-Coord: A lot of stakeholders to coordinate.
• E-Complex: The complexity of the system.
• A-Scale: Scalability and critically.
• A-YAGNI: Use of simple design or YAGNI (You Aint Gonna Need It).
• A-Churn: Personnel turn-over and churn.
• A-Skill: Not enough people skilled in agile methods.
• P-Change: Rapid change.
• P-Speed: Need for rapid results.
• P-Emerge: Emergent requirements.
• P-Skill: Not enough people skilled in plan-driven methods.

What I find very useful is the appendix with a comparison of a lot of methods like Scrum, RUP, Crystal, CMMI etc.

Although the book is very dry, although you don't get a ready recipe for success (duh!), this book will make your mind better suited for balancing different methods.

Project Managers with experience know that the traditional ways of doing PM are not sufficient any more for all our project situations. You need more tricks up your sleeve to pull it all off. That's why I follow eagerly the techniques that are coming from the agile PM camp. But I have a hard time integrating them with my own views, at least in the ways they are expressed by practitioners. Glenn Alleman provided me with the final "aha" I needed in this direction in his posting : Agile PM is not discussing project management as such, but more the management of software development using agile processes (where the agile-part is in software development).

He raises some very interesting issues I agree with. Software development can be a part of a project, but a project always has a broader scope of activities, so limiting yourself to only development leaves out some aspects. And before we go this way, let me just start now : yes, it is important for a PM to know software development practices. Not to perform them personally, but to be able to communicate intelligent about the subject: "where are the risks, is he or she bullshitting me… ?"
Read more

I had some emails from readers who wondered why I coin the term "Project Potion" in my book "Surprise! Now You're a Software Project Manager".

The origin of the term comes from a blog posting from 18 months ago:

I have to work on my self promotion. I am struggling to make some sense of how to combine components of different PM methods under certain circumstances. It is a a struggle, however, it deserves some attention. Well, heck, that's my opinion.

When I started reading "Balancing Agility and Discipline" by Barry Boehm and Richard Turner. And all of a sudden, it struck me…

They used the term "tacit knowledge" as a concept in agile methods. I am not a native English speaker, so, that sounded verrrrrry goooood. Later I found out it is just the knowledge in your head, instead of writing everything down.

So, to hype things up, you need good terms, great words…

And you know, no hype, no glory…

[hype]

If you are studying agile methods, you are already behind. There is already a new bread of project management approaches at the horizon.

As you know, different circumstances may require a different approach. If you need creativity to solve a problem or to create a design, you need an easy going, stimulating approach; if you are running towards a deadline to get in to production, a rigid, centralized controlled environment is more the way to go. Depending on the environment and general circumstances a project manager should construct a process and organization that serves him or her best.

[\hype]

So actually, you are going to borrow pieces from existing methods, and make one that suits your needs. Nothing new here. But I need a good name.

How about: Project Management Method Engineering?

I already see some new jobs: the project management method engineer. Or more hip: project profiler.

Personally, I would go for "cut&paste-" or "beg-steal-borrow"-approach. But it doesn't have the right hype.

[hype]

Be part of the new PM revolution. Discuss with the founders the all new Project Management Method Engineering!

[\hype]

So, I finally decided on Project Potion. As I point out in the book…

At the end of all those pages, you will feel like an alchemist that throws all kinds of liquids into a jar, mixing it up, stirring it, and creating the perfect blend, a kind of secret potion. At one time, you may need Project Potion No. 4, and on another occasion you may find yourself completely happy drinking Project Potion No. 1. Im mentioning this just in case you are wondering why this chapter is called ProjectPotion.

You see, I find it difficult to use those heavy sounding, difficult names… hope it doesn't ruin the hype :-).