“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 the practice, the domain must be analyzed and precisely transferred into a language understood both by the 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.
- Review the requirements with both customers and the IT; ensuring an understanding of the requirements.
- Write Use Cases, review them again, and pass them on to the 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 are going to proceed with the use of case analysis, in detail.” The customer is well-prepared for the meeting and goes on summarizing 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. It appears that the customer has read something about metadata in content management systems in an on-line newspaper and just passed it on to the consultant. 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 are 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 of being defined on a microscopic level. The process of the requirements development is particularly susceptible to such inquiries because it is very complex and difficult to understand for non-experts. However, many other process areas fit this scheme; such as “Technical Solution” (software design, implementation).
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 regarding 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 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 is likely to become standard for all “neighbors.” They are likely to become an important 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 Micro processes 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 they become, and the worse is their 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 from the very beginning how to create and establish a systematic work procedure, 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. These attributes cannot be replaced by any checklist.
I am a project manager (Project Manager Professional, PMP), a Project Coach, a management consultant, and a book author. I have worked in the software industry since 1992 and as a manager consultant since 1998. Please visit my United Mentors home page for more details. Contact me on LinkedIn for direct feedback on my articles.
Be the first to comment