If best practices aren’t, then just what is the point of process, practices and standards? And for extra bonus points, if we are using them wrong right now, then just how are we supposed to use them?
Excellent questions. I’m so glad that you asked. They’re questions that I’ve been reflecting on a while (if you squint some, you could argue that those questions have been the focus of my entire career).
There has been a great deal invested in developing methodologies and process guidelines (defined correctly, methodology is actually the study of methods and process, but we’ve amusingly turned it into its very own noun). I started my career when the development and implementation of methodology was enjoying something of a heyday. The 1990s were particularly fertile ground for this, and I remember working on frameworks for systems development, change management and project management (and sometimes all of the above, at the exact same time).
Standards started to hit the radar around this time as well. A lot of this, at least in my orbit, centred around the introduction and adoption of the ISO 9000 quality management standards. This was a time when total quality management was enjoying its last resurgence (before statistical process control got rebranded as Six Sigma, and defect tracking and control charts got all sexy again).
What predominated in all of these efforts was a focus and emphasis on “this is how you are supposed to do things.” In organizations, it was about codifying consistent ways of working. This would give people doing similar work a common terminology, an acknowledged framework and a measure of consistency. People could move from team to team and project to project, and there shouldn’t be a need to reinvent the process of how the next activities should work.
When it came to standards, the bar got raised a good deal more. The implicit expectation was a focus on “this is how everyone should do things.” That’s a noble effort, and there is value in it that is important to acknowledge. Electrical standards, for example, are what allow us to go out and buy new technology, and take it home and play with it without first risking electrocution as we wire it into the power grid. More valuably, they are what also guide making sure that the wiring in our houses is safe, and less likely to burn to the ground.
Your ability to replace a spark plug in your car (and just about every other component) is because of standards. The fact that the internet exists is also because of standards. Not to mention the ability to wander around with days of music on your phone, to make a call on that phone and successfully reach the person you intend, or just to binge-watch Netflix. Even the bottle of wine that accompanies said session on the couch is subject to standards and regulation, which means that it’s probably more or less safe to consume.
Much of the success of the modern world we owe to the fact that we have more-or-less agreed to how things work, and those agreements are more-or-less international. There are stubborn and notable exceptions (which is why you need different power adapters in Europe than in the UK than in North America). For the most part, however, the world has become a better or at least easier-to-navigate place as a consequence of standards.
When that comes to things like project management, or systems development, or even quality management, is there the same requirement? Do we really need an international standard for project management (for yes, Virginia, there really is one)? For that matter, do we need an American standard for project management (for there is one of those, also, and we call it the Guide to the PMBOK). And what benefit do these actually provide?
This would be about the point in the conversation where “best practices” once again rear their ugly heads. The development of particular of standards is theoretically encoding the absolutely best way of getting things done. This begs the question of what defines best, and who gets to decide, but it’s important to recognize that this is the theoretical conversation going on when standards are established. Also, it’s important to note that the critical word in that last sentence was, “theoretical.” In a world defined by complexity and variation, by the time we get to something as involved, nuanced and political as project management, the likely emergence of a “best” way to do anything is laughable (see my screed of last week for an expansion on these thoughts).
As evidence to support this point, I’m going to once again pick on project management, because it is an area where I have both experience and the research to back me up. A really useful exercise is to look at something like a standard, and ask the question, “does anyone actually do it that way?” And in case of project management, that answer would be a resounding, “no.” We might do things that are similar to what is described in the PMBOK guide. Some things, like risk metrics or Gantt charts, might be familiar. Other things, like project plans and status reports, will be vastly divergent and immensely varying in detail, structure and meaning.
The manager of the PMO for a client I did some consulting for was of the considered opinion that there was, in fact, one best way to do a project plan. He also repeatedly lamented that he had never actually seen a perfect example. This is perhaps unsurprising, in that his view of “best” in this context was the production of a project management plan, and every other plan management plan, as defined in the good book of the PMBOK. It may be evident that he had never worked as a project manager, and his intuiting of what constituted “best” in this instance was indeed theoretical in nature. His views are not completely unique, however, and there are many others who hold the PMBOK out as the “right” way to do projects.
The fact that there isn’t sufficient information, guidance, coherence or structure to actually manage a project by following the Guide to the PMBOK is certainly one argument to be made here. The other is that if you were attempt to, you would literally die trying. You would invest weeks and months in the creation of the aforementioned management plans, without an iota of progress towards delivering the goals of the project.
When we get down to an organizational level, however, the variation of practices goes off the charts. While project management frameworks and methodologies theoretically define expectations for how projects in the organization are supposed to be delivered, they are simply not followed, sometimes to an astonishing degree. Every project is different, every project team is different, and every project manager has a different interpretation of what should be done, and varying views on whether the organizational practices are in any way helpful.
An example I have used in several articles is the organization I assessed that had an ISO 9000-certified project management process. Theoretically (there’s that word again) every project manager did the same thing the same way. The hallmark of an ISO 9000 quality process, after all, is “say what you do, and do what you say.” And you have an annual audit as an expectation of accountability to verify that what is stated actually occurs. Despite this, the project managers in no way followed the process. Compliance was a month-long free-for-all as project managers caught up on all of the paperwork that they were supposed to have produced as a matter of course. They valued autonomy and reaction, wore their responsiveness and need to be at their clients’ beck-and-call as badges of honour, and pretty much disdained the value of planning anything.
This example is an extreme one, but it serves a point. I’ve been involved in assessing the practices of organizations from around the world for decades. I’ve got data on about 650 organizations. A significant finding in every single assessment that I have done is that consistency is problematic, to varying degrees. I know by name two organizations in the world that I would style as employing a remarkable amount of consistency in their projects; they are huge, formal, and invest significant time and effort in measuring up to that standard. For most organizations, the value of getting there would be dwarfed by the ridiculous amount of cost and effort to even try.
It would be easy to look on the lack of consistency as a problem to be solved. Before we leap to that conclusion, it is helpful to examine the point of consistency is in the first place. Ideally, having consistency means a shared understanding of how things get done: there is common language, aligned perspective, familiar structure and some interchangeability of projects, people and tasks to be performed. One project manager should be able to step in for another one, and keep the project moving forward. That is a surprisingly hard thing to achieve in practice; most transitions during a period of vacation or illness wind up with the project in caretaker mode, with many of the significant decisions deferred until the “real” project manager returns. Being able to step in and assume responsibility requires not just consistency of process, but a high level of proficiency of the project manager and awareness of the project.
A different viewpoint of inconsistency is that it emerges in response to variations in what needs to be done. This, I would argue, is the central role of process. But it’s not the role of one process, it’s the role of many. The measure of good management isn’t that there is one best way of getting things done, and everyone follows that approach rigidly. Good management is about being able to respond in an appropriate and situationally responsive manner to whatever challenge reality places in our path.
At this point in my career, I don’t have anything that looks like a consistent way of building project plans, strategic plans or business cases. I know a lot of ways that they can be built, and I have a variety of techniques that can be employed. I have umpteen different ways of facilitating the conversations that lead up to the plans, structuring the actual plans and working through the process of putting them all together. I also have an astonishing array of different software packages to pick and choose from in putting it all together.
That I have choices and options from which to select is not—mostly—a product of whim. While I will admit to occasionally doing something in a particular way simply because I can, that tends to be on the projects that I do for myself, for the benefit of my own amusement. When working with clients, the range of options available serves a deliberate and specific role. I’m able to adapt to the situation, usually knowing that I’ve got techniques that I can draw on—or at least adapt—to deal with the specifics of the situation.
What drives the selection of any particular technique might be a product of the specific technical challenge I’m dealing with. That happens, but less frequently than you might think. What usually drives that choice is what will work in the context of the situation I’m working in. What frames that situation most directly is the culture of the client, the politics involved, their familiarity and comfort level with process and their appetite and willingness to work in a structured manner. Where a client is more formal, process-based and rigid in their practices, I will draw on one set of techniques and practices. For the more informal, the more free-flowing or the less structured clients, other approaches will come to the fore. There is no right way of working as independent and abstract concept; there is only what is right for the particular situation I find myself in.
The array of options we optimally employ are a far cry from “best” practices. Sometimes, they don’t even count as “better” practices. They are simply options in a crowd, each with some advantages and some drawbacks. Choice and utilization is always a delicate balancing of reading the situation, weighing the circumstances and figuring out how to maximize the upside while managing potential consequences. There are days that happens more successfully, and there are days that you need to course correct more rapidly than others.
“Trust the process” is an incredibly useful invocation. That trust comes from knowing that even in the face of uncertainty, you have a way of working through complexities, choices and unknowns. “Trust that you have process” is even more useful here. Knowing the processes available to you, and where, when and with whom they are more likely to be successful, is where the magic really starts to emerge. That magic is still a lot more art and a lot less formal structure than many would like to think is true.