I'm sure some of you have led projects where everything appeared to be going swimmingly right up to the finish line only to find that you had somehow stepped into the project equivalent of the Hotel California. Everyone has a desire to wrap things up and move on to whatever is next but transition seems like it will never end.
While there might have been some reasons late in the life of the project as to why this unfortunate situation occurred, in most cases, problems with ending projects cleanly can be traced back to something that was missed early in the life of the project. This is why Stephen Covey's second Habit "Begin with the end in mind" is so apropos. Not only does this encourage key stakeholders to share their understanding of the project's outcomes to help in crafting the project charter, it also reminds the project manager to start to ask important questions of how the end of the project will be handled including:
Transition activities can be identified and planned based on the answers to these questions.
When major changes occur or a significant milestone has been achieved, the impact on these transition activities should be considered. For example, if a deliverable has significantly changed or a new one introduced, ownership of that deliverable, impacts on benefits tracking and support needs might have also changed.
It is also a good idea to know when enough is enough and to articulate that up front too. I've seen some projects drag on for too long till someone finally shows the leadership to put them out of their misery.
I've been a fan of the fantasy TV series Doctor Who dating back to my distant childhood memories of hiding behind our living room sofa when Daleks threatened the Earth. While each of the actors (and now actresses) who have portrayed the titular character have been memorable, Tom Baker will always be THE Doctor to me. When it was his time to hand over the mantle to his successor, Peter Davison, his final line from the episode was particularly meaningful as he regenerates into the Fifth Doctor: "It's the end...but the moment has been prepared for."
Has the end of your project been prepared for?
Articles have been written about the importance of doing just enough planning to develop confidence in what we are proposing to do as well as the perils of either too much or too little planning.
But even a good enough plan can become obsolete at some point and we need the wisdom to know when it is time to jettison it.
A common portfolio management anti-pattern is the inability of gatekeepers to terminate low value projects in a timely manner. There are many causes for this, but one is the inability to easily write off project sunk costs. The same can be said of plans - some teams and especially their leaders can become so enamored with their plans that their confirmation biases cause them to ignore clear evidence that those plans are no longer valid.
So what are some signs that a project plan needs to be punted?
But is it sufficient for us to recognize that a plan is no longer valid? No, because this realization needs to be effectively communicated in a timely manner such that a new plan can be formulated. Doing this requires not only courage but also a sufficient level of psychological safety within the team to reduce the likelihood of team members choosing short-term conflict avoidance over long-term pain. Naohiro Masuda's management of the crisis at the Fukashima Daini nuclear plant in March 2011 provides a good example of how leaders might behave when planning under pressure.
Planning is essential, the value of plans is ephemeral, so let's treat them that way!
Does your Product Owner have a high OQ?
An article from Harvard Business Review reminded me that becoming an effective Product Owner (PO) requires a lot more than interpersonal skills, empowerment, capacity and even product knowledge. In the article, the authors explained that leaders having a high level of Organizational Intelligence (OQ) stand a better chance of getting the organization to do what they want.
How can having a high OQ help a PO?
This is one of the reasons why it is can be extremely difficult to fill the role well with someone who is external. A consultant or new hire might possess deep knowledge of the product and business domain, they should definitely have sufficient capacity to handle the heavy workload and they might even be exceptional at soft skills, but if they lack sufficient awareness of how things get done within their client's organization, they are unlikely to be as effective as someone internal who might be lacking in the other areas.
Sometimes there may be nobody internal available who has sufficient capacity. If so, it is better to bring in an external player to back fill the "right" PO's normal responsibilities. And what if you don't have anyone with sufficient product knowledge which could be the case if the product or service is new to the organization? In such cases, it might be better to have an external player to support an internal PO while they are developing the necessary domain knowledge.
Building the right product requires a coalition of support across an organization, so don't skimp on OQ when it comes time to pick a PO.
I'll admit to being hyperbolic with the title of this article, but a question posed today in one of the project management LinkedIn discussion groups managed to sidetrack what I was intending to write about this week. The author asked what needs to be considered when planning risk responses. The majority of the answers offered focused on characteristics of the individual risks themselves such as their probability, impact, ability to be responded to and so on.
But what we should consider is not just the specifics of a risk but also the context in which that risk exists. Enterprise environmental factors will also affect not just the nature of risk responses but also their effectiveness, and one of the more significant ones is risk appetite.The PMBOK Guide®, Sixth Edition defines risk appetite as the "degree of uncertainty an organization or individual is willing to accept in anticipation of a reward". This definition acknowledges that appetite should be considered from the perspective of multiple stakeholders and not just that of the project team or sponsor.
Stakeholders with a low appetite for a particular type of risk might influence a stronger risk response than is warranted which can impact efficiency. Those with a higher appetite can reduce the effectiveness of the overall project risk management approach. As with so much else in project management, the Goldilocks principle applies to risk response.
Risks can be positive or negative, but risk appetite usually has a greater influence on how we handle threats rather than opportunities. The exception are cases where the realization of an opportunity generates secondary negative risks.
Companies operating in risk-driven industries such as financial services are more likely to have appetite statements defined organization-wide. Such statements can help governance staff to define policies and to provide practitioners with clear examples of the types of risk which might be passively accepted and which ones should be actively managed. However there remains a degree of subjectivity when it comes to risk based on one's own biases, and with ever increasing project complexity and uncertainty, such statements can only go so far in creating consistency.
One way to address this is for a project manager to facilitate a risk response guidelines workshop with key stakeholders early in the life of the project. Take each of the project's constraints and success criteria, define a range of outcomes for those based on the impact of a risk event and ask stakeholders which risk response (e.g. mitigate, transfer, avoid, accept, escalate) should be utilized for each potential outcome. Not only might this help to create some consistency in practice but it would also provide the project manager with insights about the relative biases of each stakeholder to different types of risk. This information can then be captured in the Risk Management Plan.
Finally when it comes to managing risks over the life of a project, it is important to remember that stakeholders' risk appetite will change.
“But doth not the appetite alter? A man loves the meat in his youth that he cannot endure in his age.” - Shakespeare, 'Much Ado About Nothing'
The original seven Disciplined Agile (DA) principles were recently refactored and as part of this refactoring, a principle was added: "Organize Around Products/Services".
While it is just one of the eight principles, this new one aligns very well with lean thinking. It also addresses many challenges which leadership teams experience with agile transformations. Such transformations require change to happen in not only the delivery teams within an enterprise, but also supporting functions such as finance, human resources, operations and procurement.
Some benefits of a product or service-centric organization include:
This is not to say that organizations don't need project management as the hard and soft tools of the profession are still critical to implementing successful change. There will always be some changes which are "one and done" and those will remain fair game for project teams. Nothing would prevent product/service owners from organizing the allocation of funds within their annual allotment to projects if that makes the management of this funding easier for them.
But if we are looking to increase alignment, organizing around products or services is a good way to cut through the silo thinking which develops when we are organized by function or capability.