CMMI and ITIL

[Curly]

RJP, and Barbara et al

(Time's flown since the last postings: holidays, projects etc.)

Thanks for your comments around ITS-CMM. Although I'd found the site and skimmed the documents a number of months ago, I thought it worth taking a fresh look to see how my thinking might have changed (although I must admit that I haven't read through the detail of all 244 pages!).

Unless I'm missing something fundemental, I don't think it will answer my immediate concerns (nor, perhaps Barabara's - although I'm only guessing there.)

As Frank Niessink states, ITS-CMM is not ITIL and is not trying to be. And as we're an organisation embarking down the ITIL route, ITS-CMM won't be a replacement for ITIL.

The situation I face though is that as an organisation, we're also going down the CMMI route too (having started with CMM-SW). And the logical question that crops up is: "How do CMMI and ITIL fit together?"

My conclusions to date are that they don't fit together, although there is the occasional touch-point where some of the various activities in the organisation interface. For example, Requirements Development (CMMI) and Service Level Management (ITIL), Configuration Management (CMMI) and Configuration Management (ITIL) !!? etc.

Perhaps there isn't a simple mapping and we just need to share our thoughts as the two workstreams progress so that opportunities to tie things together are not missed. And maybe further down the road there is an opportunity to bring in ITS-CMM to assess ITSM process maturity. But for now, I think I'll leave it on the shelf and be content with BS15000/ISO20000.

However... if anyone does find the key to the riddle, I'd love to know.

[Guerino1]

Hi Curly,

I hate to jump in at the last second, here, but based on the way we use CMMI and ITIL they do go together very well.

CMMI is a process measurement solution that breaks the measurement of a process into 6 levels of maturity.

Almomst every discipline with ITIL is a Process. Therefore, you can use CMMI to measure how effective and mature your implementation of that process is.

0 = Incomplete
1 = Informed
2 = Managed
3 = Defined
4 = Quantitatively Managed
5 = Optimizing

Therefore, if you're implementing Incident Management, you can measure your implementation against these 6 steps to see how effective your work really is.

We use CMMI measuring as a way to open our clients' eyes about their process implementation. Many enterprises want to believe that they have great process solutions. Once you use the CMMI measurement criteria, most find that they're not past level 2; a few are at 3; a very small amount are at 4; and a very rare amount are at 5. Most organizations we walk into are at "0".

In our experience, this is the best use of CMMI against ITIL.

As far as the integration of each and every process, it's a huge undertaking. We offer a fully integrated tool that covers many different process/operational areas and, as far as we know, no one else has been able to achieve what we have. It is a complex task for us, who specialize in doing this every day. Imagine how complicated it is for an enterprise who does "not" specialize in doing this every day.

I will say this, though, your assessment about the processes not fitting together is not accurate. We've very successfully tied them all together. The problem is that ITIL is incomplete and has its greatest focus on Production operations, leaving out all other areas of the enterprise, such as sales, marketing, product development, testing, engineering, executive management & reporting, facilities management, real estate, project management & PMO, etc. If you want to integrate your processes together, you will have to look outside of ITIL at a bigger picture (which, in my opinion, is the correct thing to do... since your enterprise is bigger than just your IT organization).

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[Curly]

Thanks Frank,

Some useful insight and comment. I agree wholeheartedly that things must be viewed from an end-to-end business perspective, rather than simply from a technology provision point of view.

And yes, the maturity of a process is a measurable thing, so logic says that there is a fit. It's simple really.

But before you dive back in with a further comment...... yes, I realise that it's complex too!!

[stormeagle]

OK but what if the process I am interested in is software development. In particular, the development life cycle methodology.

If I want an assessment of the maturity level of this particular process, does it make sense to go with a CMMI assessment vendor? Is ITIL as strong on development processes as CMMI is?

From the rest of this thread, another reason for going to CMMI seems to be its prescriptive nature - i.e., if one doesn't just want an assessment of the current situation in the short term - but also wants a plan and recommendations for how to improve in the long term.

Comments? Does this sound correct? Or am I underestimating ITIL in this regard? Opinions would be welcome.

Thanks

[Guerino1]

Hello Stormeagle,

ITIL is actually very weak on development processes and this is one of the areas that causes extreme contention in IT organizations, since many IT Service Delivery and Service Management teams want to feel empowered over their environments and tend to forget that they exist to facilitate product development, support and maintenance. ITIL tends to focus more on Production support & operations processes than it does on Product Management & Development processes. Product Management is responsible for the whole picture, soup to nuts.

If you want an assessment of your development processes and their maturity then, yes, it does make sense to use a CMMI assessment solution. CMMI helps you understand what your current maturity level is and helps you understand what needs to be done to any one process to increase its maturity level. ITIL is "not" as strong on development processes. In fact, it is very weak on them.

The development process or lifecycle is actually very large, as it encompasses the Product's lifecycle, from inception through to decommission. This can be a many year window with many Releases and many Changes that are implemented.

- Think of the Product Lifecycle as a very large window.
- Think of a Release Lifecycle as a subwindow within the Product Lifecycle.
- Think of a Change Lifecycle as a subwindow within a given Release Lifecycle.

Within each of these lifecycles, a product development team will need to perform:

- Product Management functions
- Project Management functions
- Release Management functions
- Change Management functions
- Requirements Management functions
- Problem/Defect Management functions
- Risk Management functions
- Build Management functions
- Deployment/Distribution Management functions
- Document Management
- Incident Management
- etc.
- etc.
- etc.

The list of sub-processes that are all part of the master development lifecycle is very large. They all start from the development environment, move through multiple test environments, and ultimately move into targeted production environments. ITIL only really covers production (a huge limitation).

ITIL is only now starting to delve into Application Management, which still appears to be very vague and immature, as a whole.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[UKVIKING]

Guys

Check out ISACA www dot isaca dot org

They have done a lot of work regarding mapping of ITIL / CMMI / PRINCE2 / COBIT

Some are free others are not
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter