This article didn’t come out of nowhere. I recently had a recorded interview with Stuart Taylor on project management. While that specific video is not out yet, you can find his videos on YouTube. It was an exciting conversation and brought me back to project experiences that left me, let’s say, animated.
Over the years, I have had to clean up the results of project decisions made in the name of pragmatism. The rate of occurrence has dramatically reduced, but not to zero. This is partly because I have more influence over the projects these days. My experience informs me that the word “pragmatic” is sometimes used to hide a decision of impaired origin. My dad, a Vietnam Veteran, had a phrase for these types of actions, which I’m sure you’ll be able to infer. For our purposes, we’ll go with the phrase “half-baked.” Let’s define what we mean when we use this term in the context of project management.
Half-baked – An informal expression used to describe something proposed, done, or executed with minimal thinking, effort, care, or attention to detail. When a task or project is deemed “half-baked,” it suggests it was not given the proper amount of consideration past the idea and the effort required for a satisfactory outcome. This phrase often conveys a sense of laziness, lack of commitment, a disregard for quality, and lack of consideration for future consequences, resulting in a subpar and costly.
I must confess that the rampant and indiscriminate use of “pragmatic” in project management has become a source of immense frustration for me, and I’ll explain why. This term has been overused and diluted to meaninglessness, reduced to a mere buzzword devoid of any natural substance or understanding.
What is Pragmatic?
What does it indeed mean to be “pragmatic” in project management? Do we believe that slapping this label onto any decision or approach automatically makes it sensible and practical? I beg to differ. Pragmatism should imply a thoughtful and judicious approach considering a project’s unique circumstances, constraints, and objectives. It is not a catch-all excuse for cutting corners or making half-hearted attempts at problem-solving.
Misusing “Pragmatic” as a Shield
Sadly, I witness a disturbing trend of using “pragmatic” as a shield to justify mediocrity or stupidity. Project managers claim to be pragmatic when they choose the easiest path forward, opting for quick fixes and temporary solutions that patch over more profound issues. They prioritize short-term gains over long-term success, sacrificing quality, thoroughness, and foresight. This is not pragmatism; it is a disservice to the profession and those affected by the project’s outcomes.
In the Name of Pragmatism
For the sake of what is deemed “pragmatism,” I have seen the following oversights or missteps in project management.
Testing
Product and system testing shortened to practical elimination justified as a pragmatic action to deliver the product (the project scope) on time.
No Estimates
In the name of pragmatism, we argue for not estimating because management behaves poorly when the estimates are inaccurate. This is a surrender, not a pragmatic solution. This is not to suggest that we should always estimate; some projects – di minimis projects specifically – are good candidates for skipping estimates. Our approach to whether we estimate or not should be predicated on risks and the amount at stake, not whether management is uneducated on the nature of estimates.
Elimination of Configuration Management
Elimination of configuration management is usually attributed to the assertion that “we do not have time for that.” Our team once managed a large test department. One of the suppliers to the system would deliver the product (hardware and software) to integrate into the system. There were multiple iteration deliveries of the supplier’s product, none of which had associated release notes. How do we know what features are included in the instantiation of the product which will inform the test group which system functions can be tested? This is just one example of how important configuration management is to project success.
Pragmatic and Stifling
Furthermore, abusing the term “pragmatic” stifles innovation and creativity within project management. With the word or idea of pragmatic, we discourage critical thinking and exploration of alternative approaches by glorifying the status quo and emphasizing the tried-and-true. True pragmatism should encompass a healthy balance between practicality and forward-thinking, leveraging lessons learned, and identifying risks from the past while embracing opportunities for growth and improvement.
From experience, the word pragmatic is used or abused to enable a quick response, no matter how bad that short response idea may be. The proposed haphazard idea will be disconnected from the present risks and available resources and is often characterized by a hyper-focus on the end, associated with a date.
Let us not forget that project management is an intricate dance between art and science. It requires a delicate balance of technical expertise, strategic thinking, and adaptability. No two projects are alike, for the most part. Even when undertaking the same type of scope, for example, developing a new product or building, there will be plenty of variation. We certainly will be required to adapt to the specific circumstances. Reducing it to a shallow label of “pragmatic” oversimplifies and diminishes the discipline’s complexity. Using the word pragmatic to dump prudent actions that should be undertaken is to embrace failure.
Conflict Can Lead to Innovation and Creativity
Instead of mindlessly using this buzzword, let us strive for a more nuanced understanding of what it means to be genuinely pragmatic in project management. Let us reject the notion of stupidity disguised as pragmatism and embrace a mindset that values excellence, foresight, and innovation. Only then can we truly navigate the challenges and uncertainties of projects with the thoughtfulness and wisdom they deserve.
Conflict, when used constructively, can help uncover innovative ideas and solutions. Using the word “pragmatic” to justify eliminating actions the project should take without considering alternative actions that may achieve the project objectives is the wrong approach. Being pragmatic should not mean eliminating the necessary actions to achieve the project delivery date without understanding and evaluating the consequences of the action. Instead, we should consider alternative solutions.
A Truly Pragmatic Approach
Let’s revisit the issues above and demonstrate a truly pragmatic approach.
Testing
For the testing story above, a pragmatic response would be to plan the testing in quickly delivered increments from the beginning of the product development, with each small iteration being tested on the way to maturity. Not to get dogmatic, but generally speaking, testing should ideally be closely integrated with the development effort rather than at the end.
No Estimates
The project manager and team must educate the management staff, demonstrating a lack of estimates knowledge. The project manager should track the spending throughout the project and the projections at gate reviews, even if the company may not have these formal gate reviews. Connecting the work to the schedule and costs demonstrates why estimates are educated assessments of what it will take to accomplish the project’s objective in the presence of a lack of complete knowledge.
Elimination of Configuration Management
The pragmatic solution for this one is complex, perhaps impossible. We had an answer, but we were unsure how pragmatic it was. We first attempted to convince this captive supplier to provide us with release notes, which proved impossible. We explained why these are required by testers, especially for complex and interconnected vehicle systems. All fell on deaf ears.
Since there were no release notes, defining what should be tested in each iteration was also impossible. The supplier’s product interfaced with every other component on the vehicle with a significant portion of more than 3,000 test cases for the entire system for one of two vehicle platforms. The lack of release notes is part of the configuration management process that ideally will describe each product iteration. This would allow for the prioritization of specific test cases, as we would know the content of the subsystem in each iteration, specifically which features are available in each iteration as the component is delivered for testing. Our final solution was to test everything expected in the entire product, not based on an incremental iteration, and write defect reports for things that did not work. The supplier did not like this solution, as many things identified as defects were functions that the supplier did not yet build. However, the test group had no way of knowing what features were in the product for any iteration. After several loops of testing the system, the supplier began to issue release notes since we had no idea of each product iteration’s content.
Solutions
We should not browbeat team members with the word “pragmatic” as a solution to do bad things. Or, as our friend says, “Do stupid things on purpose.” The decisions we make should not make the situation worse. We may have to accept some risks, but the probability of occurrence and the severity of those risks should be at some acceptable level.
We have recently recorded a chat with Thomas Cagley of SPaMCAST fame. The next episode, 763, will have more on using this word. Listen to the episode here if you’re interested in this discussion, and share your thoughts in the comments below.
More from Value Transformation
Integrating Change Orders in Microsoft Project: A Step by Step Guide
