This is a guest post by Zaki Shaheen, a former colleague, a smart knowledge worker and now a manager of many of them!

“The definition of insanity is doing the same thing over and over again and expecting the results to be suddenly different.”

– Albert Einstein

Project management (or knowledge work in general) is one of the most brain-tolling exercises and it’s absolutely critical that a project manager keeps her composure. Not just in meetings, but in moving things forward and getting things done. To always have mind like water.

I have seen (read made) a lot of mess ups and delayed deliveries. Whenever I see young project managers make the same mistakes as I once did, I volunteer my two cents.

Yesterday I had a eureka moment to model what happens when a project fails (or is failing). One of the way to do that is to come up with a key performance indicator (KPI). I call this one the sanity indicator.

The Sanity Indicator

Straightforwardly speaking:

Let:

D = number of days since an (important) issue was reported

P = number of people on the project who have seen the issue (had to take a decision on it)

A = number of times it was re(assigned | estimated | written/defined)

E = (initial) Estimate of the task

II = (in)sanity indicator

OK, perhaps that was too mathematical (in the spirit of Thinking Spirits, carried away with models). Never mind, lets see an example:

A high priority issue was identified 30 days ago. There are 6 people on the project (Junior developer, Senior developer, Quality Assurance, Tech lead, Project Manager, Client) and they have been ignoring it (possibly because it’s not descriptive enough, e.g. “improve rate of image recognition”, or encapsulated multiple issues in one ticket, e.g. “Design issues”, or the team had no idea how to go about it, e.g. “use migration scripts for deployment rather than FTP”, or the team or stakeholders were prioritizing it without consulting each other, etc. – by the way, I find these very akin to the concept of Code Smells but in terms of project management). The issue has been reassigned 20 times. It was initially estimated to be solvable in 2 hours (or story points) but gradually the estimates increased. If you calculate the (in)sanity indicator on this (keeping only initial estimate) it comes out to be 100! This is the extreme case example also known as the Cuckoo state of project management (also known as not-knowing-what-the-hell-is-going-on-or-what-are-we-supposed-to-really-do).

This defines the (In)sanity indicator (II) of the project and will give you the sure shot solution to timely delivery.

Makes sense, right? How about you take a piece of paper, an excel sheet, your project management tool and go through the current Sprint (a 30 day work cycle in Scrum process) and see where you stand right now?

The takeaway

Before you take it seriously and start applying it on your latest project, bear in mind that this is entirely fictitious (I’m exaggerating, it might have some importance in real world, I’m just too lazy to write a research paper on it). If it’s not utterly obvious, the emphasis of insanity indicator of a project, task, milestone or team is on the following key points:

How quickly does the team react on a task/opportunity/project/mess-up/escalation (D) How many layers does it pass through and which one truly takes the ownership. Also, how close are we to the stakeholders (P – but should be labeled B for bureaucracy) Is there clarity on the task at hand – and how much ownership does the individual members of the team take (A) How serious is the team taking its work. (E) The overall hygiene of the project management system (which consequently defines its health – because hygiene defines health)

Or, take the easy way, learn from mistakes of others and pick the variant of agile methodology that aligns with your goals.

In short, instead of judging the outcome on personal opinion (like incompetent developers, stupid client, bureaucratic project manager and jaded higher-ups – which all might be true as well, but these are marks of a team without a manifesto), the judgement should come on such data as the “Father of Quality”, Edward Deming says “In God we trust, everyone else must bring data”.

This must particularly start on a personal level (models like GTD and books like The Effective Executive help you achieve it). Neither of this is particular to a technology, field or age. Understanding the principle behind effectiveness will help you choose the most effective variant of the multitude of methodologies already proven to have worked. If you are a knowledge worker, that’s the best I can give to manage things (and particularly to work better with software engineers as a Project Manager).

Depending on the level of structure (or intentional lack of), YMMV! So do you still want to do the same thing over and over and expect the results to be different?

Father to a lovely daughter, Zaki is a reader, writer, programmer and an aspiring life hacker. Previously he has been busy climbing the corporate ladder and playing lot of guitar. You can reach him at zakishaheen [at] me dot com.