jump to navigation

PMP Certification Exam, Lessons Learned October 20, 2012

Posted by Tim Rodgers in Management & leadership, Project management.
Tags: , ,
trackback

I’ve been busy for the last couple of weeks studying for the PMP exam (I passed) and that hasn’t left much time for writing, but now I’ve got some time to reflect. I came up through the ranks as a project manager, learning through trial-and-error, and it’s been interesting to contrast those experiences with the standard processes and tools recommended by the Project Management Institute (PMI).

The product development projects that I’ve managed or participated in have typically followed a well-defined lifecycle with phases and formal checkpoint meetings. The phase checkpoints were theoretically go/no-go gate reviews, but in practice they were project updates for senior management and an opportunity to re-visit objectives and priorities. A project’s activity list and work breakdown structure were based on templates from previous projects. Development cost was estimated at the beginning of the project and tracked during the project, but it was understood that additional money and resources would be available if necessary. Schedule was usually the overriding constraint in order to meet sales channel commitments, so we would spend a lot of time analyzing the critical path and critical chain.

I’m guessing that those descriptions are fairly typical for product development projects. To their credit, PMI makes it clear that each organization should customize the recommended project management processes to align with their business objectives, streamlining or even deleting processes if necessary. That’s generous, but now that I’ve completed the training for the PMP exam there are three process areas that I’d like to emphasize in future product development projects:

1. Project charter and stakeholder management processes. In the future I want to spend more time formalizing the project charter, getting alignment, and clarifying the expectations of all stakeholders, not just the project sponsor. It’s not a good idea to wait until checkpoint meetings to discover a mismatch in priorities.

2. Formal change management processes, especially for scope creep. As a project manager I had a lot authority over scope changes, but the complexity of the design, the geographically-dispersed project team, and the influence of functional managers often made it difficult to stay informed. I want to help the team and stakeholders understand the risk to schedule when there’s a weak commitment to change management.

3. Risk analysis and management processes. In our projects we didn’t ignore risk, but I think the culture placed a higher value on firefighting instead of fire prevention. We should have spent more time assessing risk and looking for ways to avoid or mitigate.

I’d be willing to bet that these areas are not given enough attention in the majority of projects, especially when organizations become complacent. In my next job I’ll be the new guy, and that will give me the chance to ask the questions and perhaps challenge the assumptions that have governed previous projects. I’m looking forward to applying some new lessons learned.

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: