Sunday, November 22, 2009

Quick Lessons from 26/11 for project managers

26/11 has been a sober experience for all of us and is certainly evokes strong emotions. I for one would not explore this from all perspectives but try to quickly distill it from a project manager’s perspective. Analogies can be dangerous and sometimes the extensions may be distorting and comparisons weak. If I do hit those notes, do excuse me for the same.

From the way I see it, the government is the Sponsor and the beauracracy is the project owner (and its team members). The event itself is a risk that manifested and all of us as Citizens (who pay tax and in exchange have a right to be able to conduct our lives safely) are end users. Clearly we do invest in Policing, Defence and Intelligence proactively to exactly eliminate these situations.

There are 3 systems that owned the final situation as I see from an end user perspective.
- The proactive risk identification system (intelligence system) to detect the risk
- The proactive risk elimination system ( acting on the intelligence)
- The reactive risk addressal system (fast acting response)

I would like to submit 2 observations as the end user,
1. All the 3 systems failed us as end users . This is substantiated by announcements of changing the existing systems (creating a central authority, etc..)
2. Despite all the news coverage we do not know who owned these 3 systems. ( The design and execution of the systems)

I have seen far too many projects where the lack of a single accountable owner create so much more latency, poor understanding, cross talk, coordination challenges, personality plays and blind spots (all of which I am sure contributed to 26/11). The result in most cases that I know is the project is a failed cause.

I recognise that larger programs need larger structure and logical partitioning of the overall scope but the common theme of lack of clear accountability remains the same and inefficiencies get amplified for lack of clarity and poor alignment. .

Another unique and predictable feature of headless failed projects is that no one gets sacked for the failure. Given lack of owners (the failure makes it even more of a pariah and hence even potential owners actively disown the project – and the lessons learnt are also never incorporated!)

Another mini-lesson I note is the lack of communication to the end user (citizen) in precise way. The noise creators (media) took the lead in creating opinion and the project managers and the sponsors did very little by way of keeping the end users informed. AS a result the mindshare of the end users were lost.

At the risk of extending the analogy one last time – When do we decide that the systems in place have outlived the realities for which they were created? Do we not need to inspect our systems as the environment around us changes?

A final comment - I did start this post with a comment that this will be lessons for the Project manager but as I close this out. I feel it is equally (and may be a larger one) a lesson for the Government from Software engineering!

1 comment:

  1. Well said. Additionally,
    1. Scope clarity: The offendors managed to create an atmosphere of confusion through cross-messages, and agencies were clueless as to how many of them were really present. Different numbers were floating around - 7, 12, 30? We are still clueless about the exact figure. This in turn affected the estimate of the force needed for a suitable response.
    2. Like most projects, this one ended with a final assault, and in the moment of truimph, the team & stakeholders forgot to identify lessons learned, ensuring that similar knee-jerk strategies will be adopted in future instances as well.

    ReplyDelete