0

Do your projects keep end-customer value sacrosanct at all stages in their life?

Or does the heavy-lifting of all the decisions, compromises and trade-offs  end up with key end-user value being sacrificed (often without thought) in order to achieve a technical outcome (e.g. delivery on time?).

shutterstock_126807431 Do you feel like project teams are lose sight of the value that a project is delivering?

It’s so easy with technology type projects to lose track of customer value.  I think above all there is a mapping or translation process that happens in only one direction.

Assuming that you have a good understanding of the precise problems that a customer is trying to solve (perhaps a big assumption), there is inevitably a translation of those problem or value statements into the world of the technology domain, so that the good members of your team(s) can start defining the technology components that will enable that value.

Once the translation to technology talk happens, it never seems to happen in reverse.  We start with “customer speak”, continue with “technology speak” and from there we continue with “technology speak”, even when reporting back to the customer.

But what if there was a relatively simple way for that concept to be maintained?  At least it’s simple in concept, if not in practice: it’s called “focus”.

I am often reminded of themes from an old movie when I see a team start to forget what they are trying to achieve, in the midst of hectic project delivery activities.

This movie (Quest for Fire) is set in Palaeolithic Europe 80,000 years ago, and follows a small Neanderthal tribe who know how to use fire, but are unable to make it.  The tribe keeps a small fire burning in a little portable altar (seen in photo at left), and assigns a dedicated “Fire Keeper” to keep feeding and tending the flame. However, at one point the fire source is extinguished in an accident, and the film chronicles three men who are sent out to find a new source of fire from another tribe.Ulam

Think of the core value proposition in the project as being like this little flame.  Properly maintained, the flame can feed larger fires of enthusiasm and commitment.  Ultimately, if delivered to the end customer, the fire will kindle a much larger fire of success in whatever domain the customer operates: business, personal, not-for-profit and so forth.

The little flame of value in the project can easily be diminished or extinguished by the many forces that routinely threaten any project of meaningful size. Typical examples are dissonance of vision amongst executive leadership, compulsory technical practice guidelines, changing organisational imperatives, and personal goals (including job survival).

 

 

 “Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion.”  – Jack Welch

In any normal project this is difficult, but in a project which has been beset by more than its fair share of problems of any kind, end customer value can be the first casualty: extinguished by the mental and physical fatigue, cognitive overload and just plain stress of trying to get a project over the line.

If we lose this flame, it becomes easier and easier to compromise as the team tries to hit its objectives (typically delivery milestones).

The definition of “optional” or “can make do without” can become framed more and more in terms of delivery options, rather than end-user value.  Especially when the pressure starts to build, we start cutting corners

“High Availability? who really needs it at launch?” “Alarms? Well people should be checking to make sure everything’s alright!” “Testing? Who’s got time for these ‘theoretical’ combinations and permutations or edge case tests” and so forth.

These examples are obvious, if not extreme. But if less obvious components are removed, how are we ever sure that this does not materially degradation customer value.  How can a customer answer this question reliably: “we’re going to go live without the xyz widget in the database”, is that ok?”.  At best the response will be:  “How the !$#% should I know”.  Mostly likely the response will be: “If you think that’s ok”.  And in any case, by the time the question gets to the customer, the work has probably already happened.

To avoid this in a project requires discipline and focus. The discipline to maintain a mapping of the technical world of the project to the view of the customer.  This requires extra work, or at least the maintenance of a work practice throughout the life of the project.  The focus means maintaining that deep understanding of the customer value proposition, so that the mappings have currency and meaning.

How do we avoid this? The answer is “Discipline” and “focus”.

Firstly discipline.

The team has to understand the that the concept of end-customer value is not just some warm and fuzzy idea, it is a real and practical environment felt everyday by the customer and their stakeholders.  The fundamental problem that the project team is trying to solve for the customer is the entire justification for the project, but teams lose sight of this everyday.  It must at all costs be maintained throughout the life of the project.

The discipline to maintain a mapping of the technical world of the project to the view of the customer.  This requires extra work, or at least the maintenance of a work practice throughout the life of the project.  The focus means maintaining that deep understanding of the customer value proposition, so that the mappings have currency and meaning.

Reports, tools, charts and so forth must always contain a realistic view of both domains: technical and customer problem.

Secondly focus.

As a bare minimum, one person needs to take on the responsibility to be the “Fire Keeper” for your project, and for the customer.  This is at least partially the rationale behind the “Voice of the Customer” empty chair in Amazon, and the “Product Owner” in Scrum.

But the reality is that it is hard for a single person to be the “FireKeeper” – they can end up sounding like Stan in “The Life of Brian”, always calling out “and women” to ensure a balanced view.  Sooner or later your team-mates will get irritated and/or tune you out

In reality, the paleo FireKeeper had immense support from the tribe, whereas in modern-day project teams there are many different views and the “FireKeeper” can easily find themselves isolated or accused of slowing things down; of jeopardising the success of the project (how ironic).

The team (the whole team), needs to keep feeding the flame of value, lest you end up with a project successfully delivered (from technical perspective) but which fails to meet its market objectives.

To keep the value flame intact, we have to have it in the first place: we have to have a clear understanding of the project’s ultimate customer value and to be able to share this with other team members and stakeholders.

It requires discipline and focus, but it can be done.