Easy in theory, difficult in practice

HBR published an article this week reinforcing the importance of purpose for building engagement and creating high performance with project work. Twelve years ago, Daniel Pink doubled down on purpose with his book Start with Why and made it part of his intrinsic motivation triad.

Making sure that a project's purpose is clear, well understood, and shared by key stakeholders is critical but all too often that valuable information is hidden like the Ark of the Covenant in that secret government warehouse at the end of Raiders of the Lost Ark and it is left to each individual to locate it.

Kick-off meetings provide a good opportunity to remind attendees of the project's purpose but those are normally just held at the beginning of a project or phase and our memories of what we had heard tend to fade with time.

While forgetting what was the purpose underlying our project is likely to sap our enthusiasm for continuing to work on it, there are at least two other risks that this amnesia generates.

1. Without a clear understanding of why we are investing in the project it will be more difficult to convince stakeholders that a requested change is not needed to achieve the expected outcomes. As such, the potential for scope creep (or leap) increases.
2. Worse yet, if there are environmental or other contextual changes which decrease or even eliminate the project's benefits we might not be aware of this and hence are less likely to warn key decision makers that they may want to reassess the project's viability.

This is why it is important that we keep the project's purpose top of mind for our team and other key stakeholders. The more people who remain aware of it, the greater the likelihood that at least one of them will detect that one of these two risks is about to be realized.

But how should we go about doing that?

Using multiple complementary methods of reinforcing purpose will help as there are likely to be differences in how each stakeholder re-learns things.

Capturing it in a short but impactful information radiator such as a project canvas which could be posted in prominent locations online and in the physical world is one option, but so is having the sponsor, or better yet a real, live customer create a video or come and visit the team to talk about it regularly. Reminding everyone of the project's purpose during key team events such as retrospectives or post-milestone reviews will help. Distilling it down to a slogan and printing that on t-shirts, coffee mugs or mouse pads will also help to keep it front and center.

Lewis Carroll might have said "If you don't know where you are going, any road will get you there", but forgetting why we are doing a project is a good way to ensure that road leads to nowhere.

It is still more than three weeks till Halloween but stores have already sold most of their spooky selections and are starting to put their Christmas stock out on the shelves. This Halloween may generate more anticipation than in previous years since last year's festivities were curtailed in many cities due to the COVID-19 pandemic.

Halloween holds a special place in my heart as it provides an opportunity for everyone to express their creativity. For the kids, they get a chance to dress up as their favorite heroes or villains while us adults get the chance to decorate our homes in readiness for the hallowed night.

To put you in the mood for October 31, here are a few project management lessons derived from Halloween.

Less is more

It can be tempting to go over the top with decorations in the theme of Clark Griswold's lighting excesses in National Lampoon's Christmas Vacation but resist. Remember that the best scares come from what isn't seen but is implied.

When your stakeholders are trying to throw everything and the kitchen sink into a project's scope, help them to focus on the minimum required to achieve the expected outcomes. This will help to contain costs, reduce risks and deliver value sooner.

A little risk management goes a long way

It might be urban legend, but do you really want to bite into a piece of candy and find a pin or some other nasty foreign object inside? Waiting till we get home and have our parents' check our loot is a safe, simple practice. Wear whatever costume you want, but make sure there are some reflector strips so that drivers will see you as you are running across the street.

To be effective, risk management needs to be perceived as adding value and pragmatic. If you have to do a hard sell to convince your stakeholders to respond to risks, it's likely you who are doing something wrong.

Plan, but be willing to change your plans

Prior experience in a neighborhood helps kids to plan their trick or treating routes to receive the maximum goodies for the minimum effort. But it is also possible that over the course of a year, the treat supply dynamics can change as people move. As such, it is a good idea to stay in touch with our buddies so that if they are getting handsomely rewarded on their streets while ours is a bust we can head their way.

A plan is only as good as the assumptions supporting it. When those assumptions have been invalidated, we need to be egoless about the plan itself and change it to better reflect reality.

Follow these simple lessons if you'd like the project management Great Pumpkin to reward you this Halloween!

One of the misconceptions I like to clear up with learners in the project management fundamentals courses I teach is that there is no such thing as a "waterfall" or "agile" project. Stakeholders might choose to use a predictive or adaptive life cycle or specific methods associated with either of these approaches for delivering the scope of their project, but using these terms as an adjective furthers the erroneous perception that there are only two options available to us. In reality, there are an unlimited number of ways of delivering a project when you consider the wide variety of method, tool, role and life cycle choices available.

But let's consider the purely predictive life cycle. A basic assumption of this life cycle is that when we have completed one stage of delivery there won't be an opportunity to return to that stage again.

But projects are unique endeavors possessing uncertainty. Even operational processes which are in control will experience common and special cause variation.

And as the complexity of a project increases, the level of uncertainty does as well. How many times have you been on any moderately complex project where nothing substantially changed over its lifetime? Faced with change, if we don't provide the opportunity to iterate back, the project is unlikely to meet all of its success criteria. Any project manager that stubbornly refuses to alter their plans to address the new reality they are facing won't be in that role for long.

Even Dr. Winston Royce had provided this caution in his 1970 paper "Managing the Development of Large Software Systems" about a pure waterfall approach without iterations: "I believe in this concept, but the implementation described above is risky and invites failure." As readers of the PMBOK Guide know, the processes in the PMBOK framework are iterative in nature. Finally, the term "waterfall" itself is inaccurate as going over one of those in real life is usually a one way trip!

So the question is not whether or not we will incorporate change into our plans, but rather about the level of effort which we should expend on planning up front. With projects where uncertainty is low, team member experience is high, and we are able to control many sources of variation, we can develop high confidence plans for the entire life of the project whereas with others, a rolling wave approach to planning is wiser with our time horizon for detailed planning being defined by how foggy the road is in front of our headlights.

Tracking and reporting risk information is a standard part of any project management approach.

How we do it will vary based on the context of the project being managed, the needs of the stakeholders and the policies or standards governing the practice, but in general, a risk register is a common standalone artifact, RAID log section or information radiator.

As with all other information, capturing it for the sake of doing so is pointless. Minimal sufficiency should be the goal we strive to in terms of meeting the informational needs of your stakeholders but more important, helping risk and risk response owners to effectively address identified risks.

Given this, is it possible to come up with a minimum set of risk information elements which we'd want to capture on most projects?

Here's my list:

• Description: without this, you don't have a risk! Beyond that, we need to ensure that the description identifies the uncertain event clearly and provides a specific understanding of the immediate impacts if the event occurs. If it doesn't create the desired sense of urgency you'd like to see, it should be rephrased.
• Probability and impact: while it might be tempting to combine these two attributes into a single severity or priority value, doing so would rob stakeholders of information which would help guide their behavior towards the risk. While a low probability, high impact risk might be calculated as being of moderate severity, a stakeholder with a low tolerance for risk might act in a different manner if they understand that the impact is high than if they assumed it was moderate based on the combined rating.
• Response: PMI and other associations have defined lists of risk responses but what is of greater value to response owners is understanding the proposed plan for addressing the risk. They have the right to modify the recommendation but at least they should see that the team has done its homework. For risks which are only going to be monitored (e.g. put on a watchlist), that recommendation should also be documented.
• Response owner: When I've reviewed risk registers for other project managers, I rarely see a response owner identified. While sometimes this responsibility might fall on the project manager or the risk owner, that is not always the case. Why wait till a risk is realized to assign response ownership?
• Status: At a minimum, this field should distinguish between those risks which are identified but not responded to, those which have been responded to and are being monitored, those which have occurred and might still recur, those which have occurred and can be closed, and those which are closed without occurrence. These status values will simplify the reporting process as well as enabling the team to evaluate the effectiveness of their overall risk management strategy.
• Updates: This is a journal which can be used to track changes to the risk, capture risk response status updates and to also serve as a reminder to the team if excessive time has passed since the risk was last reviewed.

Am I missing any? Are any unnecessary? Please let me know in the comments below!

Unless you've been living under a rock for the past few months, you've likely run into the term the "Great Resignation". If you work for a mid to large-sized company, chances are at least a few of your staff have decided to exit stage left and only rarely will these departures not cause some business impacts.

So what should you do if you are managing a project and discover that one or more of your team members will be departing prematurely?

First, allow yourself a little private time to feel the frustration, fear, stress or anger which are normal emotions when we are surprised by unpleasant news. Don't act on the initial impulse to confront the folks who are leaving or their people managers as you might say something you'll regret later on.

Take the time to fully understand the specifics including how soon the team members are leaving, how much time they have to spend on knowledge transfer and other transition activities, and whether there is any potential to bring them back on a part-time or contract basis to complete their work on the project.

Assuming the resignations are common knowledge, meet with the remaining members of your team and listen to their fears, uncertainties and doubts. Just as you needed time to work through the initial strong reactions to the news, they will need to do the same. If you are concerned about a domino effect of other team members following in the footsteps of the departing folks, meet with their people managers to determine how best to avoid realizing this risk.

Working with your core team, determine the impacts and options for meeting your project's objectives. In some cases, your remaining team members might be able to take on the work activities of those departing, albeit with schedule, cost and potentially quality impacts. In other cases you will need to request replacement team members to get the work done.

This is also a good time to review the relative priorities of your project's constraints so the options you and the team come up with take those into account. It is important to be realistic as there's a good chance other projects and operational activities have been impacted so having a backup plan (or two) if your desired option isn't feasible is advisable.

While doing this re-planning, revisit the work assignments to see if there are opportunities to reduce the impact if you were to lose other team members later on in the project as your senior stakeholders likely subscribe to the motto "Fool me once, shame on you. Fool me twice, shame on me!".

Finally, do some soul-searching. Was there something which you did or didn't do which might have prompted the departures? If there is an opportunity to meet with the departing team members, do so, and seek to understand their reasons for leaving.

Losing team members is a common problem on projects. While it is unfortunate, how you handle such issues is a good opportunity for you to demonstrate that you are a professional, disciplined project manager.