A Methodology for Crafting Awesome Experiences – Part 5

Part 1 – Introduction

Part 2 – Strategic Measurement Framework

Part 3 – Design

Part 4 – Validation

If you had not had a chance to read through previous installments, please do so you can find the proper context.

So far we have created out new, or improved, experiences on paper, validated them with clients and internal stakeholders.  Now we are ready to deploy them.  This section of the methodology is where most of the work to do is going to be non-technical, and not related to computers.

The vast majority of deploying new experiences is to actually change processes, actions, and in some cases even automate some previously-done-manually functions.  As you can imagine, this is not as much exciting work (although some of the results can be exciting), but work that requires either creating requirements and working with IT and Development people to make changes to systems and programs, or working with managers and division leaders to make changes to the way they work.  In some cases, it may even involve selecting and implementing a new system or tool to assist in the new experience.

Most of this work has already been done by your organization and it is likely that guidelines exist, people who are in charge of specific departments have their own way to proceed with this type of project, and specific functions and people (such as procurement and IT) will need to involved.

Instead of going step-by-step on how to select a vendor, implement or change a new system, or negotiating a better licensing deal – which are all already being handled one way or the other internally, I tend to use this stage for two things: emphasize the importance of change management and enforce the best practices that make the process a success.

Change management is a discipline, not a software or methodology, that must be embraced by any organization undergoing massive changes.  It is recommended as a corporate initiative to be used for all projects, but it really makes a significant difference when doing larger projects since they tend to be more political in nature, and the changes required are more dramatic for more people.  The best advice I use for organizations when we embark on any large-scale project is to adopt a change management discipline before we start.

Change management has a set of procedures that, when backed by senior management, ensure that political fights don’t get in the way of progress.  By submitting each conflict for resolution and having a final position endorsed by senior executives, it guarantees that steps that must happen can happen.  However, focusing only on the latter part of it, the resolution, is not the best way to use it.  Key aspects of it are to prevent any problems before they arise by using one of two methods: either bringing in the potentially conflicting workers (people who will see their job change or be affected) into the design and development phases of the project (think of it as a co-design with internal customers as opposed to external as we did in previous phases), or working with Change Agents.

Working with change agents is the most beneficial part of change management.  Spotting them could be hard, but when identified they become key ambassadors for the project if adequately managed.  A Change Agent is a worker in any specific department or business function whose opinion is respected, in some cases even revered.  These are the people that either had designed the current process, or have worked at it for so long that they are recognized as the experts on it.  Their opinion and recommendations on how to perform a process are followed, and their expertise is sought when an issue arises. While is  recommended, if possible, to involve as many of the potentially affected workers in the design and deployment as possible, being able to target and leverage a change agent trumps the value that involving more workers can provide.

There are three best practices that will ensure that deployment is smooth and consistent with your plans (that is, beyond change management being a part of your project).

• Involve the customers – You have already involved the customers during the design phase, took their advice and built the experience they wanted.  Now is the time to make sure you did a good job.  Prior to the release to the world, you have to find a way to get the feedback from the same customers you relied on to build the experience.  If it is a web-based experience, run a test with them. Or have them call the new call center and test the script, or bring in a focus group to run through the new experience.  Involving the customers will bring two benefits: first, it will give you feedback as to whether the experience you implemented was the same they designed.  Second, and most important, it will close the loop with them.  Closing the loop when requesting feedback is paramount to build confidence in the customer that they are listened to, which builds a long-term loyalty and increases response rates.
• Stick to the schedule – Delaying a release of a new experience program can cause more than just a late delivery.  Given all the people that are involved – internal and external customers, senior management, business stakeholders – the damage done to the reputation of the team is worse than that.  If you are late delivering on experiences, the collaboration that is necessary to make it happen in successive iterations will not be the same.  Remember that delivering world-class customer service is about under-promising and over-delivering.  Focus on that when setting a schedule for release.  Meeting expectations in each release is key to the long-term success of the initiative
• Advertise the availability and the results – Even though it sounds like an oxymoron, it is essential to advertise what you are doing, and what are the results – both internally and externally.  Many experience projects think that just the buzz and momentum of the project will carry it, while in reality the only people who are expecting the new or improved experiences to be released are simply the ones involved in the project.  As soon as a new experience is released, the project should advertise the availability, monitor the results, and advertise the results.  Initiatives that advertise the release of the new experiences get a 35-40% higher initial use rate than those that expect customers to find out about it – and that increased rate justifies the existence of the program.

Thanks for hanging in there for this methodology.  Just two more, the most fun, installments.  Next one will cover measurement and the final one will talk about creating an index that spans the entire experience as opposed to single metrics.  Yes, they are related.

What are your thoughts so far?