Jaa

Practices vs. Processes

  • Artikkeli

In the world of IT as in most industries, the term “Best Practice” is often used to describe a set of activities that a business would consider as representing the most effective set of activities for achieving a particular goal.

But what about all those other activities that are not considered “best practice”? I would contend that many activities that an IT organization does would not be called a best practice. They may be effective, but not most effective. As an example, an organization might manually distribute client install discs for an application rather than create an automated software distribution mechanism. As another example, a development team may test an application completely manually rather than using techniques such as code coverage analysis and automated testing tools to increase software quality.

In both these examples, the job gets done but with significantly differing results on quality, cost, agility, and/or risk. I’d like to suggest that both these cases above are examples of what I would refer to as “Practices”, borrowing the Wiktionary definition as “The ongoing pursuit of a craft or profession , particularly in medicine or the fine arts.”

Forgetting the “particularly in medicine or the fine arts” bit, I find this concept is useful because it provides a way to group activities that can be aligned along a maturity curve such as the Microsoft Infrastructure Optimization Model. A practice could be called “Test Pre-production Application” for example, containing such activities as:

  • Develop test plans
  • Perform manual testing
  • Perform code coverage analysis
  • Perform automated testing
  • etc.

As you can probably see, some of the sample activities above could be performed at a very basic level, whereas some could be more advanced, requiring sophisticated sequences and a higher degree of automation.

Further, a practice is inherently associated with one or more of the War on Cost Value Pillars: Agility, Quality of Service, Cost, or GRC (governance, risk management, and compliance).

Practices Are Not Processes

There are many models out there that describe processes. COBIT for example, defines 34 core processes across four domains. ISO 20000 and other organizations also describe groups of processes as part of their model.

While these processes and have their place, what they lack is a distinct linkage to sets of activities that can be assessed for maturity along some value curve such as service quality, agility, or compliance. For example, the COBIT process “Ensure Continuous Service” does not say anything about how well the organization performs that process.

Also, these processes do not inherently align to specific value measures that are relevant to the business. While some of them may be implied, no model currently published makes this clear.

The Value of Practices

By defining sets of activities into practices and further classifying those activities into groups based on a maturity curve such as the core Microsoft Infrastructure Optimization (IO) model, it will be possible for us to assess how effective an IT organization is at delivering a service by determining how mature the organization is at delivering it (i.e., what activities does the organization perform at a given maturity level?).

Also, we can also align these practices to specific value measures that the organization wants to better understand. For example, practices such as “Manage Policies & Compliance” and “Perform Change Impact Analysis” have clear alignment to Governance, Risk Management, and Compliance (GRC). An organization that has a clear goal to assess their maturity around GRC can look at specific practices that are associated with that value dimension.

A Business Value Model

As the War on Cost team matures this definition of Practices, we will publish more information about how it relates to our larger definition of the War on Cost business value model. More to come…

All the best,

Erik

Comments

  • Anonymous
    December 15, 2013
    Pingback from Practices vs. Processes | DELHiTECHiES
  • Anonymous
    December 15, 2013
    Pingback from Practices vs. Processes | DELHiTECHiES
  • Anonymous
    December 19, 2013
    Pingback from Practices vs. Processes | DELHiTECHiES