In the past few months I have been cross pollinating my interests. One thread I have been seeing across several of my groups is around the concept of building a better organization.
The topic that has got me thinking is focused on helping organizations Change/Transform more easily. Taking cues from the agile thinkers I have been interacting with, a key component seems to be the idea of being able to adapt quickly. Adapt to market forces, to new technologies, to new ideas, to developing trends… to adapt quickly to Change. In Change Management discussions I have participated in as of late, there has been general agreement that we not only need to help our clients deal with the change that is in front of them, but to also help organizations be more ‘change friendly’.
To me, there are two main concepts that rise to the surface when helping organizations adapt to the degree of transformation that’s required: agility and frameworks. The idea of frameworks comes from an idea I developed through conversations in the Operational Excellence field and impacts the organizations in two important ways. The first we will deal with here, the second I will address in an upcoming article entitled “When did Thinking Fall out of Fashion?” The idea of agility comes from Agile software development processes in the IT industry as a counter to the limitations many were encountering in the more traditional waterfall process. Key concepts from the Agile community are “fail fast” and “short sprints”, each guided by direct feedback from customers.
Frameworks are also related to the thinking in the Agile community and speak to having guidelines or parameters with agreed upon outcomes rather than strict rules and controls. While not mutually exclusive, the concept of frameworks combined with the flat organizational structure seems to offer strong opportunities and rapid evolution.
But What About Standardized Work?
While the benefits of the Agile approach and the idea of frameworks have immediate appeal, they soon conflicted with my past work to standardize and document.
I began to wonder if we have taken influential thinkers such as Dr. W Edwards Demming (who is quoted as having said “People need to know what their jobs are.”) a little too far. In the automotive industry, my early work centered on standardization and “Leaning” processes on the assembly line. The concept fits nicely. Most of these processes are repeated many times an hour, and standardization is one of the keys to both productivity and quality.
This work expanded when I was preparing for ISO audits, I went through and did the same with office processes. However, even at that time it did not seem to fit. More recently, I have found many organizations who are so bent on control that they are creating ‘standard Project Management’ or ‘Standardized Change Management’ in areas where standardization not only does not fit, but can reduce overall project success rates.
Standardized processes reduce creativity; after all, the whole reason for standardized processes is to reduce variation, eliminate errors, streamline… eliminate the need for the worker to think…
How can Frameworks Help?
The concept of frameworks comes up in several contexts. The first is the idea of having a team who all understand their responsibilities and how to support each other – as demonstrated by Formula One Pit Crews.
This is a popular video that shows how process improvement has been applied to the pit stop process in a formula one race which demonstrates the value of knowing what your job is. In the second part of the video watch the character second from the bottom right – as the race car pulls in, his hands hover over where the tire will be – his sole focus is on the only job he has – pulling the tire away from the car as quickly as possible. Coming from an IE background, this idea appeals to me for many different reasons. The first is the idea of repeatability – the statement if you can’t measure it, you cannot improve it – and if the process is not repeatable, it cannot be measured or performed with any degree of reliability. However, if you watch the video carefully, you can also see an instance where one of the crew steps out of their role to complete a job that needs doing…
What this video illustrated to me was the strength of defined processes and roles in completing certain tasks, the value of knowing what everyone around you is responsible for, and the understanding the goal as the primary driver who allows members of the team to step outside of their roles to complete unscripted tasks that help accomplish the end goal.
How Defined Processes Actually Hurt
The ideas solidified for me when I thought of the typical mortgage approval process at your local financial institution. Usually you are referred to a mortgage specialist, who then helps you to fill in a myriad of forms detailing information that your financial institution should already have – most of us have direct deposit, so both our employer and our pay is known, as is our current address. Certainly there is new information that is required – such as our new address – but given that you have to set an appointment with the advisor, wouldn’t it be convenient if most of the required information was already filled in by the system and just required your signature. But the system is not set up that way – even if you have a 20 plus year relationship with that particular branch, you are treated the same as any stranger walking in off the street. When you have that relationship, who is the best judge of your reliability and ability to pay other than the people within your own branch – but like everyone else, you have to have your paperwork sent off to a separate group for the 1 to 2 week approval process. How much time could have been saved if the person were able to pull information from a variety of sources within the bank; and, operating within a set of guidelines, was able to make a judgement call right on the spot? After all, if you cannot trust your employees to make good judgements based on a framework that you supply, I suggest that you probably have the wrong employees.
What About Organizational Maturity?
A variety of tools and language has been used to justify the need for formalized process. The maturity model concept is one of these that I still use and was introduced to me when I made the move to consulting. I was an early adopter of the Maturity Model framework (from CMMI) outside of the standard IT usage and adapted it to Project Management (before OP3 was published), then used it to evaluate the maturity of other disciplines.
Many of us are still constrained by the belief that “if you cannot measure it you cannot improve it”- originated by Lord Kelvin and then propagated by such thinkers as Deming and Drucker.
As an active participant in the Six Sigma world, I have been asked by organizations to assist with the implementation of six-sigma, I have had to decline because they lack the maturity required for the process to be successful Six-Sigma requires stable repeatable processes that generate results that are able to be measured and compared. These organizations were looking for a quick fix and were not willing to invest in simpler solutions that would generate immediate success. Someone within the organization had been blinded by publicized six sigma successes without understanding that it is one of many tools, and definitely not the first one that should be adopted (but that is another discussion).
While I continued to work in helping organizations increase their maturity, the idea that ‘we’ could do better was germinating. It was a conversation with the Chairman of a Canadian Insurance Company that really challenged my beliefs. He made a few statements that challenged my world view.
My Aha Moment
One statement he made, given in the context of this discussion, was that the very structures that were put in place to reduce risk, made them much less efficient and much less agile. His comment brought to mind the following comment:
“The biggest risk is not taking any risk… In a world that’s changing really quickly, the only strategy that is guaranteed to fail is not taking risks.” —Mark Zuckerberg
An example of how cumbersome and bureaucratic they had become was the over proliferation of meetings that had little to no business value. Like many organizations they were meeting-ed to death, and he had witnessed the scourge of seeing meetings to plan their meetings (I experienced this early in my career to my great frustration). This is only an example of how organizations can evolve into unproductive behaviours as more and more structure gets put in place aimed at reducing risk.
The implications of this statement only increased as I had discussions with leaders in the Agile community. Operational Excellence leaders, other Change and Transformation Managers, and most recently the CEO of the Canadian Association of Management Consultants.
It was a statement by the latter that crystallized my thinking and rationalized those dearly held beliefs with the idea of an agile organization (meant in the dictionary definition of agile rather than the practice of Agile).
What we need, he said, was a FRAMEWORK within which an organization would operate.
How could Frameworks Help?
If you google framework, you come up with a lot of varying definitions. The simplest comes from the Merriam-Webster Dictionary which states “… a basic structure underlying a system, concept or text.” To summarize what I found in literature there, is general agreement which builds off of what the dictionary defines and states that “Frameworks leave individuals operating within these frameworks flexibility in choosing which tools, processes and procedures to follow in pursuit of a stated goal.” Ironically, most articles go on to criticize frameworks for that very reason.
The idea of frameworks goes against everything I have supported in my career to this point – the idea of formalized, documented, measurable processes and the continuous improvement mindset that they support.
When you work within frameworks, and you trust your employees, then you set them free with clearly defined goals or objectives, and guidelines or parameters within which you need to work. How they go about accomplishing the goal is up to them. While some, as I did, will cringe at the potential chaos that will result, think of the other implications.
With formally defined processes, likely all you will ever get is either the status quo or small incremental improvements. While I will agree that incremental improvements are better than no improvements, if you really want to get ahead of your competition what you need is not incremental improvements but quantum improvements – improvements not necessarily in the process but completely new ways of delighting your customer, and that requires a loosening of the reins and trust in your employees intelligence and ingenuity.
Where Does Agile Thinking Fit?
Agile builds on this idea and takes it further supporting the concept of finding and testing solutions – it accepts that not every solution will be the best one, but allows communities to explore multiple solutions, safely, and then to pick the best of the solutions tried. Like Six Sigma, it puts the customer at the center of the process and has structures in place to get feedback as the solution evolves; allowing the team to adjust as they go ensuring the final solution is what the customer wants.
While Agile is so much more than this, and there are specific tools and techniques that enhance and support these ideas, the idea of being able to adjust quickly and innovate is something that would help most organizations.
It seems to me that if we want to be able to respond to the external forces that are impacting our organizations and support those inside our organizations in helping them to deal with a frantic rate of change, that these concepts hold some keys to what may be required. We need to loosen the reins, trust our employees, and allow some freedom in how services are delivered. If we do this well, and provide the proper guides and target, we free ourselves from incremental improvements and enable the sort of agility required to get in front of market forces and competition from non-traditional sources.
By Paul E. Køhn P.Eng
Paul E. Køhn P.Eng was trained as an Industrial Engineer at Dalhousie University in Halifax. He ‘grew up’ in the automotive industry where he honed his Lean knowledge implementing various Lean and continuous improvement tools. For the past 10 years he has been working as a consultant, coach, trainer and speaker in various industries always challenging the conventional thinking of his client organizations. He specializes in all dimensions required for successful transformation: Strategy development and deployment, Process Engineering, Technology design, selection and implementation, Portfolio, Program and Project Management and, his current passion, Organizational Change Management.