The meeting had been underway for about half an hour. Our departmental and quality assurance managers were debating what specifications should we measure against and what database would we need to keep the data in. The meeting had been called by the Engineering Process Group (EPG) of our R&D Optical Networking Business Unit, weeks after an ISO assessment had been done. I was attending as an internal consultant to the EPG.
I felt rather lost. Finally I mustered up what remained of my energy, and asked, "What problem are we supposed to be solving?"
After an odd silence followed by a chaotic discussion on what my question actually meant, an Engineering manager answered: "We are working on customer satisfaction issues!"
My mind wandered to the CMM and ISO Process Improvement activities of our Business Unit. The general perception in the trenches seemed to be that the process assessments were needed to "sell" our product to potential customers. That had nothing to do with our "real" problems of course. Storms come from Above and we just hide until they blow over. Some wished to use CMM and ISO assessment results to solve some of the real problems: The people in the EPG, for instance. In the EPG we were maintaining an overview of problems with an affinity grouping and interpretation of first order measurements (observed data).
History
The "old hands" of the Business Unit told us that earlier process improvement attempts had failed. "Failing" meaning "never meeting written down goals." They were cynical of our attempt but very happy to share why they thought earlier attempts had failed. With further inquiry it seemed to boil down to "mixed messages from executive management" like
"Speak your mind but don’t ask too many questions; Be passionate but don’t show your real feelings; Improve quality and production but hurry up and get it right the first time!"
Deployment
In a haphazard fashion, in between peek pressures for deadlines, problems were investigated, solutions found, a single one chosen for all project members to use and then described. And that was it. Problems were considered "solved" after a new procedure or process was created and placed under version control in "approved" state. The solutions were virtually unknown to others. Nor were they used much.
Management Process
Management asked the EPG to support the transition to a next CMM level, but support from management processes for the improvement activities was not visible and clear enough through actions and resources. Unknowingly, problem solvers in many different small Process Improvement (PI) teams spread over all departments and locations in different countries were working on same or similar problems. And every time a deadline came near, which was nearly the case at all times, people dropped PI work to do "the real work."
We seemed to be too busy using our crippling processes to improve them. Were we solving non-problems then? The Business Unit definitely had problems. And seemed not very effective at solving them. And the waves of jokes on mixed messages from executive processes, showed clearly what the "distribution speed of information in the organization" could really be: highly effective! Why did these messages get through, when other formal communication seemed to be blocked and bottled up?
My mind fled to the larger context. I also had a role in teaching systems architecture and facilitating retrospectives and architecture reviews in the larger organization, providing me with some more experiential and grounding information. I could easily recognize many organizational patterns and problems playing in this Business Unit:
Prioritization
There was a lack of visible organizational priorities in the operational part of the BU. A list was available however, on a web page on the intranet. A web page that hardly any techie ever visited. These prioritized issues changed often, and not always on the web page: The page was last updated a year ago. Every time a Big Boss from the US visited the site, the CMM level that we were supposed to "go for" in our Process Improvement efforts went way up -if not in reality then rumored- only to be lowered again a couple of weeks later at the cost of EPG members spending time and energy on managing the managers.
Negotiations
Projects were often trying to do everything. Promising customers too much or working on too many projects at the same time happened regularly. The Guessing Game, where one is only to guess at and agree with what others want to have happen, seemed part of the culture. And the Guessing Game can make requirements, specifications and planning documents untrustworthy beyond simple recoverable mistakes. This opens up many spaces for wishful thinking.
Problem Definitions and Requirements
One of the moments I realized this, was during a simulation where participants in a workshop were challenged to meet a customer’s expectation. To the participants, the customer requirements seemed to change while in actuality they didn’t: The participants had been sorting cards according to their own assumption of what "the order of sorted cards" means, instead of asking the customer for more specific requirements. I heard a participant say with a frustrated undertone, "The customer doesn’t know what he really needs."
As a result of wishful thinking about what a customer needs and wants, problem or project statements were unclear, incomplete or even missing. In some projects the related documents became unstable, so much that many techies stopped caring or bothering. In others they seemed to be written in stone -considered unchangeable- while their contents was no longer very useful. It’s not amazing that there was no project wide understanding on the purpose of these projects. And without project purpose it is impossible to do explicit expectation and goal setting in relationship to project purpose and significance to the business.
Organization
In turn, without explicit expectation and goal setting, getting clarity on roles and responsibilities becomes impossible. And we found hardly any explicit management of internal (organizational) interfaces and relationships between components/groups, so developing them wasn’t happening either. Indeed, the engineers seemed to have no clue about the impact of their work on the development departments, and the development departments no clue about the constantly swamped testing & integration department.
Testing and Quality
We were trying to test quality in! Which quality?? What is quality to whom?!?
The global organization had a list of 5 company values for all thousands of employees all over the world. One read "Exceed Customer Expectation." How many projects had we shipped in the last year that did not live up to customer expectation, let alone "exceed" it? I had no idea. None of us was directly in touch with customers and users so how will we know how we are doing?
Hhhmm, maybe the real problems could be found in our models, or rather in mistaking models of reality for Reality itself. We are extremely good at drawing cause and effect relationships, and that predisposes us to stepwise programs for making improvements in our organizations. Maybe this "blocks" change or improvements?
What were some of the dangers of modeling I had experienced, fallen prey to or seemed to have seen around me in this organization?
A Staircase To Heaven
Many of us like working with ideas and models and Quality and Process Improvement models can be interpreted as an architectural description for designing an Universally Successful System, The Essence. We are attracted to abstract models of perfection whether the object is a project, an organization or the entire company.
Visualizations of models can suggest we could be walking up a staircase to Heaven. For instance, the CMM framework can easily be seen like that. Heavenly visions can land any organization, small or big, in a mode of discussing and wanting to do "the essential thing to solve all problems" and never getting around to doing anything in a more earthly manner.
Causality Loops
If there is a best way, and if I see It and if you are one of the best modellers like me, you will understand my solution and that it is True. It’s nearly like a mantra. But when we think we can choose a solution before we can experience it we may be caught in a causality loop. Older organizations in routine state seem especially susceptible to causality loops by use of their own standardized and consistent core -essential- processes:
We have procedures that have guided us effectively and fast (in the past) — Their description covers our mental models of "the way to do things"
The problem must be solvable using our guides — Else, it is not a problem that can be solved.
We do not have to try a new way of doing things — For we already have our (perfect) guides. Go To 1.
Cultural patterns that might be related, were
When people made an agreement, it was often assumed that all involved were thinking the exact same thing.
A problem was considered solved as soon as the till then experienced as fastest thinkers had reached an answer.
People were often discouraged from speaking out, even with verbal messages from management like "open door," "feedback" and "doing together".
People rarely gave accurate descriptions of the opinions and reasoning of those whose opinions were at odds with their own.
Questions were often perceived as challenges, as being questioned means one has possibly done something "wrong" " I am "wrong??" That can’t be!
Systems architecture and engineering were seen as a primarily pro-active effort, before development, and development before testing.
The Treadmill
When finally organizing a change, checklists of which all items need to be in place are a relief. Now we "know what we’re doing" Ö with the details of the modeled solution replacing reality. We can be problem-solutioning instead of problem solving if we’re not careful. When only putting a structure in place we run the risk of Only Going Through The Motions. The actual problems hardly get solved while some non-existing problems do get solved. And who would notice?
The Business Unit is in a paradoxical state? If the management process could provide direction based on feedback, the organization would already be in a much better state for satisfying its customers? Models and standards do not provide enough transformational model or guidelines, simply because the "where to go" is unknown territory?
I came out of my reverie and discovered the meeting had continued: We were now discussing how to measure how well implementations were meeting our engineer’s models of customer wants and needs. And the schemes envisioned were big and costly.
I thought, "Customer Satisfaction? Can we start by asking our customers?"
(1) None of the symptoms, problems, perceptions and categorizations in this article are to be taken as absolutes. This is absolutely not intended to contain the last word, but more some words to stimulate thought, sharing of observations, discussion and (other) actions.