Actually, too much planning CAN be a bad thing…

Deep, cloistered analysis and planning phases are robbing potency from your enterprise projects

Despite the rise of iterative product development methodologies over the past decade+, there are still many large IT organizations that operate in a completely waterfall mode. Stated reasons for this are many, including:

1. It seems to work okay
2. They feel they need that level of planning to efficiently engage stakeholders and partners from across their complex organizations
3. Corporate intertia
4. Agile is for hippies

During the initial phases of a large, complex, enterprise capital project, the work effort consists mostly of research, analysis and planning — the “Detailed Design” phase in a classic waterfall SDLC. In this phase, a chosen group digs deeply into the requirements and constraints in order to define, to the greatest level of accuracy possible, every facet and implication of the upcoming project. Planning, planning, PLANNING! Because more planning is always a good thing, right?

errrrr…. actually, that depends. Planning is good. But just like so many good things in our world [bubble tea springs immediately to mind], there is a natural threshold at which even planning can become counterproductive.

Consider the following three byproducts of a long and deep waterfall-style planning and analysis cycle before project work actually begins:

Non-Collaborative Analysis

The classic waterfall SDLC has a small team of analytical resources executing all the deep thinking up-front, as a service for the many other specialists who will be involved in execution. This, “we’ll figure it out and just tell you guys exactly what to do” philosophy is counterproductive in many ways.

documentation sucks

First and foremost, humanity hasn’t yet invented a seamless medium through which to transmit fully-formed, highly complex and nuanced concepts between brains. Perhaps in a future world of virtual reality or wetware, this gap will be closed. But for now, we’re mostly stuck with the words and pictures that make up the vast majority of functional/ technical documentation. And while that documentation is better than nothing, it still leaves much to be desired.

The sad truth is that in order for those many developers, testers, and other team members to add value to the project they will need to engage in much of the same analytical thought process that occurred during the Analysis phase. Human understanding is built in layers. Just painting a picture of the destination often isn’t an effective way to transmit knowledge. People need to walk the path that leads to the destination in order to fully comprehend associated nuance.

“Yeah, yeah, I read the docs. But can we grab a room with a whiteboard so you can help me understand what it really means?”

unlocking imaginations

Establishing basic shared understanding of the material across the team is a prerequisite for progress. But if you want to take that progress to the next level, you need all of the key project resources to not only understand the requirements as stated, but the underlying business drivers, as well. Only then are those resources in a position to think _beyond_ what is requested in order to suggest optimizations and enhancements that the analysts might not have thought of, themselves.

cheaper than churn

Among the most radical suppositions of the Agile process is that all key team resources should be involved in every phase of the project — including detailed analysis. It turns out that while it costs money to include the software testers, for example, in the analysis process, that cost actually represents a savings when compared to the churn that will otherwise occur during the quality assurance phase of the project if those testers are working without understanding the underlying context.

deep divers

Awesome analyst resources are still pivotal for their skills at ‘going deep’ into a body of knowledge and teasing-out the key concepts. The point here is just that those analysts should be flexing their muscles in close collaboration with all of the other specialized resources on the team.

Expectational Debt

Humans are awesome at imagination. Especially when those imaginings surround the dissipation of pain or the generation of joy. Left to their own devices, humans can dream-up some stupendous shit that can never actually be built within the constraints of a reasonable project. I refer to this gap between the amazing imagined and the more pedestrian reality as ‘expectational debt’, and it has been a component of nearly every waterfall project I have ever run. And the downfall of a few.

“Left to their own devices, humans can dream-up some stupendous shit that can never actually be built within the constraints of a reasonable project.”

poc-to-prod

Instead of setting unrealistic expectations through an unfettered analysis process, let’s set realistic boundaries for what can be accomplished with the assets pledged to the project [human, equipment, time, budget] by conducting our analysis hand-in-hand with construction. Driving the entire process via proof-of-concept exercises ensures that our planning and analysis follows the veins where our execution is strongest.

Pivoting to a “POC-to-Prod” operating model represents a huge mental shift for many organizations. In this model, all initiatives are tentative and forced to compete for light and water based on their ability to generate iterative value. Leadership reviews real progress against understood opportunity and continually re-balances funding allocation based on ground truth. The resulting path may appear meandering, but its wanderings follow the contours of the dynamic market and successful implementation over time.

[Note: Of course, there is a place for blue-sky thinking in our work, and products that only grow based upon incremental enhancement will never make fantastic, market-leading leaps. Blue sky thinking is strategic, and should be engaged within the realm of strategic planning. But beyond that, when the rubber meets the road on planning a project with realistic profitability and efficiency constraints, driving the process via group analysis and proof-of-concept exercises is absolutely the way to go.]

Squandering the Mandate

Arguably the most important reason to avoid an insular analysis and planning process is that it is such a cloistered effort. Enterprise projects are difficult to fund! When we are finally able to gather enough buy-in and enthusiasm around a concept to get it sponsored, we want to harness that momentum — immediately — to make visible impact. The worst thing we can do, from an internal marketing perspective, is to disappear into a hole for twelve weeks to generate a bunch of documentation that those leaders who just funded us will never read or understand. How much better to leap into action, start plowing through the thorny use cases, and begin generating real assets that prove [or disprove] the underlying hypothesis?

“When we are finally able to gather enough buy-in and enthusiasm around a concept to get it sponsored, we want to harness that momentum — immediately — to make visible impact.”

Leadership attention is a precious asset. Once we earn it, we should maximize by delivering tangible value those leaders can recognize and action around.

The Upshot

Planning is important. And in large, complex programs occurring in elaborate and/or regulated enterprises, absolutely worthwhile. There is a very real danger, however, of going down the rabbit hole within which too much planning does more harm than good.

Non-collaborative analysis, expectational debt, and squandering the mandate are just three examples of the damage that can be done to an enterprise program with this approach. Combat these risks by pivoting to a “POC-to-Prod” operating model where the focus is on driving to tangible, iterative value as quickly as possible.

embracing the unknown

This approach can be a challenge for leaders and organizations acclimated to thinking about projects in terms of, “I plan the whole thing, completely understand the scope, and know exactly what will be delivered at the end”. But if you look at the history of traditional waterfall IT projects over the past forty years, you are forced to concede that much of the analysis generated to represent these projects turned out to be wildly invalid, anyway. The alternative approach is to accept that very little is known, meter out investment into tranches representing time-boxed POC-to-Prod blocks, and tune along the way based on real output.

The root driver behind all of this is a desire to obliterate the unknowns in an initiative before making the associated investment. It’s a valid strategy: trap and quantify all of the unknowns via extensive analysis, and then just do the math to calculate your end date. But we’ve all learned from hard experience that approach just creates a brittle tower of assumptions, ultimately doomed to failure. We need to accept that it is impossible to obliterate the unknowns. Instead, we must create a structure through which we can control our investment and risk while we plow through the body of work and address each unknown as we stumble across. Its a messy business, but hey — that’s product development.

Kick in the Pants

If your enterprise programs are feeling stuck, and bootstrapping projects is a slog that frustrates leadership and crushes team morale, maybe its time to look at your initial analysis and planning patterns. Accepting what can/not be known about a project before it begins and re-tuning expectations and workflow around those corollaries might be just the kick in the pants your process requires.