Extreme Project Management

This week, among other things, I was thinking about two projects I was involved while in Haryana.

1. The Commercial Taxes Project (Haryana Excise & Taxation Department).

After 2.5 years (perhaps more, before we came in) - we are still not done with writing documents and following procedure in this project. Not a single line of code has been written, nor a single computer / software function put in place.

2. The Integrated Finance Management Project (Haryana Treasuries / Finance Department).

Is it 1.5 years now? Or more? We are still reviewing (and approving) documents. Yes. DPRs, RFPs, As-Is and To-Be stuff. Even the selection of an implementation vendor is apparently years away!

What is wrong with us? Is any project so big that we spend years studying, planning, documenting, reviewing and approving? How long do we wait before we really do something that is directly material to the outcomes we are chasing? Are we even certain that the documents we reviewed and approved a year or more ago still apply?

Don't get me wrong. I fully understand the importance of documentation, prior-planning and so forth. What I don't understand is the total perversion in the name of planning and due-process. Where is our sense of proportion?

It appears that the IT Consulting industry has gone berserk. We (individual consultants) are also guilty of being drunk in best practice pretences and dinosaurian wisdom, ignoring the best interests of our clients.

So I have decided to revolt. Starting last week, I've resolved to take these steps:

• I will reject any plan that shows more than 24 weeks of planning and preparatory period (concept to bidder-selection). After that, implementation must begin.
• If a project is too big to achieve this, I will ask that the project be split into smaller parts and/or phased-implementation sequences.
• For projects that I am implementing directly, I will not review any documents. Even requirements documents. Period. Any documents created by my team are for their individual reference (personal notes) only. 
• I will only review direct work products (i.e., software artefacts that do stuff - not describe stuff). Requirements specifications will be approved in the form of partly-working screen prototypes - NOT documents. Interface specifications will exchanged as stub code in a central repository accessible to all team members.
• I know. Sign-offs are important to avoid scope creep (and customers changing their minds). I am therefore declaring that scope creep is not a crime in my projects. Especially when breaking new ground.
• So when we detect that there is a deviation from what is done and what we want, we will NOT focus on who is to blame. Instead, we will focus on correcting the deviation and managing "scope vs schedule". This is important. It will help the team shift their focus away from creating proof (read: signoffs) that they are not to blame!
• I will not go soft on any consultants (and consulting companies) who give me perverted proposals (such as 1.5 crore rupees of program management consulting to manage a 0.5 crore implementation project).

Will I be flamed and hated for this? So be it. It is high time we brought some semblance of balance in favor of the clients. Even Government clients.