PM Isn’t Rocket Science, But Neither Is It Easy

 

They don’t call Project Management “the accidental profession” for nothing. Many of us arrived here from a business or management background, but a lot of us came into this profession via a more indirect route, specifically, through a technical discipline that landed us in front of a new project. And this is where it can get really interesting.

I recall one particular meeting I attended based on an invitation from a high-level executive who suspected his head of Program Controls was doing a poor job. The executive was right. This fellow wasn’t trained in PM – he had a Ph.D. in a technical discipline, and knew just enough PM jargon to insinuate himself into the newly-created slot he occupied. His Team was large, as was the conference room, so I just took a seat in the back and kept my ears open.

“Here’s the problem I want addressed” he began, standing in front of the rather large white board. He drew five large rectangles on the upper third portion of the white board.

“These represent the major program offices” he stated. He then drew about a dozen smaller rectangles in the middle third of the white board, in a different color.

“These are the major projects within the portfolio” he said, as he drew lines both between the mid-level rectangles and the high-level ones. He then drew around twenty small rectangles on the bottom third.

“These represent the organizations that perform the work.” Using another dry-erase marker color, he drew lines between the small rectangles and the mid-sized ones, with many of them reaching to the opposite side of the white board.

“Some of these projects cross programs, and most of them use multiple organizations, often at the same time.” Using yet another color, the lines drawn were proliferating.

“They also use some of the same facilities,” (more lines) “and, in some cases, the projects’ work overlaps with others.” At this point the white board looked like someone had thrown up on it after having eaten a massive amount of spaghetti with Skittles sauce. If he thought he was depicting a desired business model end-state, he was comically mistaken.

“We have to be able to capture all of these entities, and their relationships to each other, in order to create a comprehensive program plan.” The individual Team members, almost all Project Controls Specialist, were strangely silent. I guessed (rightly) that most of them recognized that this manager didn’t know what he was talking about, but were reluctant to offer their opinions about how to properly approach the problem. It wouldn’t be long before I found out why. After the meeting, I approached him, and asked for a sidebar. He knew me by reputation (I had actually trained most of the Project Controllers in this organization), and, after summoning his deputy, we sat in the foyer.

“When you say that you need to capture how the projects ‘overlap,’ that’s typically accomplished with a Work Breakdown Structure, where the scope is delineated in a hierarchical fashion. Which elements of scope belong to which project and program are then clearly defined. When you discuss the need to identify possible overloading or underloading of the resources needed, that’s usually done using a resource dictionary in your Critical Path Methodology software. By assigning specific resources to the activities laid out in your WBS, possible conflicts can be identified and avoided. Finally, the issue of more than one activity or organization using the same facility can be resolved by loading the work’s locator codes into the schedule baseline. Once the schedule baseline is calculated, those conflicts will also be identified.” The fact that I had to tell this fellow such fundamental things about PM was a bit frustrating, and I rather had the impression that he believed his technical Ph.D. should have entitled him to automatic deference in PM matters. I learned later that he was planning on solving his problem by purchasing and employing a specific software package, one based on the Earned Value Methodology. There appeared to be no effort at ascertaining whether or not the package cleanly interfaced with the CPM software, or the general ledger. I came to believe that he had simply seen a presentation by this particular software vendor, and had been sold without a clue of how the package would fit into the overarching MIS architecture – and he wasn’t about to change his mind. I then realized why the room of Project Controls analysts stayed silent – they knew it was futile to reset this fellow’s technical agenda towards something that might actually work.

Don’t misunderstand – I’m not saying a plurality, or even a sizeable proportion of technical Ph.D.s view their PM counterparts as intellectual inferiors. But PM isn’t easy. It’s not rocket science, but doing it right is not easy.