What Exactly do you want to be Preditable?

Many companies realize that they need predictability. Various departments and groups within the enterprise may be fully onboard with the idea. But what does it really mean that we need predictability? Predictability of what? This is a very important question. 

Let’s talk about what exactly do you want to be predictable.

Scope and time

First, let’s examine what is usually the subject of predictability in organizational environment. Predictable often means “on time”. A release delivered on time, for instance. The next common variable is “scope”. We want this and this delivered. Now, there are a couple of fundamental problems here. First of all, you can’t fix scope and time and expect good results. Complex effort is never fully known ahead of time, so adjustments are inevitable. At least one of these two parameters must allow for some flexibility. But the issue is even deeper than it appears at first. Even if teams via some tremendous effort, magic and luck, did it within the established time and scope constraints, is that really the goal of the whole development endeavor? 

Of course not. 

Enabling customer success

A solution is created not for the purpose of solution itself but to enable the customer to achieve certain things with it. And it happens way too often that after immeasurable effort has been spent and lots of features created, the solution is not all that effective in solving the customer problem. But it may have been delivered perfectly on time and within the required scope. 

So, here’s an important takeaway: scope and time are actually poor predictors of solution efficacy. If we are looking to predictably enable customer success and business success of the organization that creates the solution, we must seek predictability of different parameters. It no longer matters if 100% of scope was delivered by the deadline. What matters is whether we managed to learn what is and isn’t important to customer and business success and then act according to those priorities. And yes, there will always be a critical subset of scope that will have to be done, but there also has to be flexibility and, importantly, active exploration and adjustment.   

Important questions

Here are a couple of questions for you to help determine the course of action towards better predictability: 

First. What actual means do you have at your disposal to understand what functionality is or isn’t effective for your customer? Do you have a good idea of this before the teams start implementing? Or only after? Or neither? And is your knowledge of what’s important based on empirical data or speculation? 

Second. Is there a productive, regular prioritization process? If the previous item we discussed was mainly dealing with knowing what’s important, here we care about being able to use that vital information and be able to focus on delivery of truly important items, keeping things of secondary importance as a buffer. 

Lastly, is there a routine way for teams and their stakeholders to inspect and adapt their work so as to achieve better customer outcomes? If not than the previous two items will not provide sustainable benefit. If yes, you are on the right track. 

These three questions should help you determine what to do next.

About the Author

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.