What are some of the challenges in the PM Practice?

This post is extracted from a chapter in our upcoming book on Project Management with the title, Project Management beyond Waterfall and Agile.

Some practitioners of project management raise their concerns in dealing with the challenges
they face in project management, especially when relying on only one guide or resource. The
following comments reflect some of these difficulties.

  • “I understand the guide, but now I need to apply this to my specific project (or industry).”
  • “How do I connect the dots?”
  • “I know the process groups repeat, but how do I implement them?”

The project management processes are better viewed for managing a phase or stage, not the project.

In general, these challenges arise because many practitioners do not understand that they have
to think at two levels: managing the stage level and managing the project level—these are the
first two dimensions of CAMMP™.

They also need to think of elevating performance through the third dimension.

Keep in mind that the ISO and PMI guides present the processes to manage a project or a
phase. However, as explained in Chapter 17, the processes are better viewed for managing a phase or stage; not the project. The use of the process groups is not enough for projects that are not simple or small. Therefore, a project manager and the project management team can manage the phases and stages using the process groups, but to manage “across the stages,” they must depend on a project life cycle model.

Let’s maintain the focus on the first two dimensions now.

  • How do we manage across the stages?
  • What does it mean to “think at two levels”?

Remember what was presented in earlier chapters—there should be a stage charter (stage
authorization document, SAD) and a project charter (project authorization document, PAD).
Similarly, there is a stage management plan (SMP) and a project management plan (PMP); a
stage detailed plan (SDP) and a project detailed plan (PDP); and so on.

For example, control must occur across the project life cycle, as the team progresses from
one stage to another; yet control is also within the stage as the team moves between the processes.

Similarly, risk analysis is for the project as a whole and for each stage, because there are
project risks and stage-specific risks.

All the chapters in this part will help the reader visualize how to think at two levels for some of the functions.

 

What do you think?