-->
Showing posts with label project management body of knowledge. Show all posts
Showing posts with label project management body of knowledge. Show all posts

Tuesday, 11 March 2014

What if you are your project’s biggest risk?

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?

Monday, 6 January 2014

Project Management isn’t just for IT or Engineering anymore

Post written by Jason Z., Project Manager at Ideaca. Read more about project management on his blog: Unnatural Leadership.
As part of this month’s Ideaca blogging network challenge, we were tasked with discussing our thoughts on Emerging Practices.
One of my favorite quotes to reference from the The Project Management Body of Knowledge (PMBOK, pronounced pemmmmbock) is “As project management is a critical strategic discipline, the project manager becomes the link between the strategy and the team. Projects are essential to the growth and survival of organizations.” So, while operational duties are of very high importance to maintaining the forward momentum and revenue generation for a company, projects are strategic and help organizations react to changes in the external environment that may slow forward momentum and/or impair revenue generation.
Taking this as rote, one Emerging Practice that I am pleased to see is that more industries and functions – outside of Engineering and IT – are recognizing the need for project management:
So what does this mean for Project Management as a career? It means that effective Project Management is not just for IT and Engineering anymore. In fact, the rest of the organization is going to have to contend with:
  • Increased workloads for Subject Matter Experts. If you know the organizational area, you must know how to manage the project to do something in this organizational area.
  • Gone are the days of black box projects – clients are demanding more visibility into what is being delivered, how it’s being delivered, and how delivery is progressing.
  • Organizations are demanding value from their staff’s time - projects are going to have to deliver more than a “thing.”
  • Successfully implementing changes in an organization can no longer be ad-hoc, and to a lesser extent grassroots. Rather, efforts must be controlled activities.
This is both amazing, and troubling at the same time. It’s amazing because having proper control, visibility, and communication for organizations can return recognizable and material value. It’s troubling though, as many organizations may start expecting their people to be expert project managers without any proper training or experience (this link is a great discussion on LinkedIn, by the way).
If your organization is transitioning to more of a project focus, and you don’t have the time or desire to become a fully trained PMP, there are a number of ways to get up to speed on how to be effective:
  • Hire a dedicated (or shared) Project Manager – This person should be able to apply project management best practices while you are focused on the subject matter at hand. If your department doesn't have the budget or enough work for a full time Project Manager, share the PM (both cost and time) with a different department.
  • Mentoring – Junior PMs will often work with Senior PMs for mentoring, so why not do the same? Your company should have a PM for you to reach out to, or you can contact someone in your local PMI chapter.
  • Training – Most colleges offer introductory PM training. In exchange for some of your time over a couple of weeks, you can get trained up on how to run a small project effectively.
  • Reading – There are many great books available. One that I recommend is Project Management Lite: Just Enough to get the Job Done…Nothing more. Another, more detailed, is the big bible - Rita Mulcahy’s guide to passing the PMP on your first try. You don’t have to attempt the PMP, you just need to read this book.
Has your organization made the transition to more project-based initiatives?  How has it impacted you?  What have you learned?