Lifting the Hood on Project Management: Tweak, Tune & Tailor 

Mark Mullaly - May 16, 2016 

How do you think about your approach to project management? Is it something well defined and fixed? Is it evolving and flexible? Is it mystical and incomprehensible? Or is it so innate and ingrained that you don’t even think about it? It’s an important question to consider, and one we don’t necessarily explore very often.

For those of us in organizations that are considered “mature,” our view of how we manage our projects may be far less about ourselves and far more about conformance to organizational expectations. Managing projects in such an environment has very little to do with personal beliefs, views, approaches or practices. The goal of organizational consistency sets the expectations that everyone will use the same process in the same way, and the results should be interchangeable regardless of project manager. In fact, many organizations signify a key benefit of such an approach being that one project manager can step in for another without missing a beat.

Accidental project managers, by contrast, don’t necessarily appreciate that there is a process to follow. We get by as best we can with the tools and resources at hand, and as we know better we do better. Managing projects as accidental project managers is much less about process and more about treading water as fast as we can, trying desperately to keep our head above water. It’s exhausting work, but sometimes very rewarding all the same because of it. When we succeed, we can say that we got there on our own speed (even if outside observers might opine that it didn’t have to be quite so hard).

New project managers, blessed as they are with shiny course certificates or newly minted certifications, probably think most about process. But they will often also think very rigidly about it. The perception is that there is one—and only one—way to do things. Particularly for the newly certified, who have invested considerable effort in studying the materials they are to be tested on, there is often a great deal of identity and ego wrapped up in demonstrating competence in the processes and approaches they have internalized through hard-won effort. The result is a considerable level of rigidity, structure and conformity with what has been defined.

We can also see this rigidity in how standards have evolved over time. Or more to the point, how they haven’t. It’s been a (long) while since I attained my certification, and it’s arguably got a little tarnish on it (some might say a great deal). Back then, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) was still in version 1.1, and weighed in at something less than 100 pages. Today, the sixth version is being contemplated and the document weighs in at more than 600 pages.

Despite the significant growth in page size, however, the essential structure is the same. Sure, we have a new knowledge area now, and a dabbling of processes have come and gone. We’ve spent years quibbling over terminology, certainly. But the core essence of PMBOK® Guide is the same as it has been for the last 30 years.

That’s not to say that there isn’t value in the standards. That’s not even to say that consistency can’t be useful and helpful at times. But we need to exercise judgment and relevance in how we think about our processes, and the degree to which they are—in a given situation—helpful, harmful or irrelevant.

One of the most important ideas in PMBOK® Guide comes very early in the document—in the introduction, in fact—and yet I am entirely convinced that most people have not read it, and even where they have, they have not fully taken on board its implications. In describing PMBOK® Guide as reflecting good practice, the document identifies:

“‘Good practice’ does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project.” (PMBOK^® Guide—Fifth Edition, p. 2).
In other words, even where practices may be appropriate for most projects most of the time, they are not going to be relevant or helpful for all projects all of the time. As was clearly identified in the global Value of Project Management research project, there is no one way to manage projects, and there is no one reason that organizations choose to implement project management. There are many different drivers, and appropriate practice depends very much on what we are trying to accomplish.

Determining what we need to do is a judgment call. We need to think hard about what we are trying to do, the context and culture of the organization that we are operating in and what is actually going to be appropriate, relevant and helpful. There will be a core basis of what is useful, and we are going to need to scale that up or down as appropriate.

The challenge is what determines “appropriate.” Certainly, the size and type of the project will be a factor. So will its complexity and the level of uncertainty associated with what we are trying to do and what the outcome looks like. The skill and expertise of our team will have an influence, as will the expectations of our sponsors, customers and stakeholders. All of these factors need to be taken into consideration in a delicate balancing act of figuring out what makes sense, what is reasonable, what is relevant and what is possible.

My own experience is illustrative here. Like many, I started my career as an accidental project manager, working to figure things out as I went along. I’ve also wrestled with trying to apply practices that I thought would work—if only because they did last time—only to come to terms with the fact that at times I was hammering a square peg into a round hole. I’ve done my time being constrained by someone else’s project management practices, and I will plead guilty to inflicting project management practices on others.

Managing a project today, I have a core set of practices that represents how I approach my role. Most of what I do is certainly going to be recognizable to anyone familiar with managing projects, although it has my own spin and interpretation. Some things I am rigorous about, some areas I cut corners on and whole other practices I ignore. I develop schedules, estimate resource effort and build budgets, but how I do that at times draws on experience and intuition as much as it does codified practice.

The implication in this is that while I could teach someone what I do, and provide guidance on how to be able to apply my approach, part of doing that would have to involve codifying and making explicit what for me is relatively fluid. And that’s one of the key problems in striving for consistency, in defining process and in developing standards: The act of externalizing process often makes it appear more formal and rigid than it actually is (or should be). To explain something, we draw boxes around ideas and make clear connections between them. In reality, though, the boundaries may be quite fuzzy and the connections far less tangible than we make them appear.

The other challenge is in how we make visible the work that we do to others. Again, I have my own essential process that I adapt as warranted to the task at hand. While that gives me a level of comfort and confidence in what I am doing, that same level of assurance isn’t necessarily felt by others. Here as well, we need to make adjustments.

This was illustrated very well a few years ago. I was managing what for me was a very straightforward project. I knew the process, was extremely confident in the work to be done and had a solid handle on the estimates, risks and issues. Managing a project like that can be pretty lean; much of the information that I need can be documented on one sheet of paper, by hand, and provide me with all of the control that I need.

At the same time, the customer I was working for had enormously rigorous expectations regarding how any of their projects were managed. Their status report template ran to eight pages (empty), it implicitly required the use of earned value in order to complete, and expected the same information to be displayed from three different perspectives.

Conforming to the management expectations of this customer required far greater level of formality—and visibility—than either I am used to, or the project warranted. Fighting that point, however, was useless. I needed to ramp up considerably not only the process I used to manage the project, but also the visibility of that process to the client.

Shortly after that, however, I was managing a similar project for a different client who had no such rigor. Their entire organizational approach could best be described as “accidental.” Worse, they had an active mistrust of the idea of project management, having experienced in their recent past several instances where project managers tried to impose on them what they perceived as bureaucracy, forms and unnecessary paperwork. That didn’t change what I did, per se; I still used my process to define and manage the work at a level that gave me confidence in our ability to deliver. But I made far less of that process visible. The fact that I was on top of things and delivering successfully was, to all outward appearances, a product of personal diligence and talent, not any underlying process.

There is no single, uniform way to manage projects, nor should there be. Projects are by their nature unique. We need to evolve unique strategies to deliver them; some of those strategies may be rooted in what is familiar, while others may require more creativity and innovation to develop.

It was a willingness to innovate and adapt that led to the formative definition of project management as we understand it today, and our success in the future will depend upon our willingness to continue to evolve and experiment. We need to not think of project management as a black box that cannot be touched or changed. Instead, we need to be willing to lift up the hood, roll up our sleeves and get our hands dirty tinkering with it until it works the way we need it to.

You can find this article and many others at www.projectmanagement.com.

About the Author

Mark Mullaly is president of Interthink Consulting Incorporated, an organizational development and change firm specializing in the creation of effective organizational project management solutions. Since 1990, it has worked with companies throughout North America to develop, enhance and implement effective project management tools, processes, structures and capabilities. Mark was most recently co-lead investigator of the Value of Project Management research project sponsored by PMI. You can read more of his writing at markmullaly.com