Pragmatic Project Management

Use and Definitions

I bet all of you have heard the word pragmatic. There is even a book publisher, Pragmatic Bookshelf. You might have heard the word pragmatic used in Agile approaches, but this is not the only use of the word.  I have heard it in conventional projects and while a test engineering and managing testing departments. 

Pragmatic has been around for a while. I found this cool tool that shows the use of the word over time. Not sure how we know the use of the word in 1920s.

Figure 1 Use of Pragmatic over time 1  

I have strong belief in the benefit of a common lexicon for ensuring communication takes place, to have the potential of arriving at an agreed-upon interpretation of the situation. To that end, we start from a common point, we provide a definition from which we can work:2 

  • Of or pertaining to a practical point of view or practical considerations 
  • Philosophy of or pertaining to pragmatism 
  • Of or pertaining to pragmatics 
  • Treating historical phenomena with special reference to their causes, antecedent conditions, and results 
  • Of or pertaining to the affairs of state or community 

The down side

For me the definitions of interest are numbers 1 and 4.  Practical consideration as it pertains specifically to project management and product development. However, have you ever heard the word used in ways that, in no way, fill any of these definitions?

Over the years I have heard the word pragmatic many times, often enough in the throes of some management, product development or project management extremity. From experience, the word can be used, often enough, to propose what is often an indefensible, least prudent solution, or what my dad used to refer to as half-a**ed. 

Funny thing, I thought this was a saying from just my dad (retired Special Forces Vietnam Veteran). Turns out, after talking with my friends and colleagues Tom Cagley, and Jason Newton, their dads used this term in the same context.  I found this interesting, there was a time when we articulated these things more clearly. A time when the language was more direct and less ambiguous, or maybe our dads were just a bit rough around the edges. Or maybe it is just a dad thing. 

Some Examples

Consider a historical example from experience, 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.  In this case, hundreds of test cases. 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 testing situation happens frequently, would it not be prudent and pragmatic to plan our response differently? For example, that test phase activities which are crunched in favor of the launch, our plan should identify actions early enough in the development work to alter the outcome. 

We can choose some metric that allows some ability 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 for delivery, will permit us to adjust our project scope or schedule accordingly. 

Once it appears that date is becoming 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 (testing team) 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.   

Project management and testing are not the only areas where the word pragmatic is employed as a bludgeon. From experience, configuration management is another example. There are times when perhaps our organization’s configuration management process is too heavy for a project that is to deliver a product.  That does not mean abandon, or at least it may not. 

A pragmatic approach will focus on what matters for this effort and tailor fit a process accordingly.

Yet, we have seen pragmatic, once deployed to cajole the team to accept what should not be accepted. 

Summary

Generally, when you hear the word pragmatic, skepticism and a plethora of questions should come to mind. Truly pragmatic solutions may not be welcome. Rather, the word is used as a 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. 

Of course, there are broken plays, where things are not going according to our plans, or when we must adapt on the fly. Words have meaning. Conflict should be used, as much as possible, in a positive approach, that is to find a pragmatic solution that will meet the needs. The word pragmatic should not be political speak, double speak, or coercion.  We call it coercion because these solutions, from experience, are remedial. It allows us to hang a sign around team-members necks that reads – not a team player. 

The word gives us the rationale to act quickly, imprudently, irresponsibly, and recklessly. We submit that these faux pragmatic solutions are a significant reason for technical debt.  My disagreement with the word pragmatic is in the misapplication.

1 https://books.google.com/ngrams/graph?content=pragmatic&year_start=1800&year_end=2019&corpus=28&smoothing=3

2  https://www.dictionary.com/browse/pragmatic