Models of PM Success

I recently discovered the Blog hosted by Kailash Awati titled, Eight to Late. It's a good place to read about PM issues from an informed and thoughtful author. He reviews a collection of paper on the topic of project manger performance and the factor influencing this performance. The core paper is "The Role of Technology in Project Manager Performance," Vittal Anantatmula, Project Management Journal. This paper suggests a set of people related factors and technology influencing PM success.

Whether these are in fact influencer's is not really the issue. What struck me was the items listed as "people based influencer's" have direct enablers in the Defense and Space world to the representation of the project – the IMP/IMS. During an office conversation yesterday, while helping a colleague untangle some document/Power Point issue, I made one of my typical off the cuff remarks, regarding the development of speakers for the upcoming 2008 PMI Global Congress here in Denver. I'm tasked with developing the A&D SIG speaker track and my colleague some of the main speakers.

All this soft side of Project Management is way overrated

What this means is:

1. If you don't have a credible plan and schedule, with a handle on the cost all the "soft" skills won't get you back on track
2. If you don't have a definitive description of what "done" looks like, the "soft skills" class won't make those appear

So taking the people related factors assessed by Kailash, here's some thoughts on how to build a foundation where the people skills can be put to work

Influencer's of Success	Impact of IMP/IMS
Create clarity in communications	Each Program Event (PE), Significant Accomplishment (SA), Accomplishment Criteria (AC) should be written to describe definitively what "done" looks like for that portion of the Master Plan.
Define roles and responsibilities	This is easy. Build a RACI matrix from the IMS. Focus on the "A" first. Who is accountable for delivering "done" for the AC and the SA?
Communicate Expectations	The baselined IMS is the starting point. it defines "done," and the work needed to get to "done," with the staff and resources needed to get to "done." Now the issue of course is "do people accept, understand, concur, and generally agree what done looks like and that they are accountable for done?"
Employ consistent processes	This is an ongoing never ending process. What is needed is to separate the Project Controls activities from the Project Management activities. A&D does this with Program Planning and Controls staff. Plus some other staff looking after SEPG, CMMI, and other process based activities.
Establish Trust	IMP/IMS is all about keeping commitments. Hal Macomber's approach to "keeping promises" is a wonderful approach. Which promises to keep are in the IMP/IMS.
Facilitate support	This does fall into the "soft" side, but the IMP/IMS is a description of what support is needed. A resource loaded IMS is an amazing tool for describing what commitments are needed from the outside.
Manage Outcomes	Measuring physical percent complete on fine grained boundaries starts with the definition of "done," on those boundaries. This is an unambiguous description of the work needed, the measure of performance and the measure of effectiveness (the technical performance measure).

The rest of Kailash's post is interesting. I just wanted to check that there were no uncovered gaps between the "softer side" of PM and actually delivering on-time, on-schedule, and on-specification.

Here's the rationale. The IMP/IMS approach is based on the Systems Engineering principles of coupling and cohesion. Decrease coupling, increase cohesion. It is also based on the principle of probabilistic risk analysis of both the programmatic and technical architecture of the project (program). The key here is the notion of Architecture in the same way software architecture and building architecture are important, the programmatic architecture is important.

When you go to architecture school, the principles of building design are the "foundation" of designing building. The software side of building design comes later. Strength of materials, structural engineering, statics and mechanics, etc. establishes the foundation of "designing" buildings. The programmatic design of the program – represented in the IMP/IMS is the foundation for managing the program. It describes "done," how to get to "done," what "done" looks like along the way, how to recognize that we're moving toward "done," of in what units of measure are we recognizing that we're actually moving toward "done."