Understanding Project Management Processes and Practices

Every effective project management process and CPIM must consider two aspects of project management: its process and its practice.

The Project Management Process

First, there is the project management process itself, which answers the following questions:

• How was it developed?
• How complete is it?
• How is it documented?
• How is it supported?
• How is it updated?

The answers to all five of these questions are critical to the quality of the project management process. I want to take a quick look at each one of these questions.

How Was It Developed?

There are two common approaches to developing a project management process: do it yourself or commission a task force to do it. The first approach is unacceptable. You may be the best project manager your organization has ever had, but if you develop the project management process in the back room and deploy it to the organization like Venus on the half-shell, don't expect a broad base of endorsement. It's the “not invented here” syndrome.

The second approach is the only one that makes sense to me. The task force should consist of representatives from each of the constituencies that will use the project management process. The constituency group should include each class of project managers and business analysts as well as any relevant resource managers. The PSO should provide the task force manager.

How Complete Is It?

Every PMLC model should include tools, templates, and processes from which the project manager can select what works for him or her. The specific characteristics of the project should guide in that selection. Experience and feedback on its use are a good measure of completeness. If the project teams are force-fitting or using their own stuff, that's a good sign that the project management process is not complete.

How Is It Documented?

About 20 years ago, one of my clients had just completed the documentation of their new project management process and asked me if I would review it for them. I agreed. They escorted me into a room that had one long table and a chair. On the table was a set of manuals that extended to about 10 linear feet. My review was very short. I told them that if they expected anyone to actually use this, they had better find some other way of packaging it.

At the other end of the spectrum, another client had built a website to house the documentation. It consisted of three levels of detail: executive, reference, and tutorial. The executive level was usually a one-page, intuitive graphic with links to the reference level. The reference level consisted of a few graphics with one or two pages of descriptive information with links to the tutorial level. The tutorial level consisted of detailed instructions on how to use the tool, template, or process. At this level, the best-practices library was housed. The user could drill down to their level of interest and have only what they needed displayed on the screen. That worked!

How Is It Supported?

Training (online and instructor-led), coaching, and mentoring should be available, especially with respect to the process changes.

How Is It Updated?

The PSO should be the steward of the PMLC model process documentation. Through project reviews and other feedback from the team and the client, the PSO gathers ideas and suggestions for improvements. These should be reviewed by the task force, and revisions written as appropriate. At regular intervals (initially quarterly and later semi-annual) updates should be published.

The Practice of the Project Management Process

Second, there is the practice of the project management process, which answers the following questions:

• Are all project managers required to use the process?
• Can project managers substitute other tools, templates, and processes as they deem appropriate?
• Is there a way to incorporate best practices into the practice of the project management process?
• How are project managers monitored for compliance?
• How are corrective action steps taken to correct for noncompliance?
• How are project manager practices monitored for best practices?

Again, I want to take a quick look at each one of these questions.

Are All Project Managers Required to Use the Process?

The best project management process ever developed is of no use if only a few project teams are using it. If the PMLC model process was developed correctly and is stable, complete, and supported, this is a reasonable prerequisite for its use. The more successful implementations I have seen allow the project manager to deviate from the documented tool, template, or process if the nature of the project is such that that deviation makes sense. In such cases, the project manager simply needs to document that they are not using it and why. There may be occasions where modification makes sense. Again they should document the change and why it was made. This documentation should be archived in a best practices file.

Can Project Managers Substitute Other Tools, Templates, and Processes as They Deem Appropriate?

There will be some tools, templates, and processes that are required because they are needed elsewhere in the organization — a Project Overview Statement (POS), for example. I have a client whose PMLC model consists of 43 processes, of which only 13 are required. The remaining 30 processes are optional. If any of the 13 required processes are not used or changed, the reason must be documented.

Is There a Way to Incorporate Best Practices into the Practice of the Project Management Process?

If the toolkit for your PMLC model documentation is complete, there should be no reason for this deviation. However, allowing the possibility that a new employee brings a better mousetrap, you should allow this deviation. Again, justification is needed. In the case of a tool, template, or process that is new to the organization, some documentation of it should be required. That allows the task force or PSO to vet it for possible inclusion.

How Are Project Managers Monitored for Compliance?

The project review is the best opportunity to formally review compliance. These reviews should be scheduled quarterly or at significant milestones. If there is evidence of noncompliance, corrective action steps can be suggested and the status of those corrective action steps checked at the next project review. Some observations on compliance might be made informally during mentoring or coaching sessions with the team, followed by more formal suggestions by the project review board.

How Are Corrective Action Steps Taken to Correct for Noncompliance?

At project reviews, specific corrective action steps are directed to the project manager. It is expected that the project manager will be compliant at the next project review. These are serious situations and should be treated very formally. Continued noncompliance is a serious infraction.

How Are Project Manager Practices Monitored for Best Practices?

If a project manager believes his or her tool, template, or process is better than what is in the toolkit, it won't be secret for very long. This project manager will tell his or her colleagues, who will try it out and then tell their colleagues, and so on — that is, as long as it is clear that they are welcome to suggest improved approaches. If the PSO has created an environment where deviations are not tolerated, best practices may never see the light of day.

The answers to all six of the preceding questions are critical to attaining and maintaining the quality of the practice of the project management process.

Process and practice interact in several ways to create a complex network of dependent issues to be considered in any quality improvement program. For example, the project review data may show that project managers are practicing project management at a level of maturity below that of the process maturity. There are several reasons why that may be the case. For example, the training program may be weak and not available to very many project managers, or the project managers do not feel that the process meets their needs, so they continue to use their own tools and templates.

The reverse situation is also possible. Consider the case where project managers are performing at a maturity level above that of the process. That's not really as strange as it might seem. I have encountered this situation in many client engagements. The project managers might have brought with them tools, templates, and processes that are much better for their client than those documented in their organization's project management process. I would expect that the process, however it might be documented, allows the project manager the freedom to do what makes the most sense for their project and their client. This does not mean rigid conformance to a process, but rather, it allows the responsibility and authority to deviate where it makes sense. Any organization that expects its project managers to be successful must give them an opportunity to be a chef and not just a cook! One of my clients allows project managers to skip over certain processes if they don't feel they are relevant to their needs. All they have to do is state why they skipped the process. As long as you can give good reasons for not using or following a process there is no problem. Rigid adherence to process is not the best approach. Rather, the flexibility to know what is the best and the authority to execute against it is the mark of a chef. My approach is to let the nature of the project, the project team, and the enterprise culture and environment suggest the best-fit approach. This is the foundation on which the Traditional Project Management (TPM), Agile Project Management (APM), and Extreme Project Management (xPM) models covered in Part II of this book are defined and adapted so that they can deliver maximum impact on the business.