The Story of Every Project Ever

“No battle plan ever survives contact with the enemy” - Field Marshal Helmuth Karl Bernhard Graf von Moltke

Or with the longer form “Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus”, we can probably update it with "no project plan survives contact with reality". 

Reality is the place where, if not otherwise checked, a blame game might start, leading to a lot of lost energy and pointless finger pointing. Perfect deployment is not really possible in any large project. Over complicated project planning, scenario based simulations or stage-gate based goose stepping can’t prevent a deviation of the actual loading from the optimum team allocation. 

While this is a serious topic, that affects both the ability of a team to deliver a project and the profitability of that project, it never stopped Dr. PK Roy and me from taking a light hearted shot at a unified project theory more than a decade ago. I would reiterate that this is not to delve into program management tactics but to generally look at the way most projects spend their lives. 

Regardless of whether you are building a bridge over troubled waters or validating the Autopilot Software Features in an electric car, the perfect plan usually follows the A-B trajectory (blue curve). And yes, I pulled out colored chalk for this sketch; no more black and white! 

The eternal optimists and also usually the guys who successfully sell the plan to win internal or external funding, talk about planning, ramp up, stable deployment along the plateau and then a gradual ramp down followed by maintenance that eventually vanishes away. The A’-B’-C’-D’-E’-F’ curve is an exaggerated version of what usually happens when “reality ruins the plan” to mis-quote Bill Watterson and little Calvin. 

Project Planning and Setup: 

The best start is with homework done with a small team up until point A. This is when the front loading of a project has already been done via an SDK or with some platform elements. By the time a project is nominated or the internal ramp up happens, there already is some basic foundation existing. In reality the team working is smaller because every manager would consciously or casually be hedging their bets in the probable chase that the approval does not appear in time. This version in reality is the slightly lower line up until point A’. If in fact an SDK approach already exists, the lower team size and the length of time until point A or A’ is not a limiting factor to the further implementation of the project. 

Approval Lead Time: 

The time it takes between the planned approval point A to the actual one at A’ cannot be avoided. It is after A’ when the ramp-up-roles are released to talent planning, talent allocation or talent hiring. Unfortunately the delivery dates for the rest of the project would usually not change. This means the same work has to be done in a shorter duration. 

Lost "Work-Time": 

The amount of work that should have been completed at the points were the two curves intersect for the first time (kinda like the area between A-B-A’) is the lost effort due to the later start and the lack of talent working on the project from the beginning.

Compensation with additional "Work-Time": 

Any management team that looks at this situation, feels the best way to compensate for the lost work is by adding more talent and starting more sprints (for those agile Cheetahs among us). This takes a while to stabilize from point B’ to C’. 

Escalation Time:

At some point along the way, C’, the end customer goes wild and feels that the output is not enough. At this stage there is a knee jerk reaction assuming that the way to solve the problem is by throwing money, resources and cannon-fodder at the problem. 

Actually, between B’ and C’ it makes sense to have a mini plan knowing that an escalation at C’ will arrive. The idea then is to plan for the right people or processes to handle that situation, otherwise there is no limit to how many additional team mates will be brought in to warm benches after point C’. Fractal time! people – plans inside plans inside

One of the reasons not to fall for the trap at C’ is because, even with all the best intentions, the customer is not always right. 

• Just adding new people at C’ will never bring them up to speed in time for most of the project needs
• Managing additional people often is more overhead than the output expected from the additional team members 

The only useful scenario is when the additional pressure on disorganized delivery organisations forces them to finally bring their “A-Team” into the mix at C’; ideally the “A-Team” should have been in all along from A or A’. 

At some point between C’ and D’ either the stakeholders decide to de-scope the project or they finally start seeing results. 

Over the Cliff: 

After some time spent in actually delivering the project, a senior bean-counter or a business intelligence report would automatically raise a flag to the top internal stakeholders. The customer might be happy, but the project is now over-budget and burning cash rapidly. Depending on the jitteriness of the top internal stakeholders the steepness of the cliff is quickly defined, often with the plug pulled immediately on the team’s budget. With neither knowledge capture nor proper documentation of all the lessons learnt, most of the team vanishes with a quick “so long and thanks for all the fish”. 

The Cat Bounces: 

E’ is when the end customer asks for all the remaining features and project finalization. Talent is quickly searched for, in this additional push towards the finish line. If some of these folks actually worked on the same project between B’-C’-D’, then they fix all the issues and wrap up nicely. 

Maintenance and magic:

Maintenance in the perfect world is with a stable smaller team who handle changes, check for needed updates, test everything and support the end users. However, often the right folks were pulled out too early into newer projects. This brings us to the first big ticket from the end user at F’. A quick team is reassembled making this one more mini project. More little fractals of the perfect project plan for these mini projects. 

The reason this phase can actually be quite magical is because, if done right, the maintenance phase is the best time for team mates to actually learn more about the project and more importantly the technology. All this while getting ready for the pressure of another new large scale project, with less overall pressure during maintenance. When was the last time you had a CEO screaming over a maintenance fix? By balancing the interests of the team members continuing on maintenance with those of team members planned for challenging new projects, both phases in the future can be delivered competently. 

Moral of the Story

There is no concise moral to this story, because at the time, we were just amused by this template. It is important that knowing what has to be done, and when; having the right talent at the right time is far important than just having bench warmers to show an end customer when a pompous parade is considered the convenient calming tactic during an escalation. 

At the end of the day the output overshadows the optics. 

So many friends and colleagues from diverse industries talk about how, so often more than knowing what has to be done and getting it done efficiently, is less valued than a management style of creating and then avoiding your own self-made crises. Awards are given to teams that made colossal screwups, performed gymnastics and pulled off miracles to please customers. Usually no awards are given to the guys who said they knew what they had to do, they set up the project well, managed the minor escalations, fixed a few additional bugs and then they delivered the project successfully with minimum stress. 

However, a simple recommendation would be not to do managerial maneuvers for awards. Do something right and early, so you can work smarter and not necessarily have to work harder, and do it because YOU want to. 

We know that … we do it because we want to!