The Role of Organizational Maturity in Process Adoption

The Role of Organizational Maturity in Process Adoption


Authors by Joe Bauer
Process Owner, University of Michigan
PhD Student, Eastern Michigan University


Rachel Apgar
Process Owner, University of Michigan


When trying to get an organization to adopt a process, such as IT capacity management, the maturity of that organization is a mediating factor that can either limit or contribute to the success of the effort. Regardless of whether you’re implementing an ITIL version of capacity management, a process an author recommends, or a capacity management process of your own design, the maturity of the organization adopting it needs to be kept in mind.


When talking about processes, the authors specifically mean business processes. The basic structure of a business process takes inputs and turns them into outputs through a set of pre-determined activities organized in a purposeful order [DAVE93] [AGUI04] [FURE02] [HAMM03].

The pre-determined activities carried out within a process are patterns of interactions. No process activities are completed in isolation; activities must hand off to other activities, forming a process flow. Those handoffs require some level of interaction, even if seemingly insignificant. In simplistic terms, patterns of interactions are a behavior [BLUM69]. The set of expectations around patterns of behaviors is culture [BLUM69]. Within a given culture there are certain expected patterns of behavior, such as how to conduct one’s self while eating a meal with guests. If one doesn’t meet those expectations (belching at the dinner table?) that person’s behavior could be seen by the others as rude, anti-social, dim-witted, etc. With business processes setting out to achieve specific outcomes through specific interactions, what is essentially happening is an artificial set of behavioral expectations, or culture, is being imposed upon the people who would carry out the processes. That is to say, the interactions, behaviors, and culture did not come about naturally though a sort of social evolution -- they are being directed in order to advance the goals of the organization.

Humans have agency and are not programmable robots that perform instructions unquestioningly [GIDD82]. As Giddens states, humans " . . . are not merely inert objects of knowledge, but agents able to -- and prone to -- incorporate social theory and research within their own action" [GIDD82]. Because of this agency humans interpret the symbolic meaning of the actions and interactions of other humans and decide on their own how to react or interact back. When encountering the artificially imposed behaviors or culture (the process trying to be implemented) the human may choose to behave in a manner that is not compliant with the process objectives.

Frederick Taylor, the father of scientific management -- the ancestor of many modern management techniques -- addresses this struggle between human agency and the need to enforce this artificial culture (processes) when he rails against “lazy” workers who have a “. . . common tendency to 'take it easy'. . . ” [TAYL11]. A machine takes orders without question, but humans have a tendency to invoke free will. Taylor’s solution in the early 1900’s, in essence, was to force the humans to be more machine-like.

As managers of a process, if we do little more than point people to a process flow diagram are we not also advancing the same Taylorist, cold, machine-like viewpoint of the human condition? Do we, unintentionally, expect people to perform the processes as robots would, perfectly as programmed and without question? We must recognize that there is the process flow diagram and then there is also the way the process actually is (or will) be performed by the actual humans who animate it. No matter what we as managers of processes want, it is what those humans do, not what is on the diagram, that is the process. The real process.

Organizational Maturity

When thinking of the term ‘maturity’ one may envision petulant teenagers or toddlers throwing tantrums. In this case the term is simply meant to convey the type of capability around which an organization is structured. As Young states, this is not a value judgement, and an organization being at a higher maturity level does not automatically mean it is “better” than another [YOUN11]. Many frameworks for measuring and describing maturity exist; we’ll take a brief look at just three of them.

ITIL has a process maturity framework with defined maturity levels starting at one and going through five [OFFI11]. These maturity levels are measured along five dimensions: vision and steering, process, people, technology, and culture [OFFI11]. At the lower levels, vision and steering is not well defined and has minimal investment. The processes are ad-hoc and the roles for the people are generally not well defined. The culture is one that is focused on technologies and individuals. Generally, it’s a reactive world with isolated IT super heroes. At the highest levels of maturity the strategy for the organization and for IT are indistinguishable.

Roles are part of the culture, technologies are highly automated, and the culture and processes are focused on the business and customers, with continual service improvement a natural part of operating. The journey through ITIL maturity levels is one that goes from being technologically focused, to process focused, to service focused, and then to business focused. In discussing its process maturity framework ITIL is quick to point out that “[t]he maturity of service management processes is heavily dependent on the stage of growth and the culture of the IT organization as a whole. It is difficult, if not impossible, to develop the maturity of service management processes beyond the maturity and capability of the overall IT organization” [RUDD10]. What ITIL is telling us here is that we have to match the process maturity to the organization’s maturity.

Gartner’s IT Delivery Model Maturation Framework describes four models for delivering IT: Asset-Optimizing, Process-Optimizing, Service-Optimizing, and Value-Optimizing [YOUN11] [YOUN11a] [YOUN11b]. Similar to the ITIL model, the Gartner models at the lower end of maturity describe a technologically focused organization with siloed skill sets lacking the capability to have end-to-end accountability for service results [YOUN11]. At the other end of maturity, the Value-Optimizing model describes IT as contributing directly to the enterprise financially, no longer being a cost center [YOUN11]. In some cases IT is like an R&D lab or fully “fused” with the business [YOUN11]. Gartner also warns that while trying to move an organization through their maturity levels “[m]odels cannot easily be skipped” [YOUN11].

Even in the world of Enterprise Architecture there is the concept of maturity levels. Ross describes them as “four stages of architecture maturity” [ROSS06]. These stages go through business silos architecture, standardized technology architecture, optimized core architecture, and business modularity architecture. In the business silos stage IT focuses on automating specific business processes, and investments in new IT are justified as reducing cost [ROSS06]. In the standardized technology stage a shift toward shared infrastructure starts. Fewer technology platforms results in lower costs. Fewer platforms means fewer choices, but the advantage is in the IT budget reduction enabled by the standardized technology stage [ROSS06]. In the optimized core stage the focus shifts from localized data and applications to an enterprise view of systems and shared data. "In providing predictable business outcomes, standardized data and processes allow for process innovation closer to the customer" [ROSS06]. This is similar to saying that by standardizing operations, or the stuff that keeps the lights on, you can then spend precious time and resources on innovation closer to where it makes a real impact - closer to the customer. The business modularity stage provides seamless links between business process modules [ROSS06]. The process modules are built on the standard core, which is built on the standard technologies, so the progression through these maturity levels is additive where one level depends on the previous in order to work [ROSS06]. Therefore, logically, no stages can be skipped. Ross notes that while progressing through these stages the localized flexibility (individual or team level) is reduced, whereas the global flexibility (organization-wide) is increased [ROSS06].

Why should I care?

We all want to be amazing and implement the very best processes. It’s natural to have the desire to implement a very mature process even if an organization is not ready for it. The common theme from the above maturity frameworks is that they all have an ordinal path with steps that shouldn’t be skipped because they each build upon the previous ones. The process maturity must match the organization’s maturity. If there is a mismatch between the maturity of the process being implemented and the maturity of the organization, the process will either be seen as too complicated and cumbersome or too limited and simplistic. Either path leads to ineffectiveness.

What should I do?

To match the process maturity to the organization’s maturity you have to be willing to get out and talk with people. Find a maturity framework (like one of the frameworks above) that works for you and start measuring your organization. Measure how processes are handled today and remember that it’s how the people doing the work actually perform it, not the fancy drawings in the process flow diagrams, that you should measure. Then design (or redesign) the process to match the maturity capabilities of the organization. When you implement the process remember that humans with free will and agency perform these processes, not robots.


DAVE93] Davenport, Thomas. Process Innovation: Reengineering Work Through Information Technology. Boston: Harvard Business Press, 1993.
[AGUI04] Aguilar-Savén, Ruth Sara. “Business Process Modelling: Review and Framework.” International Journal of Production Economics 90, no. 2 (July 28, 2004): 129–49. doi:10.1016/S0925-5273(03)00102-6.
[FURE02] Fu-Ren, Lin, Meng-Chyn Yang, and Pai Yu-Hua. “A Generic Structure for Business Process Modeling.” Business Process Management Journal 8, no. 1 (2002): 19–41.
[HAMM03] Hammer, Michael, and James Champy. Reengineering the Corporation: A Manifesto for Business Revolution. New York: Harper Collins, 2003.
[BLUM69] Blumer, Herbert. Symbolic Interactionism: Prospective and Method. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1969.
[GIDD82] Giddens, Anthony, and Fred R Dallmayr. Profiles and Critiques in Social Theory. Contemporary Social Theory. London: Macmillan, 1982.
[TAYL11] Taylor, Frederick. The Principles of Scientific Management. New York: Harper Bros., 1911.
[YOUN11] Young, Colleen M. Strategic Decisions for Optimal IT Service Management, June 28, 2011.
[OFFI11] Office of Government Commerce. ITIL Service Design. 2nd ed. Norwich, UK: The Stationery Office, 2011.
[RUDD10] Rudd, Colin, Great Britain, and Office of Government Commerce. ITIL V3 Planning to Implement Service Management. London: TSO, 2010.
[YOUN11a] Young, Colleen M. Service Management, ITIL and the Process-Optimizing IT Delivery Model, June 28, 2011.
[YOUN11b] Young, Colleen M. Running IT Like a Business 2.0: The Service-Optimizing IT Delivery Model, June 28, 2011.
[ROSS06] Ross, Jeanne W., Peter Weill, and David C. Robertson. Enterprise Architecture as Strategy. Boston: Harvard Business School Press, 2006.