Recently, on Twitter, I had an occasion to express my discontent for 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 pertaining to a practical point of view or practical considerations
2. Philosophy of or pertaining to pragmatism
3. Of or pertaining to pragmatics
4. Treating historical phenomena with special reference to their causes, antecedent conditions, and results
5. Of or pertaining to the affairs of 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 suggests often the “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 actions that are reckless and irresponsible.

As a specific example, imagine the development of a product to fixed delivery date.  That development work has taken longer than expected; the downstream work will be impacted (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 miss-match of time available to the scope of work may be.  I have witnessed this specific testing implication on numerous occasions, and most of you test folks can likewise attest to that.

If the historical record indicates this sort of 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 the possibility 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 our development throughout the development process.  Small builds, constantly or continuously tested iterations allow us to accomplish both the development and testing objectives, thus giving our team a fighting chance to successfully deliver a quality product.

Consider the situation in which our organization does not have a comprehensive approach to configuration management. We can interject into our project management planning and activities to mitigate or reduce the 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 the word’s 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 not possible.  I do not believe the word pragmatic describes the earlier mentioned reckless and irresponsible behavior – though the word is frequently used in that context.