Post written by Jason Z., Project Manager at Ideaca. Read
more about project management on his blog: Unnatural Leadership.
“A little knowledge is a dangerous thing” – Alexander
Pope
While I was studying to become a project manager, I
believed what A Guide to the Project
Management Body of Knowledge (known as 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 subject matter experts, 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?
1.
Don’t assume you know everything
Even 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.
2.
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.
3.
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 project management
office. 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?
0 comments:
Post a Comment