Framing the Problem…

There are a lot of frameworks out there: ITIL, CMMi, PMP, TOGAF, Six Sigma, and a couple dozen more.   Do any of them work?  Do they add more value than the effort to implement them?  I have seen companies adopt them thinking they are a panacea to solve their organizational problems, and other companies avoid them as if they would rather catch the Bubonic Plague than implement a framework.  Today, I am going to take a break from my ever-growing series on organizational structures and talk about the benefits of a framework.

“The Benefits of a Framework” is a good starting place because it really does not matter which framework you try.  Nor does it truly matter how “complete” the implementation is.  Purity is not beneficial in this case.  If you are starting from zero, and go about it with the right attitude, ITIL will be just as transformative to the organization as Six Sigma – and they could not be more different.  Which one will be easier to implement?  Which one will give you more value?  The framework cannot answer that question.  Only the implementing champion can.

This means that the critical key to the success of implementing a framework and the majority of the benefit the organization will achieve lies in the decision of who will champion the effort.  It is that person’s attitude, vision, and ability to rally support around that vision which determines success.  It is ironic that the principle of the framework (every one of them) is to move away from reliance on the organizational hero, yet the implementation depends exactly on that hero.

So what are you looking for in that champion?  First, and foremost, their conviction that the framework will solve organizational challenges and bring business value.  If they do not believe, they cannot inspire.  If they’re not focused on business value as the end-game, they will not achieve it.  If they cannot see the full scope of organizational challenges in the harsh light of day, including in their back yard, they have no ability to apply the tools to solve the problems. 

Another key characteristic is that the champion must plan their own obsolescence.  The framework is not successful if it requires personal charisma to maintain.  The hero is not only no longer needed, but an actual hindrance to eventual success.  The champion must be able to get follower momentum until it is capable of sustaining itself, then get out of the way.  It is about the organization’s success, not the champion’s personal resume or fiefdom.

Finally, the champion needs a healthy dose of realism.  What will the framework solve, and what can it not solve?  In reality, it solves nothing in the present.  It is only the way it was implemented that solves or does not solve a problem – did the implementer aim to solve the right business problem?

So if the framework doesn’t matter, and it is only the alignment of the implementation to the challenges of the business that determines the resulting value, what good is a framework anyway?  Nothing – now.  But it provides a common language with which the future can be described.  Whichever framework you choose to solve any given problem gives you a common taxonomy to ground the discussion with vendors, with potential candidates for key positions, orienting new hires and guiding the thought process of the strategic thinkers in the organization.

So, it does not matter which framework you adopt, only that you have one.  So what if it is only adopted within two groups of your organization – it provides a communication structure and it solved business problems.  This group believes in CMMi and that one believes in Lean?  Great!  Neither one solves all problems, and each has drawbacks that detract from their value which can be solved by the other.  So get the two talking to each other and see what results.  It’ll be interesting, and if it is approached with the right mindset, the offspring of that union will generate business value.  The only problem is that no one will know what to call it.

So: What are the different frameworks and where do they fit in?

Information Technology Infrastructure Library (ITIL) focuses on – in a phrase – service availability.  It defines several disciplines and organizational structures, but in the end every one of them is aimed at preventing a service disruption or restoring a service to operations as quickly as possible.  It provides one possible map for how to structure an IT Operations group and processes for managing change.  The change management is best suited to a Waterfall SDLC, but can be adapted to Agile.  The effort is typically led from the Operations side of the house, in either Risk Management or Production Operations.

Capability Maturity Model, Integrated (CMMi) focuses on process in the hope that if you get the processes right, the end result cannot help but be right.  Any failure in the result, by definition, was caused by a defect in the process.  CMMi is frequently and incorrectly thought to be the answer to software quality issues.  It is usually led from the Change Management group.

Project Management Professional (PMP) is one of the best certifications I’ve seen.  In order to achieve the certification, the candidate must have lead projects throughout the full lifecycle for at least 5 years – and that claim is randomly audited.  Most other certifications test your ability to absorb and repeat their taxonomy.  While PMP speaks in terms of process, with inputs and outputs, it truly centers on communication.  Leadership typically centers in the obvious portfolio/project management organization.

The Open Group Architecture Framework (TOGAF) derives from earlier architectural frameworks, but from what I can see it appears to be a re-cast of PMP with an architectural point of view.  While PMP focuses on communication, TOGAF centers on the artifacts.  The obvious group for this is Enterprise Architecture.

Six Sigma is all about statistical process control.  It is frequently disregarded in the IT realm because it is strongly linked conceptually to manufacturing, and of course manufacturing software is completely unlike manufacturing anything else…  The real problem with using Six Sigma in IT is that there must be sufficient statistical data points to generate a meaningful sigma.  I am lining up a guest writer to discuss how some Lean concepts such as Kanban can apply to the software development process.  This is often led by outside business units or by the Process Improvement committee in the Governance arena.

Understand that any summarization of these extensive frameworks that boils down to 3 or 4 sentences is generalized almost to the point of uselessness, but it helps to understand the “problem space” that each is intended to solve.  I do not recommend implementing any of them in their entirety, but cherry-picking the best of breed processes to solve targeted operational problems.  Has anyone experienced something that shows otherwise?  Any disagreement with the overly simplistic summaries here?  Please comment so we can all chime in.

2 thoughts on “Framing the Problem…

  1. Hi Glen, I’ve used several of the frameworks above in anger and they do bring benefit to the company/agency from my experience. We implemented ITIL/ITSM V2 at a large Commonwealth agency with some excellent results around Configuration Management, Change Management and Release Management. I was also part of a team that performed a CMMI analysis on a large project in the Defence space which proved some very interesting results for the department to review. I have seen the difference in team members after attending TOGAF courses if they haven’t had a broad IT experience in their careers. I haven’t done anything formal around Six Sigma but have heard good reports from friends who have used it. There also seems to be a tight bond between Six Sigma and ITIL/ITSM in Canberra these days but I am not sure if this occurs outside Canberra. Which ones have you used and what are your thoughts on there success?

  2. Andrew:  Thanks for the feedback.  To answer your question, I’ve used each and every one of the ones I mentioned in one context or another.  I hope I did not leave you with the impression that I did not see good value in them.  My point was simply that, by themselves, they solve nothing.  it is the implementation champion that determines how much success they will have.

    I watched ITIL give an organization a framework to define business services, their SLAs, and how to maintain/restore service quickly – all to great customer benefit.  Then watched them use it to strangle the development organization and cripple its ability to deliver change.  So they tried implementing CMMI to solve the problem and got hopelessly confused.

    I watched a manufacturing organization make great gains in getting Lean by applying Six Sigma, then watched the IT organization try to do it and get completely lost.  Not enough data points to generate a meaningful sigma.

    I watched an organization floundering on what an architecture group ought to do if they formed one, and watched them founder worse when they tried to implement TOGAF.  if you don’t know what you want, a framework’s ability to ask the right questions won’t lead to the right answers.

    I’ve seen PMP used to form a PMO effectively, then watched a different organization hire only PMPs who are all completely autonomously independently disorganized. 

    The framework is not the answer.  Choosing the right person to lead it (then get the heck out of the way) for the right reason is the right answer. In answer to your question about Canberra, I have only seen one organization using ITIL attempt adding Six Sigma. They had SS in some other non-IT processes, and tried to get enough data to play with in IT by implementing the concept of “Function Points” which could yeild sufficiently measurable numbers. It fell apart because no one could agree on how many function points a program had and management did not consider the exercise worth the effort since ITIL was doing reasonably well there at the time. I personally applied some six sigma analysis to a serious procedural failing at that organization and build a whole new poka-yoke type solution to the release process to prevent further occurrences – but I never told anyone that SS was involved, lest it taint their enthusiasm for implementing the solution.

    Let’s take this a step further, in a different direction – in organizations that have done adequately well at implementing ONE framework, do they often succeed at implementing another?

    I’m having a challenge in my current organization around configuration/change/release management and would love to hear your success story in that arena. Would you care to contribute an article?

    Thanks for lending your viewpoint!

    Glen

Leave a Reply to Andrew Ritchie Cancel reply