Absurdities of project management dogmas
Have you ever experienced the absurdities that happen when project management dogmas dominate feasibility matters? The task of drawing seven red lines is simple. However, a simple subject is no obstacle in making a project painfully complicated.
In this article, I will carve out lessons about successful projects from a brilliant sketch.
Subject Matters
Project Management is important, but specialists deliver the products. Below, we will see what happens when generic project management disregards the subject matter needs.
The commitment trap
Once upon a time, there was a commitment: We can do this! The boss promises an outcome of our expert’s work, without even consulting the expert: This is destructive [1]. The boss should consult the expert and leave commitments to him.
Impossible possibility
Later on, we learn that these red lines should be perpendicular, and drawn in green ink. This absurd specification is not the point. The point is two-fold:
- After having made a commitment, we now learn details of the requirement which make the earlier commitment void. The implementation is not feasible.
- We realize that the requirement cannot possibly be fully understood by its owner, because it includes contradictions and is geometrically impossible
Did I just say impossible? That word which Sheikh Mohammed bin Rashid Al Maktoum banned from leaders dictionaries? Yes, outside the world of marketing, impossible is a possible feature of a requirement.
The benefit of asking why
It is essential to understand the nature of requirements. When customers talk about their wants instead of needs, we cannot afford to stop there. Why do they need seven red lines? It will hardly be for the sake of having seven red lines. When the woman cannot explain to what the lines should be perpendicular to, the alarm bells should ring. She or some consultant was probably convinced that seven red lines would be cool, fancy or in some other way favorable (as the kittens would be). Be brave enough to ask why enough times to understand the advantage and benefit of the wants which customers express.
Interesting, not intimidating
It is revealing to see the reactions the instant that our expert is asking the client what her image of the result looks like. He gets slammed. His query is called kinder garden and declared as an unproductive quarrel. We witness an example of the almost paranoid repression of asking customers why they want what they want. Certainly, this activity requires well-developed negotiation and diplomacy skills, but that does not make it less valuable. In close collaboration with project management and business, companies have to build a relationship with the client where they understand that asking why is not intimidating but expresses real interest in a successful project.
My domain is not your domain
By now you might be feeling the need to say that customers should not have to worry about details such as perpendicularity, and instead leave the headache to the expert. That is true, provided that clients remain in their domain. In the case of software development, the client should say which particular business processes should be made more efficient with the help of IT Services. In the construction business, the future owner should explain the expected benefits from the newly built house. That could be having more space for the children or environmental considerations. However, if the client enters the expert’s domain, for instance asking for particular material to be used, then this inevitably comes with the price of talking details. Both parties should stay in their respective domain. For the client to stay in control of the outcome, leverage quality criteria: Talk about amount of square feet per child or percentage of heat loss of the thermal insulation.
Feedback never fails
Ultimately, we can increase the collaboration with the client by approaching the work in an agile fashion. Instead of agreeing on a result in one workshop upfront, agree to approximate to the result in iterations. Draw one red line per day and receive early feedback from your client. You can also refer to this idea with the Design Thinking slogan “Fail early fail often”. In close collaboration with the client, you are actively accepting that a creative process is never perfect right away. Also, the sense of ownership and engagement on the client’s side is increased.
Lessons Summary
Let summarize the lessons we have just learned:
- Beware of the dangers of promising outcome
- Acknowledge that impossible is a possibility in a world of limited resources
- Investigate the needs behind wants
- Build a culture where everybody understands the value of asking why
- Expert and client should remain in their respective domain and respect the borders. Use quality criteria as a control mechanism for the customer
- Consider an agile approach to prioritize and foster a sense of ownership and engagement on the customer side
Have you ever suffered from the tyranny of project management? Tell me about your experience.
[1] http://jockeholm.wordpress.com/2014/05/11/promises-promises-2014/
Categories: Business
Hi David,
“Tyranny” is such a strong word – but I really do love the title of this post (and the post itself).
I would really like to republish it on PM Hut where many project managers will enjoy(?) reading it. Please let me know if you’re OK with this either by emailing me or either by contacting us on the PM Hut contact page: http://www.pmhut.com/contact
LikeLiked by 1 person
Hello PM Hut,
thank you, I appreciate your comment. I am happy to hear that you like the post.
I will contact you regarding the republish.
Best regards
LikeLike
I think it comes to the mindset of predictability. Management thinks that software development is a simple and predictable work.
LikeLike
I agree that it is an issue if the engineering needs of software development are marginalized. That is true for any engineering process, however that mindset seems more prevalent in software development than in other fields.
I think it should be a goal of both management and engineers to make software development a more predictable work. Better alignment of IT and business and understanding the creative nature of software development are critical. Agile concepts such as bounded context and increments can enhance predictability.
LikeLike