I often wonder how many of us use the term “pragmatism” with its original intent. A quick look at the dictionary describes pragmatism as “an approach that assesses the truth of meaning of theories or beliefs in terms of the success of their practical application”. That is a mouthful, but maybe I can try to distill this down to how I best understand pragmatism – that is to make the best with what you’ve been given. And, to make good choices about how you should solve a problem that leads to the best possible outcomes.
In most cases project managers must be provided with what is needed to deliver value for the organization. Yes, we bring the subject matter expertise to organize work, build and maintain high-performing teams, and ensure the deliverables are integrated with the strategic goals and support objectives for the organization. However, we are dependent on the organization at large to provide the resources, strategic goals, processes, controls, and high-level direction on what the project should deliver.
Therefore we must take whatever is provided and make it all work together for the good of the project and to make sure we are meeting those goals and objectives as stated by the organization. We don’t have the authority, in most cases, to swap out resources that aren’t aligned to the objectives (namely people) or procure whatever we see as needed to meet those objectives. The schedule pressures are often acute, the resources split between multiple priorities, authority rests elsewhere, and the problem domain unique. Do you need to be a MacGyver to be a Project Manager!?
Instead, project management is primarily focused on aligning what we have been provided. Through our leadership and planning skills, we ensure the team is operating in as high performing a capacity as possible given the circumstances. This requires us to practically apply the practices, methodologies, life cycles, and organizational resources to get the best outcome possible.
The concept of pragmatism is underscored by the PMI’s PMBOK®v7 shift away from processes to principles. This may seem like a watershed moment in project management—what do you mean we don’t follow a set of processes!? Of course we will, but this is a natural evolution away from prescription to pragmatism in setting the standard for how projects are to be managed. In previous versions the emphasis has been on tailoring the processes; in fact, students of the field know that the PMBOK® hasn’t prescribed a particular delivery lifecycle going all the way back to version 3 which was current in the early 2000s. This pragmatism can be described as falling into three areas: our processes, our teams, and our deliverables.
Pragmatic with our processes. Processes are prescriptive by their nature. Prescription in the way we deliver, then, is not a bad thing; however, uniform prescription applied to every circumstance is a bad idea. In other words, there is not one set of best practices that can be employed in every project, but rather a set of good practices that can be selected to be employed only as appropriate. The larger the set of good practices to choose from, the better.
Let’s take a closer look at a typical Agile implementation. We are taught to make Agile first and foremost a mindset that rests on the four paired values, described by twelve principles that lead to an infinite set of practices. However, outside of the typical set of practices, such as Kanban, product backlog, three roles, daily standups, planning days, and retrospectives, there are actually very few that are implemented, much less imagined. If you add to this that the shift to Agile is typically mandated top-down with management directing the transformation, Agile has become in reality quite prescriptive. Not exactly what the founders envisioned!
A mechanic will always want to gather and learn more tools because they find themselves in situations where there isn’t the right tool in their toolbox. Likewise, project managers are always looking for a better way to achieve quality deliverables given the circumstance. The uniqueness of projects requires this; there is always something new that our project teams are encountering. This is what makes project management so appealing to those of us who have chosen to pursue this profession to the exclusion of all others – there’s always something to learn about a better way to get things done.
That is not to say that project controls are optional. For the controlling PMO who is entrusted by the organization to ensure the resources of the organization are being applied as per the regulatory requirements and internal policies, pragmatism can sound threatening. There may be a perception that by not following a script in your project execution a control point would be missed. This misses a key concept of controls—that the focus is on making the right decisions with regard to scope, schedule, and cost rather than following the right processes. In fact, we can start our discussion on project controls with the right decision, pragmatically speaking, on which processes or practices we should choose to implement due to the unique circumstances that are characteristic of every project.
What is great about Disciplined Agile is that there is a framework available for us to choose how we deliver based on the orientations of six different lifecycles, which lead through a decision tree to the appropriate practices we can then choose to deliver. This allows for a more confident, team-led approach that allows the decisions to be made in a logical way, and doesn’t lead to a prescriptive approach for anything other than the project you are currently delivering.
Pragmatic with our teams. Project managers influence without authority in almost every situation. There are several reasons why a project manager has to operate without authority, but the primary reason is that project delivery is typically subordinate to operations support as a priority for the organization, as is typical in an organization’s IT department, for example. Since authority follows priority the project manager is often subordinate from that perspective.
So, we are given the resources to deliver, but often those resources are incomplete for everything we need. We often find the resources are lacking not only in allocation and focus on project priorities but also lacking in the skillsets – both in teaming and technical skills – needed to effectively deliver given the constraints set by sponsorship.
To illustrate this point, let me share an experience that may be one of the more drastic that I’ve personally encountered. The project I was given was to enable an existing application on a new technology platform. For those of you who have encountered this before, you know this means there are likely several areas of technical risk, and you really don’t know what may be impacted until you begin applying the code to the new technology. Anything that was created with custom code is suspect and has a high probability of requiring rework.
In order to deliver this project I was told by the support manager there was one resource who was imperative to the project. This person was a highly skilled resource who literally knew everything about the application. In fact, this person was part of the original development team when the application was first created and was of high value to the organization since he could easily troubleshoot problems and come up with a solution that required no one else’s involvement.
But therein lies the problem – the person can do everything themselves: in other words, without any team interactions. The value of this person’s contribution was in no way associated with their ability to be an effective team member,so they were not an effective team member; it’s not how they were valued by the organization.
Not only that, but the resource manager gave me direction to ensure this resource committed to sharing their knowledge with the other team members. Surely that shouldn’t be a problem, should it? Well, it definitely was a problem. This person’s team behaviors were rude, abrasive, insulting, condescending, and created such relationship problems people were wanting to quit the team.We even had situations with team members leaving meetings due to the inappropriate behavior.
As a project manager, what am I to do? If I escalate, I’m only engaging the same management that is enabling the behavior, and which values individual contribution over team behaviors. Can we still deliver without this person’s skills? Not in this case; there is too much risk in the technology upgrade to ask a less-experienced team, starved of the knowledge this resource has been holding onto that would have resolved this very dilemma. Is a high-performing team achievable in this situation?
What I elected to do was to talk to this highly skilled and experience team member to lay out a plan by which we would not have them attend our working sessions, but would come to them with specific tasks we would like completed. In addition, I would pass on questions the other team members have and simply asked that they respond to those questions as soon as he had the answer. This was agreeable as this team member valued most highly not being in meetings at all. In fact, he thought this was a great solution and we went on to deliver the project objectives, with customer satisfaction, and even with a fair amount of knowledge transfer.
Were we as high-performing a team as we could have been? It would certainly have been much simpler and more effective if the highly skilled person were as skilled at being a team member as they were in the application and technology. But given the circumstances, that team was as high performing as it was going to be, the project was delivered, and the customer was happy.
In this way the project manager can be pragmatic with the team, getting the best team we can put together with what we’re given as resources to deliver. This often requires pragmatism, using what we’ve been provided to bring the right resources to bear on the project deliverables.
Pragmatic with our deliverables. Speaking of deliverables, we can also apply pragmatism to what we are delivering as a project team. Again, the circumstances will dictate what the best outcome would be, but what’s really interesting about circumstances is that … well … they change!
There can be a big difference between delivering something to specifications and delivering outcomes that are acceptable. If the product requires a high degree of conformity to specifications, then acceptable outcomes are certainly only achieved when that occurs. However, in many software projects a high degree of conformity to specifications is not really necessary for the customer to be happy with the product. Often, we hear things like, “I’ll know what I want when I see it.” This subjective quality to the deliverable is what provided the impetus for Agile in the first place.
The subjective component to quality in software projects is influenced by two dynamics, the first being the functional and the second being that of change. In the functional aspect, the deliverable that is most valued is the one that works the best. We may have arrived at what works best through several iterations, but that is all part of the learning and collaborative experience. Secondly, businesses themselves are dynamically changing, both in minor ways – shifts in priority for various reasons – or in major ways – a new business transaction or even COVID reasons.
To illustrate this further, the project may be delivering a design for a rocket or space-based vehicle. Identifying and adhering to exacting specifications is paramount, and to deliver anything falling short would be unacceptable. However, delivering a new mobile app would only need to adhere to the required specifications of the operating systems of the intended devices. The way it works, in other words, how it functions, can only be attained through customer acceptance once demonstrated. Agile works best in the latter since we need regular feedback to ensure we are attuned to the subjective quality in the eyes of the user.
All of this requires a pragmatic approach. Choosing from a large set of practices that we have available in our toolbox allows the team, the project manager, and management to stay aligned not only on the project objectives, but also on how these objectives will be met.
This concept of pragmatism is a significant part of how we came to be as Projects by Design. What we mean by the name of our company is the project delivery approach can and should be designed appropriately for the circumstance. We can design, by choosing the best set of practices for that situation, the most effective means of ensuring the deliverables result in a high degree of satisfaction while ensuring required project controls are satisfied!