In my life in information technology consulting I have had multiple roles and responsibilities. I have been the developer, the analyst, the designer, the project manager and, yes, the scapegoat. I have a healthy disrespect for leaders who believe that project teams can deliver anything that they can sell. My views and opinions on projects have been developed in the trenches over the last couple of decades. I have tremendous respect for the wisdom of the trench rats who survive great wars over and over again. Stuff that goes on in projects makes one wonder whether projects are destined to auto-destruct half way through. It must be the work of miracles and alchemy that projects conclude with reasonable results with such regularity despite all the efforts of the stakeholders to help. Here are some interesting observations that I have made when I have had a chance to reflect. At least, I find them interesting. I hope you would too.

Whatever you do is either a lesson learned or a best practice
Tasks and activities come out of guidebooks or a body of knowledge that is often labeled as the methodology. These methodologies are distilled out of experience of delivering projects over the years. The intent is to lay out the best way(s) to get the job done. They also reflect the work ethics and values of the delivery organization. But a project is, well, a project: “a temporary endeavor undertaken to create a unique product or service”. The keyword is “Unique”. Project participants, consequently, believe that the gospel, guidebook, or methodology does not quite apply. It has to be fine tuned, modified and adapted to the ground realities of the project.  The resulting misadventures seem to make up for the vacation rides that project members fore-go in the name of the project, the greater good, the resolution of issues like world hunger and global warming. At the end, the job is done. Or, player fatigue or fund leakage or the departure of the guardian angel renders the project deemed completed. Then everyone gathers round a campfire and recounts the glory of battles recently past. A pattern emerges, Common Sense if rediscovered. On closer inspection one would realize that anything that worked probably worked in the earlier projects too; and can be found in The Guide and are Best Practices. Stuff that did not work, where people became lemmings, are listed as Lessons Learned. These are flogged to death or till people are tired of them. Most of the times they are ashamed to admit to these temporary lapses of sanity. These are forgotten and slink into the Lessons Learned lists, bidding their time to be called to action in the very next project.

Project conclusion is independent of Project Status
Most projects go-live. I said “most”, as calling off the siege due to fund exhaustion or a new toy in town is a possibility. Most projects, if not all, are known to be flagged off as being in the Red at some point of time in its life. But project status is most often a morning news item that isn’t really relevant during the day. How often does a status report call out a 9/11 event? So life goes on. I have been in projects that have been in the RED on the day of a software release or go-live. I have been in projects that have a jaundiced Yellow status throughout its life time. The beauty of project health is that the color of the status lies in the eyes of the beholder. Behavior of information coming forth in status review meetings is also very interesting. New inputs tend to explain away – or present the proper context – data points behind the project health color. And then there is the Hawthorne effect. One would expect that it would have nothing to do with projects, or status, or project status. But it seems the act of being observed does funny things to the project status. It changes on you and what seemed yellow seems green from one angle and red from the other, while it takes on a deeper green hue to some. I would like to submit, please do away with the traffic signals in the project status report, steering committees jump red lights all the time.

Go home plans are more important than Go live plans
Project managers know how important the critical path is. If anything in that path is delayed then the project is delayed. Anything as in “anything” – ranging from sign-offs, to server availability to solving all problems within three days of being discovered. By “project” everyone off course means the “Go Live” – that moment of truth, that achievement of the Nirvana. But who doesn’t also know that “Go Live” is also a state of mind. The decision to go there is more often a political decision than a technical one. Those most impacted by whatever is to “Go Live” have the least to say about it. Assessing the Readiness of the Organization is a tricky thing. Who believes in the status reports anyway? So the project goes Live. The poor consultants, the delivery organization personnel, get into a phase where they have supposedly delivered, but are indispensable to the healthy continuity of the solution that some one else had deemed seaworthy. They are, in a word, stuck. Individual consultant often quit and need to be back-filled by fresh blood. These souls become the Dead Man in Yossarian’s tent; the replacement pilot killed in combat before he had officially reported for duty. Since he was never there, his personal effects (in this case the consultant) can not be removed from Yossarian’s tent, in this case the project. Those folks some how do not find the eject button continue to live in a construct, like the train station in Matrix, that is almost impossible to break out of. So I hold that “Go Live” plans are necessary but not sufficient. Those plans keep the wolves at bay while any project manager worth her salt continuously keeps working on the “Go Home” milestone.

Early project escalations on trivial but quantifiable issues are Early Warning Signs
The client project manager of an automobile major had raised an issue with my boss. He had observed all the project team consultants were leaving for the day at the close of stipulated business hours. ERP projects, he knew, seldom got delivered successfully without the project team stretching a bit. This happened early in the project. Empirical facts support the client manager’s contention. But he did not have any information that would let us “correct” anything that was going “wrong”. The project was at a stage where the consultants were getting to know the “as is” processes. A deliverable from the ERP software vendor was on the critical path. The project would be in no way threatened if my team took more time than planned to turn in their deliverable, as long as they did not let it get onto the critical path (or critical chain in the Goldratt world) by dint of this delay. On the face of it this was a trivial flag raised too early calling attention to the wrong shadow. I have, however, realized that when the client is uneasy and cannot articulate why, they tend to choose the most quantifiable item irrespective of its relevance or significance. It is an indicator of the shape of emotions and issues to come. The easiest, and entirely defensible, thing to do would be to shrug it off. But the project manager would have to deal with the latent grudge that the client will bear even when they have forgotten why.

Testing is the first casualty of schedule slippage
Conservative project plans are a thing of the 90s. Most project managers inherit aggressive project schedules from the bid team with unrealistic assumptions about the skills levels available to staff the engagement team. As a result the project managers become slave drivers. In one of my projects the team was kind to me, they used to call me the ring master. So. Slippages happen. I do not love deadlines as Douglas Adams did. I am, however, familiar, with the whooshing sound they make as they fly by. They sound like a shell approaching the trenches. After they explode the damage recovery squad gets into action. They requisition a war room with the white boards, markers, a large table and all the other instruments of war. The latest project schedule is dusted and laid out on the said table. The unrealistically aggressive project schedule becomes an impossibly unrealistically aggressive project schedule with the help of innovative thinkers thinking under influence. The first casualty is always the integration testing or system testing. People forget that the intent was to add a performance testing piece that would have taken more time. Then there are assumptions thrown in that reduce the user acceptance testing. Finally plans are drawn up whereby the testing track falls off the critical path. Often with the sanity of the test cycle compromised the rush to recover and stick to deadlines resembles the Charge of the Light Brigade.

These were just five of the laws of projects that I thought I would share here. I am afraid that I have stretched the patience of readers and don’t want to risk losing whatever little audience I have. There are also other observations that you may have and may want to reflect on. To start you off, here are two such points to ponder. The extent of adoption not correlated to quality of solution. In designing software, usability and response time are always afterthoughts. I would enjoy hearing about your thoughts on these.