The Venn Diagram of Change and what it means?

I thought today I would write about something that may be so obvious to some that you wonder why I would bother. I do so because I feel there is still considerable confusion in the mind of recruiters.

I have been told a few times that I don't have enough "IT" on my CV to be considered for roles I could easily fulfill. This can be personally frustrating, but I also wonder if the mindsets behind these comments is not one of the contributors to the perceived failure rate of change projects.

I hope this is of use to at least some readers and that they can then use them to better assess requirements and candidates.

My starting point is the common view that a business is a combination of people, processes and systems. Of the terms systems is used in its more general sense rather than specifically to information technology. In the context of this post I will consider the terms systems to refer to the technology that supports business, be it email, trading systems, telephony and such.

The classic Venn diagram looks like this with the overlaps creating seven zones. This version is purely indicative and used to indicate the combinations and is no comment on the importance or volume of change in any individual segment.

So how does this help?

Let us first number the segments for easy reference

Picking off easiest to describe first, lets start with #7. This is pure technology and as shown in the diagram is not expecting their to be associated people or process change, at least not in the body of the business. Even a simple software upgrade or technology implmentation will require some people and process changes within the functions that support it, but I would suggest that if the change has little or no impact on the day-to-day work of users and management then it fits into #7. In my opinion this is clearly the domain of the "technical" project manager. The methodologies to analyse the requirements and deliver a solution are usually pretty well known and transferrable from project to project.

This is the domain of IT and includes the likes of IT networks, data centres, telephony/communications including services like internet, email, etc..

# 1 is the area of "pure" people change. This is a little harder to define, but includes changes to employment contracts, remuneration and can include more elusive topics such as cultural change. Again these may touch need some changes to the interactions between management and staff and use some technology to deliver, but if the changes have little or no impact on the daily execution of business by the core of the business then it falls into this segment. In many instances this is seen as the domain of the HR change specialist, someone who understands the daily operation of HR functions and the legal and contractual aspects. I am sure I have undervalued this segment, but mean no offence to anyone. I am just trying to illustrate this area of work.

One area that I would personally dispute is that of cultural change. It is often launched and "owned" in this space, but should, in my opinion sit in zones #2 and #5, but we will come back to that.

#3 is "pure" process change. It suggests that the same people will use the same tools/technology to do things differently/better. To my mind this can only be incremental (and relatively small) change as anything else will require people and/or technology to change. There are tools such as 6Sigma and Lean that help in the analysis of the opportunities here, but the danger is to underestimate the implementation of desired changes.

In truth many people find it simpler to think of change in just these three arenas. Indeed many organisations look to place change under the management of technology, who rarely have the empathy or experience to deliver the other two. This is often the source of dissatisfactoin and turf wars between executives, leading to "Black Ops" change initiatives run outside the normal governance frameworks. Often these only come to light when they hit trouble or need extra or already committed resources.

In practice in my expereince most change sits with zones #2, #5 and #6 with transformational change firmly in #5. These changes normally need the same or new people, working in different ways (maybe under different conditions) with new or enhanced tools to deliver business improved ways.

I struggle to think of an example that would sit in #4, but maybe someone can suggest suitable candidates.

Operational Change as used in my world of Financial services is usually placed in #6 as it is usually looking to use the same human resources in broadly the same way, but with different processes and possibly with new tools to deliver a business requirement. The issue here is that it is often under different management from the larger technology and transformational undertakings, often leading to overlap and conflict.

Personally I have operated in zones #2, #5, #6 and #7, helping to guide undertakings in #1 and #3 at different times. The place I enjoy most and believe where I add most value is in the more complex and, at times, transformational area of #5. These are the places where ambiguity is usually higher and the recipient environment prone to external change.

I find this framework is useful in assessing opportunities that present themselves and how well I "fit".

It also illustrates that project or programme manager needs more than "technology" skills when they step into endeavours that have significant people or process change. I would love a £1 for every time I have seen a technical project manager the job of implementing a new or upgraded trading system and run up on the rocks of people and process. Please do not think I lack respect for technical project managers, because I don't. They do certain changes better than I could and enjoy them more than I would, but I suspect they would say the same about me

I wonder if this makes sense or is use to others? Is it something we can develop or explain further?