IT System and IT Service

I started my IT career in the mid 90s. There were many software houses developing business applications for all industries.

By then, the term "IT service" is uncommon, we used to use the term "IT system". The word of "system" mainly focuses on IT components, hardware or software. Whereas, the term "IT service" is so common now, "service" emphasizes the value to the organization.

By then, when I was a software developer, even I became the lead of IT project team, I only knew Software Development Life Cycle (SDLC). With the introduction of IT Infrastructure Library (ITIL), we get to know Service Management Life Cycle (SMLC).

It shows that our IT industry has moved up the value chain. I believe, there are so many kinds of business applications in the market, there are hardly to re-invenet something new. Hence, the IT companies have to focus on its services.

Currently, ITIL has come to version 3. Put it into a simple way, ITIL is a set of recommendations based on the decades long experiences of its many contributors. This library consists of 6 books, the first book is an introduction to ht entire area of IT service management, and the other 5 books give the core of the best-practice recoomendations.

The good thing is, we don't have to go through the 6 books to become a ITIL practitioner. There are many ITIL course out there to certify you within a week.

Project management Vs Release Management

I still remembered the time I just took up the role of release manager, the project team members always gave me a confused look. This was not their fault, they didn’t know why I was there. They already had their project manager breath down to their necks, and now came a release manager?

I know, this is one of the frequently asked questions from the IT people nowadays, what is the different between project manager and release manager? Or, I should put it this way – what is the difference between project management and release management.

Project managers practice PMP, release manager practice ITIL, period. Simple, huh? Let me give you a longer answer as below:

Project management is focused on the delivery of a project within a pre-defined scope, resource, budget and timeline. A project may result in a release.

Release management is the process to govern IT projects go from the development and test environment to the live environment. In short, release management is to manage the release of new/changed services. The changes can be software, hardware or both.

Project may happen once, but release can happen many times. For example, a project may have a number of releases. Each release can be a separate project. No doubt, project management and release management are very closely related.

Release management can help project management by defining the guidelines that each release must adhere to with regard to documentation, testing, acceptance, implementation, source codes check-in and etc.

A project by its nature will come to an end, but the releases will continue on in the production environment as a service or component of a service. Hence, release management tells you the routes to go from development to production.

Some IT management guru said that Release management takes a holistic approach to release, I strongly agree with it though it won't make me a holy man. Release management defines the procedures for every activity. The activities can be user training, production support briefing, communication to business users, post implementation support. The objective is to ensure a consistent set of standards are applicable to all releases. Also, by defining a standard set of procedures, release management helps to build “quality” into the process.

P/S: PMP or ITIL practioners can give your opinion.

When to Release?

It is often a question to release manager or product manager -- when is the new application or new changes to be released to production. Some managers believe in “release early” and some believe in “release often”, and not to our surprises, many managers like to “release early and release often”. No matter what your belief is, never ever release an application/change that is NOT STABLE.

I was a release manager for a BPO (Business Process Outsourcing) of a UK based commercial bank, we had 4 major releases in a year. We conducted reviews and assessment and extensive testing on the application/changes. We had meeting with the project teams and service managers about whether to release the new changes.

Reasons to Release

1. The changes were tested and stable.
2. The release of the changes had been scheduled. If we missed the release date, we would miss the release window and re-scheduled was required. Individual release could be arranged but was not encouraged.
3. Regulatory Compliance.
4. Real pressures from business users.

Reasons not to Release

1. The changes were not meeting the requirements.
2. The changes were potential harms to production.
3. User Acceptance Test was not signed off.
4. Disagreement from CAB (Change Advisory Board).
   

There were many struggling internally, with everyone has their own stake. However, we had to face the reality, the real pressures were come from business users and the regulators, we decided to release the changes. The most important lesson to me was that we couldn’t set the priority to the changes, the priority was often set by the business users.

I kept a simple checklist when came to production readiness assessments:

1. Are there any major bugs in the changes?
2. Has all stakeholders made aware of the new changes?
3. What is the impact if the changes are not release?
4. What is the impact if the changes are delayed?
5. Will the new changes be impacting other modules?

I couldn’t answer the assessment by myself. Instead, I worked with other teams to complete all the necessary assessments.