Project Management, Change Management and Release Management

Change Management

It seems that most people view ITIL Change Management as the recording and approval of “operational” work being done in the production environment.

Typically what I’ve read, heard and discussed with people is some concept of putting in a “RFC” a few weeks, maybe a few days, before the implementation of the change. The Schedule of Change then becomes the go to resource to see what is being “released” in the environment when.

This (what I may call “traditional”) view of Change Management is entirely too limited.

First it completely crushes Release Management to the point where a lot of organizations don’t do this, don’t do it well, and really don’t understand how Release works with and/or is different from Change Management.

Second, it creates limited interaction with Project Management, Service Design functions, or even Service Strategy functions. If you are just considering the risk of a change 8 days before implementation, when the majority of the money, time, and other resources have already been spent…you are not doing much of a “risk evaluation.”

Project Management

All projects are essentially the organization/management of resources with the purpose of implementing change(s). There are of course lots of work that goes into doing that and doing that well. Scope statements, stakeholder communications, requirements gathering, budgeting, coordination across multiple “line” teams and the utilization of various IT processes.

Some things to consider when thinking about Project Management and the (real) role of Change Management…

  • How do we ‘prioritize’ this project vs other organizational efforts?
    • Not just priority vs other proposed work but priority vs current efforts?
  • How do we assess the risk of the project from multiple facets (before work is actually started)
    • Such as “Capacity”, “Availability”, Business Continuity”, “Portfolio/Catalog”,  or “Security”
  • How are we determining, documenting, and then managing what “gateways” this effort must pass through in order to progress from Design to Operations?
    • Not every “change” needs a detailed design review or a new pricing model – how do you determine which does and how do you ensure they go through those checkpoints?
  • How do we document and manage any changes to scope or to risk to the ‘change’ when it is in Design or Transition?

If you are not doing a RFC until a week or so you are moving to Production – you can’t possibly be capturing and managing this type of information using Change Management – so then how are you doing it….or are you doing it at all?

Release Management

The often forgotten and neglected process. Sad and lonely. Do you have a Release Management Board? How does it work with the CAB? Who actually sets the schedule for ‘release’?

In most places it seems that the Schedule of Change (to include date/time) is set by the Change Advisory Board. In doing so, I believe, you force Release to march to that tune and so curtail some of the power/authority a Release Management Process can (should) have.

The Release Management process should dictate the actual schedule of the implementation. The CAB should only state the change is “authorized” – the actual date/time, type of release, resources used in the release, artifacts required are determined by Release not by Change. Change is the ‘macro’ and Release is the ‘micro’.

How they can work together…

A need or idea for a change starts the Change Management process. Some of these will also be Projects, some will not.

Change Management can start months, maybe a year, prior to the actual implementation date. Change Management may review an RFC multiple times.

Consider the following:

  1. Need/Idea
    1. These are: Customer/Business Requirement, Customer/Business Request, Service Improvement, Service Correction
    2. Our new idea is “New Service Desk” tool.  Since it is coming from IT, it is most likely a “Service Improvement” effort.
  2. A high level business case should be put together and then you have your first CAB review
    1. Define problem, define scope/urgency, define benefits/risks, define estimate of resources needed
  3. CAB provides approval to move towards RFP and proof of concept
  4. The ‘project team’ then develops RFP and/or POC, meets with vendors, obtains testing equipment/software, performs POC, reviews POC…
  5. Team updates RFC with POC/RFP information – updates Business Case as needed. Goes back to the CAB. The CAB can then approve/deny continuation of the effort.
  6. At this stage the ‘project team’ must create Design plan, what artifacts (Capacity Plan, Security Plan…etc) will be required/updated , schedule of significant milestones (such as: requirements signoff by stakeholders, beginning of testing) and resource allocation.
  7. The ‘project’ goes back to the CAB – the Design plan is reviewed and denied (maybe they didn’t include the Business Continuity Plan, or maybe the planning seems to include things beyond initial scope) or approved
  8. The ‘project’ moves to development/design – any deviation of dates to significant milestones require an update to the RFC – which requires review by the CAB.
    1. Why was testing pushed back 1 month?
    2. What other efforts will that impact? Are resources still available? How does that impact future ‘change’ requests?
    3. Normal progression through milestones just has updates to RFC (change in sub-status could be helpful here for reporting purposes)
  9. During Design/Development – Release Management starts to become involved. They are the gate keeper to some significant milestones (such as Acceptance of Testing, Implementation Plan Acceptance) – they approve the RFC to migrate through these ‘sub-status’
  10. As the effort moves through testing but prior to implementation – the CAB reviews the change again and then provides “approval” for implementation. The schedule is set by Release Management.
  11. Release Management provides approval for the Implementation Plan and sets the date/time for the release.
  12. After implementation Release Management reviews the “release” and provides input to Change Management to assess overall success/failure of Change.
    1. The ‘release’ component can be successful while the overall change effort can be viewed as less than successful due to schedule/resource overruns, or failure to adequately address customer/business needs. This separates the assessment of the Change from the assessment of the Release.

But let’s just say that you are not doing something that large. You are just doing a  a upgrade to an existing application or maybe you are just adding capacity to a service by putting in more “servers” – Do you have to go through ALL of this stuff?

The answer is a bit of yes and no. You still need to put in the initial RFC. You list it as “Service Correction” or “Service Improvement” and you still need some high level business case (this is your justification or reason for doing the work). It will get approved and you don’t need a RFP or maybe even a POC so you move right to documenting your Develop/Design plan and identifying which documents you will create/update. This is then approved (let’s say your work does not impact Availability, or Security – so you just say you won’t be updating or creating those documents). It is then approved to move to the next stage – which then you will start to engage with Release Management. You have to progress through their stages and you can then get to implementation in production.

Of course you can always create “standard changes” which can speed this process up by “pre-approving” many steps but that of course means you’ve at least gone through this exercise at least once.

Recap…

Project Management is to manage discreet efforts. The may be large in scope but they have a defined scope. They may even have PM Boards which discuss project management practices, or certain artifacts related to Project Management (status reports). Project Management is more about “who” and “how” is something is getting done.

Change Management is to manage ALL change efforts to the enterprise. Big or small. Project or Operational. They must all be recorded, assessed, and balanced against all other requests and business needs. We cannot allow ‘rogue’ work on change efforts without governance. Change Management is more about “why” and “what” is getting done.

Release Management is to manage the transition from the ‘test environment’ to the ‘production environment.’ It is concerned with the details of those plans. Release Management is about “how” and “when” something is getting done.

The “where” is defined in your policies. I’d recommend that this type of structure apply to production as well as applying Release Management controls over your test environment.

What are your thoughts?

Advertisements

Lead Users, Agile Development, and ITSM

Lead Users

You know the main point of this blog is really so I don’t forget things I come across or ideas I have. I am sure, that if I didn’t right this one down, I’d forget about it and then “rediscover” it about a year from now.

Anyway, what is a Lead User? And how did I find out about it?

I did some reading on Professor Von Hippel’s site (and of course Wikipedia).

The ‘lead user’ is the person who is using your product/service in a way that the majority of people are not yet. They are trying to solve a problem that the rest of the world doesn’t know it has, yet.

The idea is that you can get innovation breakthrough’s by working with ‘lead users’ of your products/services and see what problems they are facing and how they are working on solving them. You can then perhaps also work with related (but different) area’s to see how they are working to solve similar problems.

If all goes well, you will be ahead of the competition and just as importantly have a better product/service.

Lead Users and ITSM

Are there ‘lead users’ of ITSM? Are there people in  your organization that are trying to use your processes (or technologies built to support those processes) to solve problems that you (and the rest of the organization) are not really aware of or paying attention to…yet?

I know, in my last place, I heard of a Project Manager wanting to link a Change Request to a Project. I didn’t hear this from 10 or 20 PM’s or really from anyone working on projects or anyone in leadership – just the one PM.

But what I did was take that idea to the development team and asked them to include in the Change Request a place where you can put in the Project ID Number.

Boom! Now, you can track changes associated to projects. A few weeks after that, at lunch with the CIO, I bring it up to her that she can now have a report that would link Projects to Change Requests. Instantly she saw value in that and instantly it became a need for the majority.

Lesson: Find “lead users” in your organization. Listen to them. Bring their ideas forward. See how you can test them or, put them in practice quickly without spending too much time trying to make it ‘perfect’.

Agile Development

I’m not going to spend anytime explaining this concept. I’m not a SCRUM Master (what a title…) but I do believe Agile is better than classic/traditional/waterfall.

Now, previously, I described the simple way in which you can track projects to change requests. Is this the ‘best’ way to do it?

No. Clearly not. Anyone can forget to associate the two. They can “fat finger” the number. It isn’t the best method. Is it better than nothing. Yes.

And with an Agile approach to process you can start and in the next ‘release’ (maybe 30, 45 days, whatever) you update it. Maybe it wasn’t a mandatory field at first now it is. Maybe even better, there is a question “Is this Change Request related to a Project?” – if they say “Yes” then you make it mandatory. Oh, even better, why not ask the question, make it mandatory, but it is a drop down pulled from the Project Management technology?

You can make it better and better with iterations.