By Jason H. Zalmanowitz
“A little knowledge is a dangerous thing” – Alexander Pope
While I was studying to become a project manager, I believed what the PMBOK and my professors had to say as the gospel truth: a project is a project is a project. It didn’t matter that I had no experience building a bridge, planning a wedding, or configuring a database server… I was going to be a professional project manager, and that meant that I could manage anything (so long as I followed the 5 phases of the PMBOK and did everything that the 11 knowledge areas told me to do)!
For a while, that was the case. I made sure that all of my projects had strong technical people that were good communicators so as to provide good estimates, identify risks early and often, and manage the details of the deliverables. I was able to focus on managing at the executive level, facilitating problem resolution, and provide project administration support.
But then it happened – I was assigned a project where I had a little bit of technical knowledge, but not much, and was paired with some intermediate resources. They were technically strong, but were relatively inexperienced in working in a large project setting. At the time, though, I did not know this and just assumed that they were as skilled as every other project team I had worked with in the past. When we sat down to plan, I used the same process as with my other project teams; when we ran status meetings, I used the same process as with other project teams; and when we identified risks, I used the same process as with other project teams. However, development activities continued to miss dates, and my inquiry into what went wrong with the team yielded answers like “we don’t know”.
As a result, I used my fairly limited knowledge of the subject area to help plug the gaps that I saw. When asked questions by the sponsor and SMEs, I gave them answers that I believed to be true without consulting the team. When asked questions about the technology by the IT operations team, I gave answers that I had heard given in the past without consulting the team. And then things started to go really wrong. The client kept asking the team about things that I had said, and were told opposite things, the project team kept freezing me out of discussions, and my Program Manager came back to me with feedback that I was about to be fired from my project.
At that point, having a team that was not as strong as my previous teams was not the issue. My assumptions, silo’d decision making due to frustrations, and unfair expectations of the team introduced a myriad of risks, which of course I didn’t capture in the risk register, to the deliverables. These risks almost immediately became issues when I communicated out without consulting the team. I was the issue. I was the project’s biggest risk to scope, schedule, and budget.
So what should I have done?
- Don’t assume you know everythingEven though I had some experience with the technical area, and was a well seasoned project manager, I should not have assumed that I knew better than the team. It’s OK to say “I don’t know”, so long as you promise to get the answers and follow up.
- Consider your team’s requirements
Instead of forcing the team through processes that worked well for other teams, I should have considered their requirements in the locus of their experience level. During the “forming” and “storming” phases of team development, I should have been asking questions rather than imposing processes. When I saw a process that did not work, I should not have knee-jerked into command and control mode; rather I should have worked with the team to re-assess
- Recognize that you cannot push a rope up a hill
As a project manager, it is your job to facilitate successful project outcomes. Unless you are explicitly performing a specific role on a project team, your only true deliverables are status reports, communications, and facilitated sessions. It is up to your team to deliver the technical content. If there are performance issues, talk to the team members (and then their managers if required). If there are scope concerns, talk to your sponsor. If there are resourcing concerns, talk to your PMO. Do not try to own the issue; try to facilitate resolution.
In the end, I focused heavily on #2 and #3 and struggled with #1 through to project closure. After giving answers for so long, it was hard not to. As far as the project was concerned, after a re-baseline, it was delivered to scope, schedule, and budget constraints.
What type of learning opportunities have you had through projects? How else could a Project Manager be the project’s biggest risk?
Jason H. Zalmanowitz, MBA is nerdy Management Consultant / Project Manager who has spent the majority of his career working for consulting firms in Calgary. As a Project Manager, he has managed consulting engagements, strategy development projects, software development projects, and hardware implementation projects.
Article source: http://www.pmhut.com/what-if-you-are-your-projects-biggest-risk
Powered by Facebook Comments