Model of Change

Something different today: some ITSM philosophy for your consideration... and debate.

A thread of discussion on this blog makes it clear that there are differing perspectives of Change. In order to further muddy the waters, here is the IT Skeptic's Change Model which attempts to draw those perspectives together.

[Updated: added point 3]

  1. Change has four major views: Organisation, Project, Development and Operations. But these are only views: the underlying change entities exist as a single set. Note also that these are not IT terms. That is, IT Operations is a subset of Operations, IT Development is a subset of Development. Other groups to have a development area include Marketing and R&D. But we will talk mostly from an IT point of view, because IT is the thought leader in this area, and because it is what I know.
  2. Changes are managed by view. Process and ownership of the process occurs at the view. Overall ownership of the change is trickier: there could be a Chief Change Officer that owns all, or ownership could be passed like a baton as a change moves through processes.
    Personally I favour an über-manager (“manager” meaning owner, roles, processes and tools) that tracks all changes, even if a sub-manager manages the details of one view. So there is a central portfolio of all change, but the detail of the change management is handled below it in
    • demand management (user and management requests for change)
    • project portfolio management (holistic, strategic deployment of people and money across projects)
    • project management (tactical control and forecasting of people, tasks and timelines across inter-related projects)
    • software development lifecycle or SDLC (versioning, changes, defects, builds and staging)
    • service desk (changes generated by incident and problem management, and “casual” requests for change)
    • configuration management (tracking what is happening to the production environment; understanding the implications by relating the change to the impacted objects and services)
    • operational change management (controlling the implementation and deployment of changes into production environments)

    E.g. The central process shows a status of "with development", while all the techie details are managed in IT Development’s geeky process and tool, with occasional updates flowing back to the centre as the change passes development milestones, until the change is passed back from Development. Then some other process gets control of the change with occasional updates flowing back to the central controller (where Development can check on progress).
    Others will prefer a federated model - it seems to be in vogue right now (sunrise, sunset...).

  3. [Updated] A change goes through its lifecycle from an idea to a proposal to a project to a production system, and as it does so it appears and disappears from views as it moves in and out of their scope of interest.
  4. In theory a change may appear in any one view and not appear in any other. For example:
    • a business change may never make it to the project stage
    • many IT operational changes will never appear on any other view
  5. But most changes will flow through multiple views:
    • An operational change requires business process change
    • A new product needs changes to operational systems, eg. Warehousing
    • A business-initiated change initiates a project which requires new software developed which has to be implemented ...
  6. And many changes need to at least appear on all other views so that they can be examined for impact:
    • Operations departments need to have advance warning of proposed changes entering demand management
    • one function of the CAB (ITIL Change Advisory Board) is to facilitate this for the Business view, so they are aware of upcoming production changes.
  7. An underlying tool might be the repository and engine for one combination of views, and another tool for some other combination. There is not a one-to-one mapping between tools and views. For example
    • an IT Service Desk will almost always manage IT Operational change and might manage some or all Operational change in general and some of IT Development change
    • SDLC is a specialist function (think bug tracking, copybook management, builds...) that usually has its own tool
    • A Change Manager would use CMDB to check change impact, and an operations technician would update the CMDB or notify the Configuration Manager after they have made the change so that the mappings to services and other logical entities can be updated.
    • the business executive will want to manage project portfolio in yet another specialised tool which usually integrates with the project management tool(s)
    • try telling contract project managers to use a tool other than MS-Project to manage project changes.

    I see lots of problems when people try to force a square tool into a round view. People have seriously proposed JIRA as a problem management tool in my hearing. Recently I saw CVS+Bugzilla being promoted as an IT Operational change manager. Wrong. There is an overlap (release, software distribution, staging...), no more.

    More subtle is the fact that tools evolve from one view to encompass more. I think we need to be careful to ensure they actually fit the requirement at hand when applied to other views. E.g. powerful toolsets that come from an IT Development background for modelling, RAD and CASE are now proposed as a more general repository: a CMDB. Not wrong, but not necessarily the best solution unless the environment is Development-heavy.

    People come from diverse backgrounds too, and they bring with them preferences and mindsets that also skew planning and designs. Personally I think a CMDB needs an IT Operational bias, but that is my own background showing. People from project or business experiences might suggest another toolset as CMDB, perhaps a financial asset tool that has grown up.
    When selecting tools, each situation must be assessed to decide which aspect is most important, what skew is appropriate.

  8. How the views relate hierarchically is an organisational decision. I often draw them as Venn subsets, i.e. nested circles: Development within Operations (yes if I ruled the world Operations would manage Development change) within Project within Business. But I think there are several other valid ways of arranging them:
    • four peers under an umbrella view
    • business managing the other three
    • Development and Operations within Project within Business
    • "group hug": mutually cooperating peers (yeah, right)

In the IT change world, ITIL has a lot to say. Most of the time, ITIL Change Management (and Release and Configuration Management) is about service desk and operational (production) change management. Unfortunately ITIL has aspirations above its station: at times the ITIL books try to expand “Change” into demand, project, SDLC and even portfolio management.

A lot of debate stems from definition of terms or scope. If we have a clear mental model of all the aspects of change (the IT Skeptic once mapped about twelve, not the four here), then we can be clear what we mean when we talk about that much-debated word "Change".


An important aspect of change is time

I think the perspective of time is missing. It is not mentioned. Whatever, the view (or opinion) of change it is always about a moment in time and a duration.

Excellent idea

Does point 3 above address this?

Yes, but what about the problems.

Most changes are a source of problems mainly because I think the change lifecycle described is like throwing dead cats over the wall. Maybe it is because the lifecycle is not fully described with all the relevant checkpoints for validation and due diligence?

On a seperate point, a major source of changes is failure or degradation in production. These dead cats come flying back over the wall with PostIT notes attached, which results in new change requests. I don't see these types of changes being described?

Differing views of change

Hi skep,

Agree with your summary that a) change can be split into the sections you idenitfy and also b) that "change management" may viewed as how the different perspectives are reconciled. Because many get the ITIL religion they fail to realise that there is a bigger world than service management with project and development activities requiring their own type of controls compared to the generic change to production systems.

Without going over the same ground about the CMDB concept, your views may it plainly obvious that the CMDB cannot deliver all the knowledge or information required to support, or communicate all types of change. It's enough of a monster without trying to encompass project and development activities (aka ITIL V3).

My experience of implementing "cmdb like" solutions is that the ones that work for production change control are where you map dependencies between services and their underlying components. Asset control is pretty irrelevant for CAB decision making. Release controls are much the same, its the project teams responsibility to identify risks and impacts. So if you want to implement a reasonable effective change management process for the production environment, and you want to make it easy for all to submit changes, log incidents, report on root causes - then focus the CMDB on service mapping and leave everything else out. Alternatively, we have would to map the organisation, the business processes, the roles/responsibilities, the assets as well as the IT services (which some try to do!) By keeping a tight focus, service management teams can deliver the coordination and controls expected. Shame that this is lost in mass of ITIL V3 messages

Maybe a better view of what change management is, makes it easier to understand what supporting knowledge systems will actually help.


Syndicate content