Keeping “Why?” front of mind

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.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores)

Batches? We don’t need no stinking batches! (Or do we?)

Emphasizing flow through the reduction or elimination of batching of work items is desirable but this is not always efficient or practical.

So what are some of the factors which might force us to batch work items?

Whether it is equipment, materials or people’s time, constraints are a common reason for batching work.

Let’s say we wanted to build a fence for a customer. While it might be better for the home owner for us to complete the full work for one section of fence at a time so that if the work spans multiple days the homeowner would progressively be receiving value, we might be forced to dig all the post holes first because we only have the use of an auger on the first day.

Maybe we are writing a software application which needs to have both English and French messages and we have no one on our team who can do the translation. If we only have access to a translation service for a week, we might need to batch the translation of all the screen messages and until that is done we can’t ship the product.

Sometimes there might be a mandatory dependency that prevents completion of subsequent work activities till a preceding one is completed for the entire batch. When building a house, you would normally wait for the entire concrete foundation to be ready before we’d start building on top of it. When frosting a cake, it doesn’t matter if half of the cake is baked – we’d wait till it is fully baked.

Economies of scale or a minimum requirement on how many work items can be efficiently produced might be another reason to batch work.

If I want to bake cupcakes, although the cycle time to bake and frost one cupcake is likely to be less than that of completing a dozen identical ones, the costs of wasted energy and ingredients from doing them one at a time would start to add up. Unless I have a customer who is willing to pay me that much more to justify producing single cupcakes, I’m likely to make them in batches.

This applies even if I’m trying a recipe for the very first time. While the volume of ingredient wastage would be reduced by baking a single cupcake, the benefits of baking a batch are still greater.

Or maybe I need to print some color business cards for newly hired staff from a printing agency. While there would be a per card cost, the overhead costs of setup, proofing and shipping might justify waiting till there are a few new hires rather that printing each set individually.

While some of these factors might present opportunities for continuous improvement to our delivery process, others are unlikely to be reduced or eliminated. We may wish to avoid batch work, but we do need to be pragmatic and accept that context counts.

But what will our staff do if we don’t focus on their utilization?

Lean thinking encourages us to focus on maximizing value delivered to stakeholders rather than maximizing the utilization of the people, equipment or material resources contributing to value streams.

Two reasons for this recommendation are:

1. Systems which are run with no free capacity will have no tolerance for any impact which causes a greater utilization of resources than was planned, resulting in delays to the value we were expecting to deliver. While we don’t expect such special cause variations when managing operational processes, with project work, Murphy’s Law is often par for the course.
2. It is extremely rare that there is a perfect balance of the resources supporting every activity within a value stream. If we have one or more bottleneck, by insisting on maximizing the utilization of all resources contributing to the value stream we would end up overloading others or resort to unhealthy multitasking.

While managers might accept the above in principle, they might raise some concerns. If we don’t maximize the utilization of our team members, how will they be adding value when they aren’t contributing directly to the value stream or streams they are part of? After all, we are paying them for a full day’s work so shouldn’t we expect a full day’s work out of them?

While some managers might worry that their team members’ slack time will be misused for slacking off, there are multiple productive ways to use this freed up capacity including:

• Learning new things. When the focus is maximizing utilization for “billable” activities, learning often gets pushed outside of normal working hours. With down time during the work day, staff with spare cycles might use that time to increase the depth or breadth of their skills.
• Reducing bottlenecks. One way to reduce a knowledge bottleneck is to hire additional staff. This is a good short term fix but rarely does a company have sufficient funding to solve all of their bottlenecks that way. A better long term solution is to encourage methods for cross-training including job shadowing and non-solo work. Such approaches require that the existing staff have some free capacity.
• Making things better. Value streams don’t improve on their own. When left unattended entropy increases within them. Staff need to have some free time to identify opportunities for improvement, explore possible solutions and run experiments.
• Enhancing organizational assets. There is a cost to developing and enhancing templates, playbooks and other forms of codified knowledge. In previous articles, I’d written that one of the common challenges with traditional approaches to capturing lessons learned is that practitioners rarely have the time to curate and refine the “raw” lessons identified over the life of a project.

Without some free capacity, your team members might be inspired to quote Scotty from Star Trek: “I’ve giv’n her all she’s got captain, an’ I canna give her no more.“