Easy in theory, difficult in practice

We might assume that transparency should be a given when delivering value through our projects so why is it that the actions of teams or the stakeholders supporting delivery don't always demonstrate that basic hygiene factor? Transparency is so critical that the Scrum Guide lists it as one of its three pillars and it is similarly echoed in the reference materials for many other agile delivery methods as well as in PMI's Code of Ethics.

Transparency is a rising tide which lifts the attitudes of all stakeholders:

• Customers benefit as they have to spend much less effort in understanding what is really going on
• Sponsors benefit as they will develop stronger, more positive relationships with teams and are better equipped to support their teams in a more timely manner when issues arise
• The project manager and team benefits as they don't have to worry about putting the right "spin" on events and are less likely to get distracted or waste effort in needless status updates for stakeholders. They will also benefit if the higher levels of trust which result from increased transparency encourage enterprise groups to lean out governance requirements by focusing on the few outliers rather than punishing the majority.

I wrote a few years back about the downsides of unfiltered transparency as this could generate unnecessary panic or encourage micro-management from our stakeholders, but responsible transparency is key to creating trust.

Responsible transparency is about providing the truth, warts and all, but ensuring that sufficient context gets provided so that our stakeholders' reactions to the truth are appropriate. Project teams have many tools and techniques available to them which can provide transparency about progress and impediments, but using these in isolation may not provide that context. For example, reviewing individual work items in a sprint backlog without also being aware of the sprint goal(s) identified by the Product Owner doesn't help a stakeholder see the forest for the trees. Similarly, trying to interpret a burn down or burn up chart without understanding the team's delivery approach or the contents of a sprint or release backlog might create the wrong perceptions.

So as you strive for transparency in your information radiators and other communication methods, ensure that you are providing the necessary color commentary to make the information meaningful.

The single most important ingredient in the recipe for success is transparency because transparency builds trust - Denise Morrison, (Former) CEO, Campbell Soup Company

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'm midway through reading Choose Your WoW! from Scott W. Ambler and Mark Lines of the Disciplined Agile Consortium. While their 2012 reference book for Disciplined Agile Delivery provided guidance for teams interested in tailoring their delivery approaches, the new book delves much deeper into the key goals, decision points and options for those decision points. It also provides external references to inspire practitioners to venture down the rabbit holes for the practices they wish to explore further. The main content of the book comes in just under four hundred pages but given the volume of information provided, it shows that the authors have been practicing what they preach when it comes to minimally sufficient documentation!

Their book focuses on teams using adaptive lifecycles for delivering technology solutions but it would be still be helpful to address the needs of teams who are utilizing traditional approaches for delivering projects in other industries or domains.

What would the outcome have been if the volunteers who created the sixth edition of the PMBOK Guide had taken a similar approach? Yes, the current edition contains new sections with tailoring considerations but those are just scratching the surface of that critical topic.

Perhaps they would have realized that the current guide should have really been released as two separate documents. There is still a need for a PMBOK framework reference covering process groups, processes, inputs, outputs, tools and techniques, but much greater value would have been realized by practitioners in having detailed guidance for exploring the key goalposts and decision points taking into account the context of a given project and the culture of the organization they are working in.

This could be done using a decision tree approach similar to that used for Disciplined Agile but imagine how much fun it would have been if it was written like a Choose Your Own Adventure® book? Such a guide could help teams understand the options available to them while simultaneously exploring potential downstream implications of their decisions. Add in some cartoons illustrating key concepts and the Guide would no longer be considered a surefire cure for insomnia!

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.