Beetil

How many times have we all heard that “the only constant is change”. Well, you’d better get used it. And you’d better get good at it. Because it’s here to stay.

Before we talk about how Beetil deals with change management, let’s take a step back and ask why we need change management in the first place.

Change can stem from a number of sources, including (but not limited to):

• enhancement of functionality
• performance enhancement
• bug fix (stemming from an incident or problem)
• new assets
• compliance obligations
• because developers think it’s sexy

How many of us in IT have seen developers/techies run off and do those changes that add no value whatsoever!

Change needs to be justified to make sure we’re spending money on the right things. Change needs to be managed to ensure we keep to budget and quality, and that negative business impact is kept to a minimum. Change needs to be streamlined to keep ahead of the game (or even up with the game!)

We like to think that changes can be split into three phases:

Planning
First up, lets work out why we are doing the change in the first place. Ultimately it boils down to this:

• what benefits will the change bring us?
• how much is the change going to cost us?

Sure, we have things like impact analysis, risk factors, the impact of not doing it, but at the end of the day it’s a trade off between the benefits that the change is going to being versus the cost to implement it. It’s the business that should decide what gets done, not the IT team.

Once the changes have all been “planned”, it’s worth meeting up and deciding which changes get approved. This is what ITIL calls a CAB (change advisory board) meeting. CAB members would normally consist of technical staff BUT ALSO business representatives as well.

Building
Once a change is approved, it’s important to keep tabs on how the build of the change is progressing. It’s amazing how often this doesn’t happen. But the idea is that you check in on regular intervals to make sure everything is going to plan.

Testing
Once a change is built, it’s likely wise that you get a few people to take a look at it, and make sure it’s of the appropriate standard. In other words, we test the change. We test, raise issues, get them fixed. Rinse and repeat until you’re happy that the change can be released into the wild.

Closure and Review
And finally, it’s always worth reviewing how the change went, what was done well, what was not done well, and taking note of what can be done better next time.

Let’s now take a look at Beetil Change Management, starting with the dashboard.

The Change Dashboard

The screenshot above tells it’s own story, but like the other Beetil dashboards, you can slice and dice changes by status, assignee, if it’s on your watchlist or not, and order and group by various due dates, priority, last active date, and created dates.

The change dashboard clearly shows at what stage each change is at, and even shows the status of testing as it is happening.

In the example above, we can see that the change has been approved, the build is in progress, and that testing is in progress, with one high, four medium, and one low issue raised.

Logging a Change

Logging a change is easy with Beetil.

Much like the other Beetil types (incidents, problems and releases) all changes have the following attributes.

• change owner
• change assignee
• priority
• due date

At any time, you can easily switch between the plan, build and test phases of change – simply by clicking the plan, build, test tabs.

Note that Beetil does not enforce a strict, rigid workflow, in the respect that you can start populating data in the other “phases” without having completed other phases. Every business operates differently, and we wish to respect that.

Plan

At the planning stage we recommend that at least the following gets completed:

General Description – this should be a high level description of the change. If you want to populate the full change details, please feel free to do so, or feel free to attach a document.

Reason/Justification – ask yourselves why you are doing this change and what benefit’s it is going to bring. We always ask the question, “If it was your money would you still do it?”.

Impact Analysis – it’s always worth having a good think through the impacts of what this change might have. This is not only from a technical point of view, but also from a people and process point of view.

Complexity and Risk – take time out to assess the complexity and/or risk level. Beetil lets you choose low/medium/high.

Effort – Beetil lets you populate the estimated number of hours required to complete the change.

At this stage, the change can be flicked back and forth between multiple parties until every is happy that there is enough information for the change to be submitted for approval.

Submitting for Approval

Submitting for approval is easy – click the big “submit for approval button”!

The change state will change to “pending approval” and all change approvers will be sent an email stating that this change has been submitted for approval (unless the submitter was a change approver themselves).

A change approver then views the change and can accept or decline:

If the change approver declines the change, they can enter a reason, and the change moves to a “declined” state.

If the change approver approves the change, the change moves to an “approved” state.

Build

The build tab in Beetil allows the change builders to collaborate and update interested parties.

Beetil allows for users to set a build due date, special build instructions, and to post progress updates.

Once the change build is completed, users can marked the change implementation as being completed. This automatically sends an email to the change owner, and sets the build state to “completed”.

Test

Beetil allows multiple parties to get involved in the testing phase of a Beetil.

Users can assign a series of reviewers, and let them know which area they need to test. Upon assigning a reviewer, the reviewer will receive an email.

The reviewers can then post “testing issues” against the change. Remember at this point that we are not creating incidents. The change is not yet in production, so therefore issues with the change aren’t really incidents.

To post an issue, simply click the “create” new issue button.

When posting a new issue, you can assign priority (high/medium/low), add a note, and upload attachments.

Once saved, users can then mark each as fixed, with testers having the ability to “OK” the fix.

The currently assigned change owner, and those on the watchlist, will get email notifications of these issue updates if users mark the “notify watchlist” checkbox when saving.

If you’re an assigned reviewer and have finished testing, you can mark the “I’m done testing” checkbox as complete.

Users can then mark the change as having it’s QA completed, and can mark as being “ready to be released”. The change is done!!!

Next step – release management!

Linkages

As you well know, Beetil loves linkages. Using the right hand panel, you can easily link up to other incidents, problems, releases and configuration items.

Through the easily linkages you can create, you’ll get a good idea as to how and why this change came about,.

As per any Beetil (our collective term for incident, problem, change and release) you can add yourself to the watchlist and receive email notifications when important stuff occurs. And every change to the change is logged with in an easily accessible and comprehensive audit trail.

You can also easily generate custom change reports and scheduled emails using our Beetil smart reporting functionality.

More links in our getting started with Beetil series

• Setting up and configuring services
• Incident Management
• Beetil and the Customer Portal
• Problem Management
• Release Management (coming soon)
• Configuration Management

Remember you can always access the help link in the top right hand corner of most pages! And you can always contact us on email at support@beetil.com, or catch us around the Campfire.

Tags: beetil, cab, Change Management, itil, ITSM

This entry was posted on Thursday, September 3rd, 2009 at 11:52 am and is filed under Change Management, Getting Started, Hints and Tips. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.