The Alphabet Soup of Process FrameworksBy Corinne Bernstein | Posted 2009-09-29 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
A new study reveals that IT process frameworks are more alike than they are different.
Although the mention of IT process frameworks—such as CMMI, COBIT, ISO 20000 and ITIL—might bring to mind a complicated recipe for alphabet soup, a new study reveals that these frameworks are more alike than they are different.
The study, “IT Governance and Control: Making Sense of Standards, Guidelines and Frameworks,” was prepared for the Society for Information Management by Sue Conger, an associate professor and director of IT and IT service management at the University of Dallas, and Ulrike Schultze, an associate professor at Southern Methodist University. It shows considerable overlap among the frameworks, even though they emphasize different aspects of IT processes and use different vocabulary and conceptual schemes.
Developed by auditors, COBIT (Control Objectives for Information and related Technology) focuses on risk management and controls. Meanwhile, ITIL (Information Technology Infrastructure Library), developed by IT professionals, concentrates on IT operations, and CMMI (Capability Maturity Model Integration) was developed by IT professionals for application development functions. On the other hand, ISO 20000 is an international standard for process management.
SIM’s Advanced Practices Council report, which is based on five case studies and uses a cross-referencing tool for mapping the frameworks, shows that IT organizations use process frameworks for different reasons, such as justifying investments and other key decisions, providing credibility to their practices and supporting process-improvement initiatives.
Despite these differences, applying the frameworks in a complementary way is beneficial, says Conger. She recommends using the study’s cross-referencing tool to make the frameworks “more actionable” and to provide a broader perspective of IT governance and service management.
The tool helps integrate the frameworks into a process blueprint for the IT organization. Through the tool’s cross-referencing links, each framework builds on the other, Conger explains.
Moreover, process standards and frameworks don’t necessarily limit flexibility or create bureaucracy. The study finds that organizations have considerable freedom in implementing the process frameworks.
“Our case studies have shown that there is little risk that process frameworks will lead to straight-jacketed, commoditized IT processes by themselves,” the report concludes. “For one, the frameworks are purposely nonprescriptive; they bill themselves as ‘best practices guidelines’ rather than ‘standards.’ Furthermore, by limiting themselves to what a process should do, rather than specifying how it should be done, the frameworks are generally too vague to be used prescriptively.”
Although process frameworks should not impair flexibility, organizational culture and individual personalities could lead people to “proselytize these frameworks with religious fervor,” the study says. There is also the risk of overengineering processes and controls, especially in the face of Sarbanes-Oxley (SOX) and Health Insurance Portability and Accountability Act (HIPAA) regulations.
The report dispels the concern that companies, particularly small and midsize organizations, will need to add employees to develop, document, measure and improve processes. The case studies show that most of the design and implementation tasks had been done by professionals who were already doing the work affected by the process initiative.
The report includes the following recommendations for IT organizations:
1. Define your objectives before committing to a process framework. Determine whether the objective is certification, risk management or regulatory compliance, service improvement or cost reduction.
2. Select a process framework or frameworks, but remember that each process framework has a different purpose.
3. Set a deadline. Successful process improvement hinges on knowing when to stop or, at least, pause. In the case studies, deadlines such as SOX requirements or certification audits were considered key milestones.
4. Seek outside assistance. If your company doesn’t have enough experience with processes, consultants can help you avoid overengineering.
5. Create an infrastructure for the process-improvement project. This includes securing a commitment from top management, developing a process blueprint to give participants an idea of their roles, selecting and training the project team in the frameworks, and developing a project plan with stage gates and deadlines.
6. Develop new processes. The process frameworks are intended to be best-practice guidelines, not one-size-fits-all solutions. The frameworks must be adapted to the organizational goals and needs. However, the report suggests that IT organizations should have a full understanding of their current processes and take an evolutionary approach rather than a re-engineering tack.
7. Develop an implementation and change-management plan. Set priorities and shift to new technologies and processes in phases.