Conflict with “Pragmatic”

Recently, on Twitter, I had to express my discontent with the word Pragmatic.  My spontaneous outburst so amazed me that I decided to explore this further.  The definition on dictionary.com[1] is:

1. Of or about a practical point of view or practical considerations
2. Philosophy of or about pragmatism
3. Of or about pragmatics
4. Treating historical phenomena with special reference to their causes, antecedent conditions, and results
5. Of or about the affairs of the state or community

For me the definitions of interest are numbers 1 and 4.  Practical consideration as it pertains specifically to project management and product development.  Too often this seems to be an excuse for our altering what should happen to what can be made to happen.  My experience often suggests that “what can be made to happen” is entirely inadequate or, as my dad used to say, “half-assed.”  Observation suggests this is one of the reasons for poor product quality.  In the name of pragmatism, we justify taking reckless and irresponsible actions.

Example

For example, consider developing a product to a fixed delivery date.  That development work has taken longer than expected; the downstream work will be affected (due to dependencies).  For whatever reason, our launch date remains the same.  To say our next set of work (perhaps testing) will delay the launch is unacceptable.  Whip out our pragmatic crowbar, “do what you can in the few hours you have”, no matter how ridiculous the mismatch of time available to the scope of work may be.  I have witnessed this specific testing implication numerous times, and most of you test folks can likewise attest to that.

If the historical record indicates this situation happens frequently, would it not be prudent and pragmatic to plan our response differently?  For example, knowing the above situation happens frequently, that test phase activities are routinely crunched in favor of the launch, our plan should identify actions early enough in the development work to alter the outcome.  For example, choose some metric that allows us to prognosticate the probable completion date of the prior items in our dependency chain.  Knowing the gap between our desired or wished date and probable date will permit us to adjust our project scope or schedule accordingly.  Once it looks like that date is compromised, we reduce the scope of the development work or add resources (last resort) to ensure we make the date of delivery to the downstream dependency.  A second pragmatic solution could be to integrate our testing with development throughout the process.  Small builds and continuously tested iterations allow us to accomplish both development and testing objectives, giving our team a better chance to deliver a quality product successfully.

Consider the situation where our organization lacks a comprehensive approach to configuration management. We can integrate these into our project management planning and activities to mitigate or reduce risk.

Generally, these pragmatic solutions are not attempted.  Rather, we use the battering ram “you are not being pragmatic” and trash any rational approach as “being by the book” as if a textbook execution is synonymous with mythical or inadequate. In football, by way of comparison, textbook execution is usually referred to in a positive light.

My disagreement with the word was perhaps a mistake. My real disagreement is its use in coercion or as doublespeak (political speak, management spin, etc.). I call it coercion because, in the sense we are accepting that which probably should not be accepted—a remedial and reckless solution—and as such, you are not being a “team player.”

I agree with this definition. Practical considerations are necessary as aspiring to the ideal is difficult and often seems impossible. However, I do not believe the word pragmatic describes the earlier-mentioned reckless and irresponsible behavior, though the word is frequently used in that context.