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/