“Mr. Consultant, this is really simple. Please just write down how you proceed with the use case specification, step by step. You surely have something like this ready in your drawer, right? The Customer is the King.”
The brave consultant does not hesitate.
“You’ll have the paper on your desk by tomorrow morning.”
The night that follows seems endless. The consultant keeps asking himself how he could possibly transform the process of understanding and thinking into a linear ten-bullet list.
With the first light of morning — after many drafts and moments of despair — he realizes: one cannot define a thinking process.
In practice, the domain must be analyzed and precisely translated into a language understood by both business people and IT specialists.
He finally writes this list:
-
Interview all stakeholders.
-
Classify the results according to their functional and non-functional nature.
-
Review the requirements with both customers and IT to ensure mutual understanding.
-
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’s far too high-level. I’m sure you know exactly how you proceed with use case analysis in detail.”
The customer, well-prepared, summarizes a method presumably taken from a classical Use Case book — concluding that use case analysis is a creative process, based on mutual understanding and careful classification.
Ironically, his 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,” thinks the consultant. “How could I forget the metadata?”
But what metadata was actually meant?
Another sleepless night follows. By morning, the consultant is sure: the way the human brain works cannot be described in “ten simple steps.”
And there is no metadata that could replace it.
As it turns out, the customer had read something about metadata in content management systems — in an online article — and simply passed it on.
Now the consultant must decide how to make that clear.
These events are taken from daily project life, not horror fiction.
Computer scientists have a big problem: many non-technical stakeholders believe that software development is as simple as using Excel.
Interestingly, no one would ever ask a construction engineer to explain in ten bullet points how to design a bridge or a processor board. Why? Because everyone accepts that building bridges requires complex expertise and should be left to professionals.
In IT, however, this kind of micromanagement is common. It leads to absurdly detailed inquiries like the one above.
In this case, our consultant wisely resisted the temptation to produce a fake “bullet list” describing the supposed “thinking process.”
Because thinking is not linear — and never will be.
Let’s start a conversation on LinkedIn or X.com (formerly Twitter).
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