I’ve heard that “A good project manager can manage any project, as long as they’ve got good people on the project”. In the perfect world, maybe. In the real world, no way.
Those promoting project management focus on characteristics of PMs that are common across all disciplines: interpersonal skills, organizational skills, communication skills, and problem-solving skills. These are necessary but not sufficient qualities. Good project managers also have interest and depth in the subject matter of the project.
It seems that the world has forgotten about history’s great project managers. They were overwhelmingly individuals with abiding interests in their fields. Werner von Braun led the massively successful development of the Saturn moon rocket. General Bernard Schriever, the man cited as “The Father of Project Management” (here), who led the Air Force’s space and missile programs in the 1950s, was a long time pilot with an engineering degree. Frederick Brooks, with a PhD in Mathematics from Harvard, led development of IBM’s OS/360 operating system, fundamental to IBM’s dominance 0f commercial computing during the 70s and 80s. “As of 2008[update] he is still engaged in active research there, primarily in virtual worlds and molecular graphics.” (Wikipedia)
I recently witnessed two IT projects, both multimillion dollar efforts and both business-critical. Project A, a migration to a commercial-off-the-shelf (COTS) human resources system, tracked to budget and schedule and met business objectives with almost no customization. Project B, another COTS effort for core business operations, suffered huge budget and schedule overruns associated with frequent changes in direction and scope expansions.
Project A was outsourced to an outside consulting firm, who brought in a PM with deep technical experience configuring and customizing the COTS package. Project B was run by an internal Project Management Office, staffed by project managers who did not have technical or business analysis backgrounds.
Project A’s leadership had the background to understand the road ahead, and spent six months of a two year project in definition, completing detailed business requirements, business process design, and system architecture deliverables. On Project B, a senior IT manager decreed that the team skip requirements definition, since future business processes would be dictated by the COTS application: a critical early mistake. Project B’s management did not have the IT background needed to recognize the mistake, which would have been obvious to the Project A team.
For a PM to be effective he or she needs sufficient knowledge to envision the end product in a scope and objectives document, create a work breakdown structure that makes sense to business and technical team members, and know which risks are pivotal and which don’t matter.
In spite of stereotypes about IT folks, many are experienced, articulate, well organized, have great interpersonal and problem-solving skills, technically curious, and would welcome an opportunity to lead an ambitious project. Make one of them your project manager, provide strong organizational support, and you’ll be more likely to achieve objectives on budget and on schedule.
Couldn’t agree more; I’ve always equated it to teaching. You can’t simply hand a smart person a book on particle physics and expect that person to teach it well. What happens when students have questions? What happens if there’s an error in the book?
Project management methodologies like PMBOK describe processes for running a project, but they seem to trivialize “the details”. In my opinion, you can’t effectively manage a set of processes, if you don’t understand the value of the relevant inputs/outputs.
Thanks for article. Everytime like to read you.
Have a nice day