DCX/CRM: Avoiding Failure (1)

0
31 views

Share on LinkedIn

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…

LEAVE A REPLY

Please enter your comment!
Please enter your name here