Easy in theory, difficult in practice

Long time readers of this blog will know that I occasionally like to draw lessons from other domains to project management. I am a foodie and pizza is one of my long-standing favorite foods. So I thought it would be interesting to see if there were parallels which could be made between projects and pizza!

There's more than one way to make it

If you like your pizzas to have more than just cheese as a topping do you prefer your toppings to be below the cheese or on top of the cheese? With the former method the cheese locks in the toppings so they are less likely to fall off when you eat a slice whereas with the latter you have a better opportunity to grab the slices you'd like if there are certain toppings you want more or less of.

With projects, sometimes a deterministic life cycle is appropriate whereas other times an adaptive life cycle would make sense. Push-based communication methods work in certain situations whereas pull-based approaches are suitable in others. Context counts.

It's all about the crust

Those who view a pizza crust as merely a glorified plate for a bunch of toppings are missing the point - the crust makes the pizza. Yes, you can make your sauce from scratch and use the highest quality toppings but without a crust that is equally good, the pizza won't be great.

When I teach project management fundamentals classes, I ask learners to identify some root causes for troubled projects and then ask them when those issues might have been prevented. In the majority of cases, they identify the beginning of the project as the best opportunity to do things right. Just as the crust is the foundation for a great pizza, how we kick off and initiate our projects will often determine how successful we are at the end.

There are pros and cons to outsourcing

Some people prefer to order their pizzas fully cooked from restaurants whereas others prefer to get them prepared externally but will cook them at home. Some like to buy the crust and sauce and then add their own toppings whereas others will make everything from scratch. Each of these methods has its advantages and disadvantages. If we like wood-fired pizza but don't have a wood-fired oven or grill at home, getting our pizzas from restaurants might be our only option.

The same holds true for projects. If a company has the necessary skills and capacity, they can choose to do it all in-house. But if they have other higher priority work or must outsource some or all of the scope to a third-party it will cost more and they might not always get what they hoped for.

For those of us who see project management as our calling and not just a job, I'll close with this quote from Bill Murray: "Unless you are a pizza, the answer is yes, I can live without you."

I was asked a very unique question by one of the learners in a project management course I taught this week: "How do I motivate my team members when even I don't believe in the project?".

While I'd been posed this question for the first time, it is not an uncommon challenge. It is hard enough for project managers who are in full support of their projects to inspire disengaged team members so having to do so when the project managers themselves don't feel the projects are worth doing is much worse.

Start by confirming the issue does not rest with you. Are you experiencing some general malaise with the company, your role, or some other personal cause which has nothing to do with the project? If so, deal with that first, or recuse yourself if you have the option to do so until you can deal with your personal issues.

Assuming the challenge is with the project and not you, how do you go about addressing this?

You can't just grin and bear it. If you don't really believe in the benefits from the project, it will be hard for you to create a genuine sense of purpose for your team members. Worse, if you try to fake it, your team members will pick up on this and you will lose credibility with them which will hurt you much more if you have to work with them on future projects.

Make sure you understand the underlying business rationale for the project. Whether there is a financial motive or not to the project's existence, is there something you are missing with regards to its expected benefits? If you have a good relationship with sponsoring stakeholders, meet with them to ensure you have the full picture. Ask your peers if they can see something which you don't.

If it is a non-discretionary project, ask yourself why you don't believe it needs to be done? We always want to lead disruptive, innovative, sexy projects but just because you are working on a mandatory project doesn't mean that your team members can't express their creativity, especially in coming up with lean solutions to the minimal requirements. With such projects it is often a question of re-framing how you perceive them. By keeping your organization safe, you are improving its brand, reducing risk and opportunity costs.

What if it is a discretionary project? Even if it is not improving profitability or solving world hunger, is there any benefit which justifies the investment? Even if the answer is "no", could there be an intangible reason for it such as a promise made to a critical stakeholder which, if broken, would cost a lot more to address in the future? If so, why wouldn't you want to support it?

But sometimes the project you are leading truly has no merit. If so, this is the time to use your powers of influence and persuasion to convince the sponsor, governance committees and other decision makers to do the right thing. And if they don't, you have a tough personal decision to make.

If you are asked to lead a project and don't want to, always start with why.

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:

• Who will be taking ownership for each of the key deliverables? If a RACI chart or similar staff assignment matrix is being used, an additional identifier could be added to indicate this.
• Who is responsible for ongoing monitoring and reporting of benefits realization and when will they be engaged?
• What are the expectations around "warranty" support for completed deliverables?

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?

1. The primary success criterion can no longer be achieved. All project constraints are important, but some have to be more important than others otherwise it will not be possible to develop realistic plans and to modify those plans as things change. If the primary objective can't be achieved with our current approach, then we need to change our approach.
2. A sufficiently material unknown-unknown risk is realized whose impact cannot be absorbed leading to the first condition above. I'm a big fan of the Die Hard movies, and the villain of the first film, Hans Gruber, commits the fatal mistake of underestimating John McClane's abilities to derail his exquisitely designed plan to steal the bearer bonds from the Nakatomi building. His hubris is well summed up in the following exchange: Hans "We do NOT alter the plan!" Karl: "And, if HE alters it?"
3. A fundamental planning assumption is proven to be invalid. While planning the 9/11 attacks, the terrorists made the assumption that the passengers on board the hijacked flights wouldn't have the courage to resist when faced with armed attackers. This assumption was proven wrong on United flight 93 after the passengers learned what had happened to the earlier doomed flights that morning.

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!

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?

• They are able to see beyond titles or hierarchies to understand which stakeholders possess the real power when it comes to influencing product directions.
• They have a good grasp on the company's strategic objectives which makes them able to "send messages that reinforce the strategy — and minimize other messaging."
• They have a deep understanding of the core values and culture of the organization which helps them "foster an understanding, or ethos, of “who we are.”"
• They will be more successful at influencing change vertically because of their understanding of how things get done. They know which battles are worth fighting and which are not. This can be especially crucial in the first few years of a shift to organizing around products.
• They will be better at helping the delivery team to connect the dots. Having a deep understanding of how teams within the company interact will make it easier for the PO to educate the team on the rationale for key decisions.
• When issues emerge, they are more likely to have built up goodwill with internal stakeholders to get their support in resolving the issues quickly.

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.