Viral Microprocesses – Micromanagement, Reloaded

“Mr. Consultant, this is really simple. Please just write down how you proceed with the use case specification step by step. This must be straightforward; you will surely have something like this ready to use in your drawer, right? The Customer is the King.” The brave consultant does not hesitate. “You will have the paper on your desk by tomorrow morning.”

The following night seems endless. The consultant keeps asking himself how he is to actually transform the process of understanding and thinking into a linear ten-bullet list. With the morning grey, after many drafts and moments of despair, he comes to the conviction that one cannot define a “thinking” process. In practice, the domain must be analyzed and precisely transferred into a language understood by business people and IT specialists. He sits down and writes the following list:

• Interview all stakeholders.
• Classify the results according to their functional and non-functional nature.
• Please review the requirements with both customers and IT, ensuring they are understood.
• Write Use Cases, review them again, and pass them on to IT.
• Track the implementation.

“Mr. Consultant, why are you bothering me with such trivial stuff? That is much too high-level and too general. I’m sure you know exactly how you will proceed with using case analysis in detail.” The customer is well-prepared for the meeting and goes on to summarize the method, presumably taken from some classical Use Case book, concluding that the use case analysis is a creative process; mutual understanding and classifying of the use cases must be done carefully, etc. The summary is basically identical to the consultant’s paper. “I know all that,” the Customer continues. “But you, being a professional process specialist, shall please deliver a detailed description of the use case analysis process in ten simple steps. And don’t forget the metadata!” “Metadata? Good heavens, how could I forget the metadata?“ thinks the consultant, deeply frightened. But wait: what ‘metadata’ was actually meant? Another sleepless night follows. By the next morning, the consultant is definitely sure: the way the human brain works definitely cannot be described in “ten simple steps .” There is no “metadata” replacing it. The customer has read something about metadata in content management systems in an online newspaper and passed it on to the consultant. The time has come for the consultant to decide how to make it clear to the customer. These events are taken from daily project life; they are not horror fiction. Computer scientists have a big problem: Excel users often tend to assume that software development is just as easy. Interestingly, a customer is not very likely to ask a construction or hardware engineer to please describe in 10 easy bullet points how the design, the processor board, or a new railway bridge is created. Why? Because most of us have accepted the fact that building bridges requires complex knowledge and thus it should be left to the experts. However, in IT projects that kind of micromanagement is frequently practiced. It leads to such absurdly detailed inquiries as described above. In this particular case, our consultant resisted the temptation to create an obsolete “bullet list” seemingly describing the actual “thinking process.” Obviously, thinking is not a linear, easy-to-understand activity. The requirements analysis has served us here as an example. No process area is safe from the attempt to be defined on a microscopic level. The requirements development process is particularly susceptible to such inquiries because it is very complex and challenging to understand for non-experts. However, many other process areas, such as “Technical Solutions” (software design, implementation), fit this scheme. Our consultant could have sketched a list riddled with shiny technical terms (metadata, traceability, reuse, etc. would definitely have to be mentioned several times). Such a hyper-loaded list would probably be approved without examination, as it is not uncommon in the day-to-day software business. This list would automatically become obligatory to anyone working in the area, with all its consequences. It would most probably contain directives of the kind: “acquire, analyze and classify the metadata.” – who would ever seriously try to understand that? The result: the requirement analysis becomes suffocated by misunderstandings and too many rules. And the process of conformity audits would become arbitrary. That is an example of “Viral Micro Processes.” Those are hardly visible, small beasts that continuously disintegrate the overall process and decompose it into a useless set of regulations. To make things even worse, they are contagious; once a Viral Micro process is defined in one area, it will likely become standard for all “neighbors.” They will likely become an essential part of statistical data presented to the senior management to document what areas are well or insufficiently documented. The overall consequences are easy to guess. Viral microprocesses are likely to paralyze an organization, and they are exactly what a process designer would try to prevent at any cost: thinking regulations. The more complex a process area, the more dangerous it becomes, and the worse its impact on the overall success of the project outlook. What can be done against Viral Processes?

• When in doubt, it is better to be inaccurate than too exact. In a project environment, if real experts are at work, they don’t need detailed instructions on how to do their job. Experts only fail when they work based on the wrong requirements. Viral Processes will only make it worse.
• Internalize the CMMI basic ideas. CMMI appears quite complex because it formulates a large set of practices for each process area. However, it is based on simple rules called common features:
  • Commitment to perform; do we want to do it?
  • Ability to perform; can we do it?
  • Directing implementation; conduct and tracking the work. Are we actually moving on and in the right direction?
  • Verify implementation: is the job finished? Do we have what we wanted? If not, why not? And what can we improve?
• Do not discuss the processes democratically. If the responsible persons don’t understand how to create and establish a systematic work procedure from the very beginning, then each discussion will be led on the political, unproductive level. Consider hiring a good consultant.

Thinking is indefinable. We must live with this sober truth. Simple, clear objectives and a healthy common sense should at least be expected of each manager. Any checklist cannot replace these attributes.

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).