I’ve written a few articles on the risk posed by resource availability to most knowledge-based projects, and I still feel that this is a frequent cause of schedule & budget overruns. Other common risk factors impacting projects include requirements clarity, technology uncertainties and organization change resistance. Finally, project priority is a major source of risk these days – the “star” project that receives funding and focus today could morph into the “dog” tomorrow that is starved of resources.
A more subtle risk factor, and yet one that can be equally pernicious has to do with that unique project role – the stakeholder. I was once told this definition for a stakeholder: “Anyone with the ability to sink your project”.
One tends to think of negative stakeholder influence as a common source of risk to construction or other highly visible external projects, but any moderately complex internal project could also possess multiple stakeholders with competing agendas.
To address this source of risk, the best response is thorough and regular stakeholder analysis. If you are not sure that you have identified all of your stakeholders, seek advice from a peer or mentor. Meet individually with your stakeholder representatives early on and reinforce these relationships throughout the lifecycle of your project. It may be naive to assume that you can satisfy the needs of all of your stakeholders, so your objective should be to manage the impacts of their influence on your project. If it is not possible to work towards a “win, win” situation, you may need to solicit assistance from your project sponsorship or other stakeholders.
Project teams working on high stress, aggressive time line (is there any other kind?) projects tend to focus on their customer or their project steering committees. This myopia can be fatal – stakeholder influence is perhaps the best example of Dr. Hillson’s definition for risk: “Uncertainty that matters”.
(Note: I wasn't blindsided when I wrote this article in January 2011 on kbondale.wordpress.com)
I’ve written previously about the need for a project manager to proactively plan for a smooth transition if someone else will be assuming the role on one of their projects. Should you be fortunate enough to find yourself taking over from a project manager who has followed some of those suggestions, it will make your life easier.
But often we don’t have that luxury.
When projects get into trouble, rightly or wrongly, the project manager may have been identified as a convenient sacrificial lamb and you might join the project after they have been expeditiously shown the door. Other times the individual might have just been moved to a different, higher priority project but they did not maintain a complete, accurate project control book or they may simply not have the time to help with your onboarding.
In such cases, what should you do?
Meet the sponsor
Even if there are documents such as a charter or project management plan, there’s no substitute for learning about the needs and wants of your sponsor as early as possible. Developing a productive, symbiotic relationship with this critical stakeholder will often make the difference between success and abject failure.
Make sure you take the time to understand what they expect from you from both a communications and expectation management perspective, but also gauge their willingness to support you when decisions, issues or risks have been escalated to their attention.
Meet the team
Recognize that the team will be experiencing the change churn of having lost a leader.
If the previous project manager was despised, you will bear some of that baggage and will want to ensure that you don’t get drawn into a comparison competition with your predecessor or having to defend the value of project management. On the other hand, if the team adored their project manager, you may face suspicion and resentment and will have to avoid the temptation to become defensive about why you were placed in the role.
Be curious, ask questions, but most important, strive to be a servant-leader, giving the team some time to grieve but also demonstrating your value by escalating or ideally removing any hurdles that have hampered their productivity.
Trust but verify current state
Status reports, feedback from the sponsor or the team might provide you with insights into the project’s state, but seek evidence that supports their assessment.
Identify recent milestones and confirm that different stakeholders agree that those have been successfully met. Once you understand what milestone is coming up, check with the sponsor and team to ensure that there is alignment towards its completion. Ask questions about the top three risks and issues. Check the financial health of the project with your finance partners to ensure the books are in good shape.
While a project plan might exist for your project, you should still create a personal onboarding plan reflecting the specific activities you will need to complete to be effective in your new role. Treat this role transition as you would any meaningful project – plan the work, and then work the plan!
(Note: this article was originally published to kbondale.wordpress.com in January 2017)
A student in a project management class I taught shared the concern that it was very hard for her to get risk responses implemented. This is a fairly common problem and is likely one of the reasons that the volunteers who updated the PMBOK Guide, Sixth Edition added Implement Risk Responses as a new process within the Project Risk Management knowledge area.
Most companies which have project management standards require teams to identify and analyze risks, but merely capturing information in risk registers is worthless if nothing is actually done to manage those risks. Acceptance is a risk response strategy, but project managers are not supposed to just report on accidents, they are expected to prevent them. But there's only so much that they can do by themselves. Risk management requires investment from stakeholders outside of the project team to really make a difference.
Getting a reluctant stakeholder to commit themselves to a risk response requires change management so let's see if Prosci's ADKAR® change model could be used as a framework to achieve this objective.
Awareness & Desire: If the proposed risk response owner is not aware of the need for them to participate, nothing will happen. Sending them a risk register by e-mail and asking them to review the risks which they can help with isn't likely to generate a prompt response. Meeting with them in person and clearly articulating the nature of the risks and the proposed responses might work better. Response owner awareness is a good starting point, but why should they expend their valuable time, money or political influence? Helping them understand how they have "skin in the game" for the project's success will be critical if you want them to commit themselves.
Knowledge & Ability: Does the response owner clearly understand what you'd like them to do and do they possess sufficient context regarding the risk? Do they already have the necessary knowledge to plan and execute the response, and if not, how can you simplify that learning curve?
Reinforcement: Just because you've had a meeting with the response owner and they've bought in to the need for their action doesn't mean that you can wash your hands of the risk. Regularly reporting on the status of implementing risk responses to your sponsor and key stakeholders as well as following up with response owners will be needed to increase the likelihood of follow through.
Read any of the case studies which are published in PMI's monthly PM Network magazine and effective risk management is nearly always identified as a contributor to a team's success on large, complex projects. But without addressing the need for personal change, your risk management efforts are likely to remain an academic exercise.
Most organizations regardless of their size or project management maturity will initiate a proverbial “800-pound gorilla” project at least once. Mega-projects can torpedo a company, but they are often critical to their long term sustainability or strategy. For the “lucky” program or project manager that is asked to manage one of these, it can either be a career-limiting death spiral or a priceless differentiator for their portfolios.
Failing to plan is planning to fail – this is the mantra of mega-projects. Organizations that were historically able to successfully complete small to mid-sized projects in spite of themselves will discover that heroics that worked in the past will not work on a mega-project.
To plagiarize Jeff Foxworthy, here are some ways of identifying mega-projects:
What are a few ways of coping once you’ve identified the fact that you are the proud owner of an 800-pound gorilla?
Tackling a mega-project can sometimes feel overwhelming, but remember that even King Kong was laid low by a combination of fighter planes and gravity!
(Note: Neither King Kong nor Donkey Kong was involved in the publishing of this article back in November 2010 on kbondale.wordpress.com)
When I first started to manage projects, I had envisioned the role as being similar to that of an orchestra conductor – while not being directly responsible for playing specific instruments, possessing familiarity with the strengths and weaknesses of each, and being instrumental (pun intended) in creating harmonious melodies instead of raucous cacophonies.
This illusion rapidly dissipated after a few days on the job. I came to realize that project managers need to be like Lon Chaney – the man of a thousand faces. Here are a few of the roles that a PM might be called on to play in a typical project.
1. Salesperson – Successful PMs need to be able to create a need for and “sell” their customers, stakeholders and team members on decisions or recommendations that may not be popular.
2. Football lineman – A PM must often be the offensive lineman preventing their “quarterbacks” (a.k.a. team members) from getting tackled by distractions.
3. Coach – Vince Lombardi nailed the essence of effective project management with his quote “Coaches who can outline plays on a black board are a dime a dozen. The ones who win get inside their player and motivate.”
4. Diplomat – PMs are often called upon to help resolve conflicts, negotiate for win-win outcomes and to deliver bad news in a constructive fashion.
5. Historian – PMs should be able to review the past life of their projects, analyze events and derive lessons that can be applicable to future projects.
6. Diagnostician – PMs require the analytical ability and perspective to look beyond symptoms to help identify the root issues that are plaguing their projects.
My guess is that there are probably a hundred other roles that could be part of this list – how many can you add?
(Note: I was wearing my blogger hat in November 2010 when this article was originally published on kbondale.wordpress.com)