In my quest to analyze project stakeholders I came across some very interesting observations by Alistair Cockburn in his book Agile Software Development. In the first chapters he doesnt discuss agile, but he is describing characteristics of individuals and groups that, in his opinion, lead to why agile is a good method for certain projects.

The part that particular interests me is mentioned as Overcoming failure modes. One of the characteristics of humans the project manager should take into account is the mode people are working in. This is more or less a default behavior people have, strategies they tend to do more likely working in projects.

The failure modes are behaviors that probably lead to problems in your project. So recognizing them will bring you already half way a solution.
Read more

There is so much knowledge about software project management available in bookstores, universities, businesses and the internet, if you encounter a problem in your project, chances are the right solution is already invented and waiting for you to find it.

Two problems are popping up here:

1) how do you define the problem in your project?

2) how do you find the right solution for your problem?

There is just too much information about it, but even worse, we are lacking a good vocabulary to link project problems to solutions. If I want to tackle this Project Profiling thing, this is one huge problem to solve.

How to solve it? I dunno. I do know that if you want to be able to use it in everyday project management, it should be simple and easy to use¦ so no huge frameworks and theoretic models.

Two possibilities come to my mind:

I love the solution provided in AntiPatterns in Project Management: they list some sentences that people use to describe the situation: "They Don't Leave Me Alone!", "These Users Keep Changing Their Minds". If you walk around your project these sentences stick out and keep on lingering in your mind. Using these "anecdotes" as they call them, you can identify problematic situations and look up solutions based on the sentences.

Another possibility is the use of analyzing trends in metrics, like schedule slippage, budget overrun, programmer productivity, size of backlog, number of change requests, number of bugs found, number of test cases performed per day. The pattern of the trends can be a starting point for analysis, and combinations of these lines can be used as a descriptor of a problematic situation. This technique is used in The Fifth Discipline.

Most problems in a project occur when the project is actually running. This may seem obvious, but consider the amount of time spent on analyzing the situation and taking measurements to counter potential problems; the majority of this is done at the start of the project. When the project is running on full speed, when everybody is very occupied with their day-to-day work the need for analyzing project circumstances increases, but is hardly done.

Project Profiling attempts to create a set of techniques just for the purpose of quickly assessing a project that has some problems, and to deduct in a speedy way counter measures.

At this moment the potential candidates are:

• Traditional Risk Management
• Stakeholder Analysis
• Fifth Discipline Archetypes
• Project Management AntiPatterns
• Agency Theory
• Job Gap Analysis

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 :-).

Here is an interesting point that Lauri Koskela and Greg Howell mention in their article I forgot to mention in my previous posting about the fundamental problems concerning plan-driven methods. The lack of information about how the project plan should actually be performed. For example, the PMBok guide is amazingly brief about this.

So, management creates a plan, throws it to the working people, and that is about it; no comments on how the working people should operate. We all know that to start a specific task, some of the needed materials or resources might be missing. Then the informal and creative process of fixing and improvisation will start to allow to start on the task anyway, or to minimize the effects on other activities.

Although the execution of project tasks consist for a large part of improvising to make the scheduled tasks happen, the plan driven methods provide no underlying basics for the execution. There is just the plan, and if something has to be changed, it start by changing the plan. And thats all there is to it.

For the subject of numbers around software projects Level 4 of the Capability Maturity Model (CMM) is da bomb: software as a Quantitatively Managed process.

A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the process.  (CMMI)

Wow. Project Number Fetishist Heaven! I thought I check it out for some nice entries to put on this site. Well, I got more than I bargained for¦ thats just too much¦ but it is great fun¦

Fun? you ask.

Well in some weird way¦ Think of all those students that after years of university can do all those quantitative managed things, just to find out that for them as a novice it is useless. They need experience to do all those numbers.

He, it says so in the CMMI description self:

One essential element of quantitative management is having confidence in estimates (i.e., being able to predict the extent to which the project can fulfill its quality and process-performance objectives). The subprocesses that will be statistically managed are chosen based on identified needs for predictable performance.  (CMMI)

Great. You have learned all this stuff, and you will be ^%^%^ by an old frustrated programmer that provides you with bogus over the top estimates. Should be frustrating

And¦

Another essential element of quantitative management is understanding the nature and extent of the variation experienced in process performance, and recognizing when the projects actual performance may not be adequate to achieve the projects quality and process-performance objectives. (CMMI)

You see that your budget is going down the drain, but you need real experience to know the difference between real panic or just normal project behavior (BTW thats normal behavior).

Yeah, numbers are a funny thing¦ they provide you with an aura of precision, but you need sooooo much interpretation to give them the proper meaning. Like they say: you have lies, more lies and statistics¦ or something like that :-).