Customer Experience – Implementations

When you translate a dream into reality, it’s never a full implementation. It is easier to dream than to do.”
Shai Agassi
.

After Contract Negotiations, the second post in this Customer Experience series, today’s post discusses the next step, when the project moves into the implementation phase.

The customer experience during the implementation stage basically revolves around variation (from the dream).

CUSTOMER EXPERIENCE.
Project implementation is basically constrained by a combination of scope (functionality), time and costs. Complex projects like major OSS transformations rarely stay on target on any (or all) of these three key variables, which doesn’t help to deliver a positive customer experience. [Aside: An earlier post describes the triple-constraint of these three variables married up against an additional three constraints (resources, risks and quality) as described in PMBOK literature.]

WORKING BACK
There are millions of techniques aimed at limiting variation on scope, time and costs on OSS projects, but some of more important ones tie back to ruthless simplification. That means ruthless simplification of everything you can simplify, from requirements, project reporting, meetings, change requests, workarounds, etc, etc.

As an industry, we seem to make complexity of our OSS an artform. At their very core, they tend to be very complex, so we should be doing everything within our power to not throw further complexity on top.

In addition, it’s the complexity that means we’re unable to plan for all circumstances ahead of time, via documentation such as solution architectures, detailed designs, etc. Rather than getting bogged down in the what-if scenarios of the design, I’m a strong advocate of building sand-pit environments first based on higher-level designs.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *