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.
Thinking Spirits ... 
Are these indicators visible, red lights, dashboards or white board, to the team as well?
Hopefully not. This is basic “Project Management by Hygiene” – as I term it.
Or if you were referring to Insanity Indicator, well it sure would not help anyone to know how insane their project is going.
The gist is to improve one’s habits (and by extension, the hygiene). So the people who live in slumps or with smelly animals don’t realise that their environment is actually smelly, even if you made an indicator to denote the smell. (“Power of Habit” by Charles Duhigg was instrumental in teaching such concepts).
Hygiene will help you attain clarity in all aspects from time logging properly to task management and decision making (Read “Effective executive” by Peter Drucker – thanks to Ather for recommending that).
The only indicator is progress and only goal is to “ship it”. For post-martems, you can do things like this. Ill planned backlogs and unhygienic conditions are the biggest cause of slow progress. The onus lies on the management, not the leaf nodes (engineers, in this case). (Read “The Essential Deming” – the Father of Quality as he argues that quality is not a metric for the engineers but the management and they are responsible for it solely).
May be I am working in very different environment than you. I am coming from Agile paradigm. Agile advocates empowered teams. Instead of managers, there are scrum masters and coordinators, my turn to use some buzz words,it is more about servant leadership. So it is very useful for the team to know how well or poorly “team” is performing. If there is a useful indicator, i (in)sanity index, then it could be useful to share it with the team so they can improve. I would argue the index is any good, it is an indicator of “progress” so it is extremely useful.
So if I understand your point people with bad habits that they can’t fix themselves because they can’t detect it but does it mean you are not for self organization of developers because they are not capable of it? I would strongly disagree but we are digressing. When it comes to Software developers instead of blaming the individual one should focus on systematic failures. So to extend your analogy it would be more useful to think why developers have slum like situation that they can’t differentiate between good and bad practices. Even in this case insanity index is extremely useful because it will indicate if they are going fast or slow. In the end it is all about the flow and identifying bottlenecks(Kanban):)
Good point. I have not converted my teams to completely Agile.
About the bad habits point, no I don’t mean to say they can’t fix themselves. They surely can. What you need is a technique that works to show them their smelly habits are actually hurtful. Mostly, people have psychosomatic tendencies – they continue doing things that hurt themselves. So here “Servant Leadership” + “Leading by example” is a good technique, which I tend to do a lot wherever I can. I usually get the “no, let them do it themselves” argument from my higher ups – but you really can’t beat furniture into a carpenter – yet working as a drafts man and seeing good architect can surely teach you a thing or two to make your own plan. So I’m completely with you that we don’t need to blame individuals and that’s how the hygiene, at least in the start, is management’s responsibility (no matter what you call it, Scrum Master, Project Manager, Tech Lead, CEO, COO).
You certainly nailed it with Kanban. That’s like the 5-star hotel of project management I think 🙂 But a long road considering the talent pool I am currently assigned.
About your talent pool comment, I hope your team does not read this comment:). My suggestion would be instead of focusing on individual and their talents try to create a culture for improvement (kaizen).
Nice thoughts Zaki and in general we should pursuit ways on getting things done and improving our work. But I am against any formulas and equations in software development (or for that matter any place for knowledge work) as I don’t believe humans operate that way. I hope you are not serious about this index and just proposing a food for thought. I hope 🙂
Thanks Majd. Yes, just food for thought 🙂 The actual focus is on the “human” side of things.
Pingback: Happy Birthday Thinking Spirits! | Thinking Spirits ...