The Interplay of People, Process and Technology

Before I get into the article, Google Analytics is telling me I am not getting as many hits as I used to.

While this may simply be a seasonal thing, I am keen to keep my audience. Therefore, if there is a specific type of article you would like to see or, if you feel I have been dropping the ball of late, let me know. Generally I write one of three types of articles:

• Codeless tricks for Dynamics CRM
• Competitive analysis (often directed at salesforce)
• Thought leadership on CRM in general

Today’s article is in the ‘thought leadership’ camp.

The Processing of Information

There is a reliable model in IT circles when it comes to implementing software into a business which is the model of People, Process and Technology. The idea is that if you are processing information e.g. converting an order into a delivery or going from a lead into a sale, inevitably these three elements will be involved.

Overall it is a pretty good model in that it is understood that all three elements have to be considered for an IT project not to fail. To put it generally:

• People: who is involved in processing the information?
• Technology: what systems are being employed in processing the information?
• Process: How is the information transformed/transferred?

What is often overlooked, and the purpose of today’s blog, is the consideration of their interplay.

Scenario One: The Dreaded Timesheet

A few employers ago, my boss asked me to look at how we could improve the internal process of lodging timesheets. The consultants complained that the process involved multiple handling of emails from the resource manager (the person that assigned them to projects), their calendar and the ERP system where they eventually logged their time. All three elements held basically the same information but none of them were linked, except through the keyboard of the consultant.

The resource manager complained because his calendar, showing all consultants, was not linked to the CRM or ERP system so he had to monitor when deals closed and then assign resources manually. The general manager complained because the numbers in the ERP system of closed deals never matched the resource manager’s calendar of completed work and the CRM system of future deals never matched the resource manager’s calendar of upcoming and assigned work. It was a mess.

As an aside, for those of you not in the consulting game, this situation is nothing new and is pretty much par for the course in most consulting businesses.

I began reviewing the situation and quickly concluded that Dynamics CRM could be used to resolve the situation.

• When a sales opportunity is closed in Dynamics CRM, a workflow could automatically create a project task for the resource manager
• The resource manager could assign this to a consultant and it would automatically appear in their Outlook calendar
• When the work was completed, the consultant could mark the activity as completed and this would then feed into the ERP system via an integration component
• Everything could be monitored through CRM’s Service Calendar or through SRS reports

An elegant solution and entirely practical. All the resource manager would ever have to do would be to assign jobs to consultants and all a consultant would have to do is complete the work and mark it as such in Outlook. The systems would take care of the rest.

I was so excited about the possibilities, I mentioned the idea to my boss’ boss, the general manager. To my surprise he was lukewarm on the idea of using CRM as the ‘glue’. His response was “let us look at the process first and then we can look at the technology”. Unfortunately, despite lovely process diagrams being created, nothing changed and the business continued to drown in  poor information and overly manual processes. Because so much time was being spent on the manual processes generating inadequate information, there was never any time to improve the situation and, as far as I know, the situation remains the same to this day.

Scenario Two: The Dream System

Another time, the company I worked for was asked to deliver a system, using Dynamics CRM, which met the specifications gathered by a third-party system-agnostic business analyst. We were told it was the system the client’s staff had designed and it was vital to give them what they wanted to guarantee user adoption, no further workshops required. Unfortunately, the consultant involved (who will remain nameless to protect the inexperienced) accepted the challenge and the project horribly failed with budget blowouts and compromised solutions. No-one got what they wanted.

Scenario Three: Consolidating on the One Platform

The final situation was a conversation I had with a client where they loved Dynamics CRM so much they wanted to do everything through it, including their financials and inventory management. Fortunately, I managed to convince them otherwise but it is an excellent example of when you have the CRM hammer how everything looks like a nail. For the client, it did not matter that CRM has no concept of a general ledger or that the accounting department would have to learn a completely new system which would deliver a fraction of the functionality of the incumbent ERP software.

Why Considering Elements In Isolation Never Works

The problem in each of these scenarios is that one of the three elements was being considered without regard to the others (process, people and technology, respectively). This happens a lot and is often why CRM projects fail. Use your favourite search engine to find lists of reasons why CRM projects fail and you will see lists talking about how one or more of the three elements are being ignored.

If you focus on the technology and process but do not ensure the people are equipped and motivated to use the system (through training) user adoption will be compromised.

If you focus on process and people but ignore the technology, the misalignment will lead to expensive development to make the system ‘fit’ blowing out budgets with minimal gain.

If you focus on the people and technology but ignore the process, you risk automating and magnifying inefficiencies or failing to deliver what the business actually needs.

Getting in the Zone

A rough analogy can be drawn to the idea of the head, heart and hands and the idea of being ‘in the zone’; that state of mind, similar to Csikszentmihalyi’s ‘flow’ where productivity is achieved effortlessly.

Hugo Kehr researched this area and came up with the ‘Compensatory Model’. The theory goes that if the head (rationale for an action), heart (personal motivation to perform the action) and hands (perceived ability to perform the action) are aligned, the individual will achieve effortlessly. If they are not, without intervention, achievement will be difficult or impossible. A classic example is a smoker who knows quitting is good for his health (head) and he has the ability to stop (hands) but his heart is not in it. To achieve success will require willpower; it will not be effortless.

In our case, we can consider the process as the head (the logical approach to processing the information), technology as the hands (the tools to enable the processing) and the people as the heart (those performing the action who must be personally motivated).

Reviewing the misalignment through this filter:

If the people are unmotivated e.g. they perceive CRM as unhelpful and merely a ‘big brother’ system, they will be able to achieve the outcome but there will again be frustration and the requirement for willpower.

If the technology is inadequate but the people and the business both agree the outcome is necessary, creativity and problem solving will be used to ‘work around’ the systems e.g. Excel and Access systems will be created.

If there is no process, people with the right resources can achieve the outcome, but there will be frustration and willpower (volitional regulation to use Kehr’s terminology) will have to be employed.

Conclusions

The idea of considering the elements of people, process and technology when implementing an IT solution to help with a business process is a good start but it is not everything. Changing one of the three elements inevitably affects the other two and, often, in subtle ways. Therefore, it is also necessary to consider how all three are linked in the ‘as is’ process, how this will change in the ‘to be’ process and what steps will be necessary to transform from one to the other. Being rigid with one element and expecting the others to fall into place is a recipe for disaster.

The closer all three are aligned, the less frustration there will be with the system and the more consistent the process: business nirvana.