Find out what happens when a group of PMs focus too much on stakeholder communication and not enough on project execution.
Case Study 1 of 8
Maximize project involvement to avoid getting replaced. If PMs are not driving project success, then they risk becoming irrelevant. Just doing schedules and status reports is not adequate for running a project as a PM. Find a way to be a critical team member. To manage a multi-year, multi-system rollout, management hired a half-dozen PMs to form a centralized PMO. They reported to stakeholders on schedules, status, risks, and budget, including managing a steering committee consisting of several corporate VPs. The PMO got caught up in reporting and didn't focus on project delivery. After 6 months, the entire PMO staff was replaced.
As a business analyst, I worked on one of the projects. This was complex because of 5 vendor products, millions of dollars in investments, different customers, new technology, schedule coordination, and data integrations across platforms. Had the PMs focused on cross-organizational issues, became embedded with the projects, and perhaps helped to develop metrics, they might have been more integral to the team and therefore harder to replace.
My department runs an IT PMO, separate from the one mentioned, which is responsible for the success of individual IT projects, where each PM is assigned 3-5 projects each. Our PMO works critical IT projects, which keeps the PMs relevant and crucial members of the organization. This structure has worked over time, and we constantly have more PM requests than we can fill, given that the organization recognizes the value that these individuals bring to the projects.
As a project leader, in order to be the most important person on the project, you need to be aware of everything, know what everyone is doing, know what all the schedules/milestones are, and be prepared to roadshow and answer any questions about project direction. Need confidence in your role, make yourself indispensable, irreplaceable and undeniably the most important person on the project.
If you want to read more stories
Here more stories about:
When we kept adding features and suffered from scope creep
When our stakeholders realized they didn't have budget so our project was cancelled
When we had little or no guidance and suffered from slow progress
When we had insufficient the team had to stay up all night rolling back an operational fix because of insufficient testing
When users complained about a major feature and our stakeholders decided to delay our project by a year
When we kept adding features and suffered from scope creep
And here are some more tools that we discuss in the book.