We Can’t Finish Until We Stop Starting

Managing the risk of requirements churn during the product development design phase

Sometimes these posts come rolling right out of my noggin, and other times I struggle to articulate the point in a compact and understandable format. This post falls into the latter category. To help combat that situation, I’m going to drop the conclusion right up top:

In Digital product development, the highest likelihood of change occurs at the beginning of the project lifecycle, during the design phase. We must recognize and expect that, including adequate time and cost into our planning so this eventuality doesn’t derail the project right out of the gate

Okay, now that the truth is out there, let’s unpack it to understand why that is and how it should best be managed.

Project Lifecycle and the Cone of Confusion

Much has been discussed in this space about the power of standardized process in product development. Whether you utilize a software development lifecycle [SDLC] like my “5 big D’s” or some other approach, having a ready template to help map out new projects is a huge boost.

For the purposes of this discussion, let’s ignore the specific SDLC and simply represent progress as a single horizontal line with the project’s kickoff at far left, and completion at far right.

The “Cone of Confusion” is an Agile concept recognizing that we understand the scope, solution strategy, and implications of the project least at its beginning, and most on the day we finish. It is through the act of executing the project that we gain mastery over its subject matter. Inconvenient timing, I know.

Note that the cone of confusion is at its widest in the very beginning of the project. The further we move through the project, from left to right in the diagram above, the more clearly we understand its subject matter. And the more narrow that theoretical cone becomes.

Because our level of understanding is at its lowest in the initial phases of the project, that is also the area of greatest risk of change. This makes sense, right? It is during those initial conversations that both customer and execution team are presenting their points of view, exploring feasibility, and riffing off each other to envision the very best product possible.

It is during those initial conversations that both customer and execution team are presenting their points of view, exploring feasibility, and riffing off each other to envision the very best product possible

This is natural, exciting, and how we win in the marketplace.

“Concept, Meet Execution”

Hooray for all that, but the current techniques for converting cool ideas into working Digital technology require a team of people working in close collaboration across lengthy timelines. What this means in practice is that the scope at some point must be locked to create a stable target for that team to develop against. Estimates around work effort, cost, infrastructure, partner integrations, and other project constraints are all based on this stable scope definition, sometimes referred to as a “baseline”.

Nothing will cause a Developer to sling their laptop across the room faster than the regular occurrence of, “hey, remember that thing we asked you to start building yesterday? Yeah, we changed our minds and now need you to start building this, instead.” That kind of practice is also a great way to run a project that chews through funding yet makes no progress.

As established above, the creative churn involved in the design process is pretty much unavoidable due to the cone of confusion, and arguably necessary for the creation of awesome products. And yet, at some point we need to call a halt to all that experimentation in order to establish a baseline stable enough for the team to develop against. Successfully contending with this friction is critical to effectively managing this portion of the product lifecycle.

Vendor Implications

It is not uncommon for there to be at least three distinct entities involved in this phase of the project. There is a customer, obviously, who is bringing the vision and signing the checks. Often there is also a design agency helping guide the customer in articulating their vision into something actionable and enticing to its target market. Much of the time, technology solution providers charged with converting those design concepts into working software are involved in these early phases, as well. Whether these are separate groups in the same enterprise or different companies, the danger remains the same.

This situation becomes particularly fraught when the deadlines and budget for the project have already been established before all this activity takes place. And turns into a pressure cooker if the players involved are vendors engaged through some form of fixed-price contract arrangement.

Managing Design Churn

This is a “Knowing is half the battle” situation. Just acknowledging and socializing this risk goes a long way to its very mitigation. If everyone is on the same page about the importance of established deadlines, and savvy/compassionate enough to admit that all groups require adequate time to do quality work, just talking about this risk might be adequate to hold it in check.

More often, however, especially when working with customers lacking past product development experience, talking just isn’t enough. For those cases, a few potential solution strategies:

STRATEGY: Find a ‘Follow Your Nose” Product Model

The easiest way to manage the high risk of change early in the program is to find a situation where its implications don’t matter. If budget isn’t a factor, there are no looming deadlines, and we can have access to critical enterprise resources for as long as we need them, most of this risk drains right out the bottom. If we spend seven months generating and absorbing design change early in the program, and that is deemed perfectly acceptable, then let’s keep on rocking.

While this strategy may seem far-fetched, it was the norm during the infancy of the Digital revolution during the late 90’s and early aughts. Plentiful venture capital and a consumer base rabid for Digital products created an environment wherein many teams were free to follow their noses [and hopefully some critical analytics] to create the best products possible. Those were the days. At least until the bubble burst.

STRATEGY: Riff Upstream, Then Stop

For those in a more terrestrial scenario of budgets and deadlines, there just isn’t the freedom to follow our noses in hopes of finding the best possible solution. In these cases, we need to carefully plan the program such that we hit the target date, at or below allocated budget, with a product potent enough to fulfill its intended mission.

Depending upon the organizational structures involved, it may be possible to manage risk by pushing these design activities upstream into their own, compartmentalized phase. All the change risk still exists in this case, but is contained in a controlled environment specifically engineered to absorb it. This may be via some internal Design Lab with a healthy budget and strategic mandates, or via a trusted vendor relationship with a time and materials contract structure. Regardless, the expectation of this strategy is that there is a defined end to the design process — all that riffing — beyond which change is contained to an absolute minimum. If the customer can’t play by those rules once we all exit the ‘Design Lab’ part of the lifecycle, this strategy is likely to fail.

STRATEGY: Cash Contingency

Whether in a manner that is transparent to the customer or less-so, cash is held in reserve to cover the cost for the team to absorb the likely change experienced during this phase. When handled by an external vendor in a transparent manner, cash is locked in escrow until approvals are triggered to make it available. If the customer wants to engage in further exploration, they unlock the cash to fund those activities.

If client/vendor relationships lack the resiliency for this level of transparency, presented estimates are inflated secretly to allow some contingency to ride along with the raw operational cost. We “pad the estimates” so we don’t lose our shirts when the customer demands more change than had been included in our initial planning. This practice begets strategic problems down the road, but when you’re fighting for your life tactics trump strategy every time. Smart customers build strong vendor relationships to avoid situations just like this.

STRATEGY: Predefined Rounds

Another oft utilized approach is to press the design process into a predefined number of ‘rounds’. This approach accepts that the creative process is iterative and participants need to walk a journey so they can incubate their concepts along the way. We plan for a standard process that begins with brainstorming >> moves into some kind of prototype development >> presents that prototype back to the customer >> and collects their feedback. << Those steps represents one round, and the feedback generated becomes an input into subsequent serialized rounds.

As project managers, we can calculate the time/cost of these rounds, and plan for a predefined number to occur during the design phase. This approach gives the customer and team plenty of space to explore different ideas, yet keeps everyone aware of how much more time/cash we have allocated for this activity.

This approach gives the customer and team plenty of space to explore different ideas, yet keeps everyone aware of how much more time/cash we have allocated for this activity

With a really strong customer relationship, we can even afford to allow the customer to cut this process off early if they are confident they have the right answer before we have run through all the rounds included in the plan. An early cutoff has the potential to save cost and time that can be utilized later in the build.

A word of warning, however… Another axiom of project management is known as the “Thousand dollar problem”. This concept states that the same problem can have different costs for remediation depending upon where in the product lifecycle it is discovered:

• If discovered during the design phase, when the team is small and tools are lightweight, it might be solved for $1 of cost
• That same problem, not discovered until the development process is in full swing with a complete team and established expectations, might cost $10 to solve
• Not discovered until late in the testing phase or on the cusp of launch, that problem might cost $100 to fully remediate
• Finally, if that same problem sneaks its way through the entire product development process and is not discovered until the product has been deployed in the marketplace, mitigation might cost $1,000, instead

If anything, I think the sample numbers in this axiom are lowballed. In my own experience, the curve is much steeper and allowing a serious issue to pass all the way to Production could be enough to existentially damage the entire company [SEE ALSO, Tylenol, cyanide, 1982]. But the point of the axiom remains the same.

In my own experience, the curve is much steeper and allowing a serious issue to pass all the way to Production could be enough to existentially damage the entire company

This axiom is generally used to scare project managers into eating all their vegetables, and focusing on due diligence throughout the project run. But it applies to this scenario, as well. Don’t be in such a hurry to capture the savings of chopping a design round or two off the project plan that you leave a problem to fester until later in the process when it will be much more expensive to fix.

Applying the concept of rounds to a design phase doesn’t make the high risk of scope change disappear, but it does provide us with some architecture to hold it in place, slice it into chunks, and ensure transparency for all involved.

As discussed previously, team and stakeholders alike must have a widely shared understanding that once we complete our journey through whatever design process has been chosen, that design must be fundamentally locked for the rest of the build. Without this essential locking mechanism, the execution team will be unable to generate solution strategies and efficiently construct the product. Waterfall and Agile methodologies manage the work differently, but this fundamental truth still holds.

Final Analysis

Technology product development is a risky business, wherein we are building something [relatively] new every time. Even with expertise in the platforms involved, bolting those into a new enterprise is always fraught. The risk of scope change during a project like this is ever-present, and the ‘Thousand Dollar Problem’ axiom tells us that its impact becomes worse as the project moves forward in its lifecycle.

But it is during those heady initial design phases of the project that the likelihood of scope change is highest. Indeed, there is adequate evidence to suggest some amount of this back-and-forth is necessary to create strong products that win in the marketplace. Shared understanding and acknowledgment of this risk is critically important for success. Beyond that, creative and resilient process mechanisms can be utilized to hold that risk at bay so the product lifecycle is able to move forward. We can’t finish the project until we stop starting it. Techniques like these help us maximize the utility of the design phase without allowing it to strangle the project before it really even gets underway.