The Holy Grail of Project Management Process and Methodology

I recently did some consulting for a high-tech division of a very large company (I'm under NDA, so that's as much description as I can give). The focus was on providing a base level of project management training while getting an idea of the unique project management challanges they face.

During a roundtable discussion during lunch, I was able to hear from the division's VP, key operations exces and managers, and product development staff, marketing staff and engineers. While the issues were framed in the context of their specific environment, the essential problems are ones I (and probably you) have observed and experienced throughout my project management practice and teaching career.

The senior managers responsible for delivering projects want project management processes applied to ensure successful project delivery and to provide accurate status reporting on projects. Those managing the projects really want to do this for themselves as well as for their bosses.

Senior executives want this information and want their organization to efficiently deliver projects.

But... No one wants to do any extra work to develop and execute on project management process... because, see, we have all these projects. And, the operations/production people, while seeing the value of project management, also see themselves as tough, pragmatic managers who choose not to add project management "overhead" to their jobs of getting products manufactured and process improvements in place. You know, getting real work done.

What's a project management advocate to do? If everyone acknowlwedges the need and value of project management to helping the organization deliver projects more efficiently, but everyone is too busy to execute project management, how do you get out of this loop? How do you win over the operations types who feel that project management does not add value to cranking out widgets?

The Holy Grail: Figuring out how to bring the most impactful, valuable components of project management to the organization while focusing on suppressing work perceived as overhead to make it happen. Some of the high-value examples are so simple, basic, yet meet with resistance.

My favorite is the tracking of actual versus estimated hours used on project tasks by human resources. There is no more important metric to track than resource actuals. The additional metrics and reporting this step enables both tactically and strategically are legion, yet this basic project management function meets with tremendous resistance, even in some organizations that are doing many other standardized and robust PM practices. Why?

This step is, depending on the organization:
Perceived as extra work, considered too detailed or granular, labeled as "big brother is watching", and more...

In one project management class I was teaching a few years back, a participant said something along the lines of not being able to ask "professional people" to account for their time. I collapsed with disbelief and laughter. My first question was "you are paying these people, right?" Seriously, in this day and age no one collecting a paycheck should be questioning efforts to understand how their time is spent, especially in the context of getting better at projects.

This is just one example of many components of project management that could provide incredible value to organizations but meet with resistance because of perceived difficulty to implement or perception of overhead. Champions of project management must find that elusive Holy Grail - that balance of value versus detail and process.

With tracking actual resource hours, the project management advocate must: (1) find a cheap and easy tool to use (2) figure out the largest increment of time to track that will still add value to the project management process (3) sell this as a way to track projects and help build the organization's database of estimating resources, and certainly not an effort to see how people spend their time.

Another great example is the project charter. This is one of the most important documents in all of project management practice. Yet, it is surprising how many projects get launched in organizations of all types and sizes without a single, simple document that captures who launched the project, why it was launched and what it is supposed to achieve. The project charter is another low effort, high-value step in adopting basic project management practices.

Simply documenting why a project was launched, who is responsilbe for paying for it, managing it, and tracking how much time has been spent on it are low effort, high-value project management tools that will pay dividends fast. The important thing with the charter is to keep it brief and simple. 2 - 3 pages is enough detail to document what is supposed to be delivered, how, when, by whom, etc, but not so much that anyone can claim that it is too much overhead to write it.

Are these two examples the Holy Grail of project management? No... but you can make a strong business case against anyone who thinks it is overhead that doesn't add value by showing how little effort it could take to put these couple of basic items in place. That's the Holy Grail - high-impact, low-overheard project management process improvements that help the organization, improve the perception of project management, and, in the words of John Belushi in Animal House, "don't cost nuthin."