DCX/CRM: Avoiding Failure (3)

This is the third of a series of ‘conversations’ centered on avoiding failure when it comes to Digital Customer Experience and/or CRM.  The first ‘conversation’ dealt with articulation-understanding-ownership of requirements.  The second ‘conversation’ dealt with the challenge of integration.  This third conversation deals with the matter of thinking/collaboration that necessarily comes with a transformation programme.

Thinking & Collaboration: Christmas Day

Yesterday was Christmas Day and we (our household) celebrated it.  The day turned out great and it didn’t just happen. For the day to turn out as it did (workable, enjoyable) required thinking/collaboration: the five members of the family had to think, make decisions, and collaborate in making happen that which we decided upon.

Let’s start with thinking/decision making.  We had to decide (as a family of five) where we wanted to spend Christmas. With the children’s grandparents in France in their main home in the country?  With the children’s grandparents with their winter home in the Alps? With the children’s uncle Ralf (and his family) in France? With my sister in the New Forest?  At home?

Where did these series of conversations centered on this question/decision take place?  Around our dining table – as that is the place where we sit, eat, talk things through ever since the children were toddlers.  After listening to one another and thinking things through we came to a mutual decision: we will do Christmas at home!

Next decision: Do we do Christmas as a family or do we invite guests?  Once we had made the decision that we wanted guests for Christmas, we had to agree upon who and how many people to invite given the demands on shopping-cooking-seating-sleeping that necessarily comes with inviting guests.  How did these decisions get made? Through a series of conversations. Where did these decisions get made? Around the dining table.

Did the thinking and decision-making stop here? No. Next, we had to decide (as a group) what it is that we wanted to eat/drink and the dietary requirements of our Christmas guests.  The challenge? To come up with the minimum number of dishes as some wanted to eat meat, others fish, others had vegetarian/vegan requirements.  And ensure that these dishes are the ones that folks want to eat.  Where did this thinking through (as a family) and decision making occur? Around the dining table.

Once the thinking through/decision making) had happened it was time to formulate a plan of action: Who would do the food shopping and by when? Who would go and buy the wine/drinks and by when? Who would prepare the food? Who would do the cooking? Where did these matters get thought through and decisions get made? Around the dining table.  Then on the day itself, we collaborated with one another to make happen that which needed to happen: setting the table up, clearing up the table, doing the washing up etc.

Thinking & Collaboration: DCX/CRM Transformation Programmes

Now think of your transformation programme (DCX/CRM): the elements, the actors, the interplay between the various elements/actors, the sequencing of work, the design of the end-to-end solution, orchestrating dependencies, dealing with the arrival of the unexpected – challenges, opportunities… Ask yourself these questions:

1-Is thinking (and decision-making) required?

2-Is this thinking (and decision-making) a one-off event or an ongoing series (a process)?

3-Is the thinking (and decision-making) that is called for, simple/easy – as in here is a round block of wood, here is a round hole, insert that block of wood into that hole?

4-Is the thinking deep, intricate, multi-dimensional – the kind of thinking that comes up with options, thinks through these options, considers the advantages/disadvantages of promising options, and identifies the impact of an option on the wider transformation programme?

5-Is the thinking (and decision making) an exercise for one omnipotent person? Or does the ‘nature’ of the thinking, decision-making, action planning, and execution necessarily require the active participation/contribution of a group of people?

6-If the thinking is not superficial/simple and cannot be done (or should not be done) by a single person then ask yourself this: Have we created a suitable context & space for the kind of thinking/collaboration that needs to occur in order for this programme to deliver on the promise?

Of What Do I Speak When I Speak ‘Context’?

What is it that I mean by ‘context’?  Imagine that you open your mail and find a wedding invitation for someone who matters to you.  What happens? You automatically know the context by having attended (or seen if it is via the movies) the context that goes with a wedding: the mood, the music, the place (most likely a church for the wedding service), the actors, clothing, the sequence of events, what actions are expected etc.  Now imagine you open your mail and learn that a friend has died and you are invited to his/her funeral.  Again, you know (almost immediately) the context that goes with a funeral – for example, the mood (and setting) will be dramatically different to that of a wedding and the expected behaviour/clothing will also be radically different.

Of What Do I Speak When I Speak ‘Space’?

Imagine that you are charged with staging a soccer game, in a foreign country,  between two well-known soccer teams. On the day of the match, you, the soccer teams, and the fans turn up to the venue What do you find?  The pitch, the space, is set-up for cricket! There are no goal posts. There are none of the markings that a game of soccer requires e.g. half-way line. Instead, the space has been set-up and thus calls forth (supports) a game of cricket as there are wickets. And there are the markings that go with a game of cricket e.g. the crease.

Avoid Failure By Cultivating a Context-Space That Calls Forth Deep Thinking and Collaboration

Time after time I come across transformation programmes where the space in which the actors show up and operate is that of a large call-centre.  Have you spent time in a large call-centre?  If you have, it cannot have escaped your notice that the environment is like that of a large warehouse. What is warehoused?  The people who answer calls!

The kind of space that one finds in a large call-centre operation is suited to the context of almost all call-centres. Why?  Because the context is one where ZERO original thinking is required. And ZERO collaboration is required.  Everything of significance has been thought through and turned into a script: for call type X follow script X, for call type Y follow script Y.

If you wish to avoid failure in your transformation programmes then it is essential that you create a context that signals, to all actors, that here we have to think (deeply) and collaborate – this is the default.  And, you have to create the space to support this signaling and enable this deep thinking/collaboration to occur.  Specifically, this means:

1-Plenty of meeting rooms – where the availability of these meeting rooms is kept up to date and made visible (electronically) to all working on the programme;

2-Range of meeting room sizes – from four people working on a challenge through to 20 people working on a challenge;

3-Each of these meeting rooms equipped with the equipment that goes with the kind of thinking/collaboration that the meeting room is designed for e.g. whiteboard/s, pens, ‘erasers’, sticky notes, audio-visual equipment…

Heed My Warning For The Transformation ‘Game’ Is An Unforgiving One!

I consider this to be a MINIMUM requirement.  Since 2016, I have worked on (and or witnessed) four transformation programmes.  Of these, only one company (global Oil & Gas operator) has provided the context and space I have set out here.  The rest, in my view, failed – the degree of failure varied from one company to another.   Allow me to end by saying this:

1-If you fail to provide a context-space for deep thinking to occur then I guaranteed you that your transformation programme will end up with superficial thinking;

2-If you fail to provide a context-space for collaboration to occur then I guarantee you that you will get silo-based thinking (and actions) and you will end up with requirements that do not gel across the elements of the programme, solution components that will not fit/integrate with another, and dependencies that are not identified early enough nor orchestrated effectively;

3-Where there is lack of context-space for deep thinking and collaboration there you will find a lack of effective leadership and programme management; and

4-The transformation ‘game’ is unforgiving as in failures in effective leadership and programme management will be punished through missed milestones, rework, escalating costs, demotivated actors, finger-pointing, scapegoating, and a sub-optimal ‘solution’ from the perspective of end users – your prospects/customers, your distribution partners, and the people on the front line of your organisation dealing with prospects, customers, and distribution partners.

Enough for today. I thank you for your listening and wish you the very best for 2019.  Until the next time….

DCX/CRM: Avoiding Failure (2)

In the first part of this series, I pointed out that IT centered programmes that involve the term “transformation” tend to be complex and tend towards failure – failure to deliver the desired outcomes to time, to budget, to end-user expectations.  And, I dealt with that which I consider as one of the most important sources of failure – inserting business analysts between those who will be using the technology and those configuring/building that technology.

Integration: The Formidable Challenge of Getting Systems to Work Together as an Ecosystem in a Transformation Programme

Today, I wish to consider, the most troublesome cause of failure: transformation programmes necessarily cover multiple functions, lots of business process, many end users from across the business, and these necessarily require many discrete IT applications (from different vendors) that must talk to one another fluently.  Fluently! Nothing less is acceptable to the end users – whether customers of the business or those in marketing-sales-service who are charged with facilitating the interactions/transactions with these customers

How big of a challenge is this?  Let’s consider this in terms that all of us, especially those not familiar with technology will understand. Imagine a board of directors meeting – there are seven people there, each speaks a different language, and none speaks/understands the languages spoken by the others.  How are these seven directors going to communicate with another and thus work as one to generate that which is expected from a board of directors?

The same is the case for IT systems!  There is a multiplicity of systems none of which ‘talk’ to one another yet they must ‘talk’ (integrate) to one another such that ‘conversation’ (data) flows easily/quickly across these systems.  How to arrive at this – an integrated solution where all the systems ‘talk’ to one another?  How one approaches this challenge determines whether one avoids failure or not.

Here’s One Way to Approach The Integration Challenge

1-Get a bunch of folks together whose title usually includes ‘architect’ as in “solution architect” or “enterprise architect” and get them to agree upon a design and publish a document to the rest of the players – those responsible for configuring/building the individual systems, and those responsible for connecting these systems with one another;  and then

2-Walk away sayings something like “Now, you vendors get together amongst yourselves as and when you see fit and figure out the specifications for the interfaces/integrations” thus neither facilitating nor overseeing this vital matter of working out how the interfaces/integrations are going to work (protocols, data that will flow across systems, direction of travel of this data, the mappings between one system and another, error handling…) and dealing with unexpected complications that always arise.

What Happens When You Take This Approach? 

If you take this approach then I guarantee (as I have seen it with my own eyes) that you are guaranteeing failure. What does failure look like?

1-Many errors are picked up in the Systems Integration Testing phase, and/or the User Acceptance Testing phase. Considerable rework is required from multiple ‘vendors’.  This takes time and effort resulting in Go-Live pushed out further and further, and increasing costs.

2-The ‘vendors’ dodge responsibility and point at others. The client team, including those with ‘architect’ in their title, scapegoat ‘vendors’ instead of taking responsibility for their failure to own/orchestrate/oversee the business of integration – often the most complex piece when you look at transformation in technology terms.

3-End users involved in the User Acceptance Testing rightly become concerned about that quality of the solution. This concern tends to be shared in the wider Business community thus making the challenge of ‘winning heart & minds’ that much greater as few of us have the time or the inclination to give up the familiar and learn the unfamiliar.

4-The Go-Live having been pushed out once, has to be pushed out again. And perhaps again. Then again. And when politics intervenes and the solution must Go-Live then most likely the solution will not be that which was envisaged. It falls short of delivering the desired outcomes: functionality, ease of use, and usefulness to those who use it.

5-Those who make the decisions promise that the deficiencies in the Go-Live solution will be addressed in phase 2.  This promise is rarely kept – at least not in the timescales that matter to the end users. It’s rather like sex: after climax, the passion/desire dwindles to nothing – the parties to the game are satiated.

Is There An Alternative – An Effective Approach To Dealing With The Challenge Of Integration?

Yes. What does this look like? I can only tell you what it looks like for me:

1-With regards to that which truly matters to me, I take full ownership – always, no exception- as in I design the play, I orchestrate the play, I facilitate the conversations/thinking that matters, I oversee to ensure that all are doing that which they are responsible for doing;

2-In the domains where I lack expertise, I bring in the experts as in those who have handled the challenge that I am facing and proven themselves. By “bring in the experts” I do not mean the organisation that claims this expertise – rookie mistake. I mean those individual human beings who embody the expertise either as individuals or as individuals that have worked together with one another as one team;

3-Put in place practices that allow me and those who are supporting me in the challenge of handling integration to keep in touch with individual teams/systems – on a weekly basis. Why, so that we know what is happening on the ground and pick up early if team A is doing something regards to system A that is going to mess with that which Team B is doing with system B.

4-Chair a regular Integration Workshop where ALL involved in building the IT solution attend – always, no exceptions. And, in this workshop I ensure that we actually work as opposed to merely talk. By this I mean, that we deal with that which impacts integration – this may just be issues, equally it could be design changes in one system that may impact other systems, or changes in business requirements that impact the design of the systems and the integrations.  And one output of the Integration Workshop might me that the integration blueprint published a long long time ago by the ‘architects’ has to be re-worked as it turns out to be flawed in one or more areas.

Does what I suggest sound like hard work?  Yes, it’s hard work. Which might explain why it is that so many go for the easier approach – the one I outlined at the start, the one prone to generating a failure.

I thank you for your listening and wish you the best. Until the next time….

 

DCX/CRM: Avoiding Failure (1)

Information technology centered programmes are prone to failure. This particularly true for the large/complex programmes – in the business world these kinds of programmes have the word “transformation” in them like business transformation, enterprise transformation, or digital customer experience transformation.

There are many factors that contribute to failure. Today, I wish to focus on the business requirements that represent the demand that the technology must deliver.

How It Used To Be

When I started out implementing IT systems as a management consultant, we had the consultants who were going to configure/build the system in direct (face to face) communication (typically workshops) with the business users (subject matter experts, end users):

Consultants <———————-> Business Users

This set-up was not perfect. Why?  Because the Consultants and the Business Users came from different worlds. In a sense they spoke different languages: the Consultants spoke the language of the application, the Business Users spoke the language of their industy-function-job.

A bridge between the two worlds tended to be built through a series of face to face workshops between the Consultants and the Business Users. And it was common for at least one member of the consulting team to have relevant domain experience: industry-function-process. Further, and importantly the Consultants and the Business Users shared culture as in came from the same culture so understanding was facilitated.

How It Is Nowadays

Nowadays it is common (in my experience) to have three sets of players:

Consultants  <————->  Business Analysts <—————–> Business Users

In this setup, it’s the Business Analysts who are responsible for:

  • ‘gathering’ the requirements from the Business Users and ‘packaging’ them up;
  • communicating them to the Consultants; and
  • responding to the questions posed by the Consultants.

Notice that there are 2 sets of communication: that between Business Analysts and Business Users; and that between Business Analysts and Consultants. So the challenge is for the Business Analysts to understand that which the Business Users need/want. And then pass on this understanding to the Consultants at the level needed for the Consultants to configure-build the application.

And notice this: the vital communication between the those who will configure/build the IT solution and those who will use it has been severed – it is no more.

Herein, lies a critical source of failure in CRM/DCX programmes that I have been involved in.  What is it that I am pointing at?

  • The Business Users no longer feel a sense of ownership over the business requirements nor the success/failure of the change programme;
  • The Business Analysts have become ‘Product Owners’ yet they do not see themselves as such nor operate as such;
  • The Business Analysts typically write up the requirements – create a document and email to the Consultants with the expectation that the Consultants will simply read the document and understand what is being asked of them;
  • The Consultants read the document and typically don’t understand the requirements and have plenty of questions for the Business Analysts;
  • The Business Analysts had thought their job done when the business requirements were documented and published so they tend not to be keen to meet with the Consultants;
  • When that meeting (often a Webex) occurs between the Consultants and the Business Analysts occurs it tends to become evident that the Business Analysts have only a superficial ‘understanding’ of the requirements.

This is where the matter becomes interesting. If we were living in an ideal world then the Consultants would insist that the Business Analysts supply the level of clarity/detail that is needed to configure-build the application. Ours is not an ideal world so events play out differently.  The Consultants can be young/inexperienced. The Consultants may come from a culture where confrontation is avoided and there is extreme deference/subservience to those with higher status.  The Consultants are under considerable pressure to get moving – to meet the deadlines that the client has set.

So the Consultants tend to move forward with whatever they are given.  They too have zero ownership of the business requirements.  They are handed an ‘order’ by the Business Analysts and so they fulfill that ‘order’. If this order does not make sense then it’s not their problem – as long as they can prove that they met the order.

If You Wish To Avoid Failure

If you wish to avoid failure as in wasted time/effort, wasted money, disappointed end users, and the business disruption that failed IT implementations bring then I advise you to do the following:

  1. Cut out the Business Analysts and restore the direct communication between the Consultants and Business Users;
  2. Only accept Consultants who between them are familiar with your industry (by having worked in it for several years), are familiar with the function – marketing, sales, service – that is being ‘automated’, are familiar with configuring-building the application you have chosen to implement in your  business;
  3. If your culture supports it then choose Consultants who are likely to bring ideas/experience and are likely to challenge you and your people as in challenge your thinking, your operational practices, the business requirements you have come up with;
  4. Make sure that you create the role of Product Owner, assign the best persons to these roles, and make these persons accountable for the quality of the ‘product’ created/delivered by the Consultants;
  5. Give up the notion that business requirements are merely lying around on the corporate carpet waiting to be gathered up – this is nonsense;
  6. Understand the business requirements are best co-constructed iteratively by the Consultants and your Business Users collaborating with one another through a series of face-to-face workshops;
  7. Make the Consultants and your Product Owners jointly responsible for the Business Requirements asking both to review and sign-off the documentation, and apply version control.

Enough for today. I thank you for your listening and wish you the best. Until the next time…