Project Management

Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

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

Think top-down and bottom-up for agile transformations

Why project work doesn't get completed early...

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

How does psychological safety relate to holding space?

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.

Posted on: October 25, 2020 07:00 AM | Permalink | Comments (3)

Think top-down and bottom-up for agile transformations

A question which I'm asked regularly during my classes is what the best place is to start an agile transformation within a company? Given a choice, I'd prefer to use the cop-out (but correct) answer "It depends", but otherwise I usually respond that you'd want to do both a top-down and bottom-up approach simultaneously.

A common approach for major organizational changes is to start at the top with executive leadership, creating a coalition of commitment and support towards a shared vision for the future. This is critical with agile transformations for a number of reasons:

  • Delivery teams don't work in isolation and hence buy-in to change how things are done will be needed from all supporting areas including human resources, finance and procurement.
  • There will be the need for funding investments such as training, coaching, tooling and potentially even staffing new positions.
  • Without changing existing portfolio intake practices and performance measures (e.g. shifting from a focus from maximizing utilization to maximizing value), it will be hard to achieve the full benefits of the transformation.
  • To shift the established behaviors of middle management towards an agile mindset, the executive team needs to model the desired target behaviors first. Not only will the executives need to be coached to get there, they must also agree to hold each other visibly accountable to this new way of working.
  • There needs to be a unifying vision for the transformation as well as a roadmap for how to get there. The executive team must be fully engaged in the creation of these key deliverables.

But there will also be the need to have engagement at the delivery team level. If individual team members are comfortable with how things are working and have no sense of urgency about the need for change, then their support will be superficial. Their buy-in is needed to:

  • Develop the details of the new ways of working and inspect and adapt those over time.
  • Feel comfortable designing and conducting experiments and having the occasional setback with those.
  • Be willing to take on new roles and responsibilities.
  • Be open to providing stakeholders with a greater level of transparency into their work and work flow than they have been used to.
  • Collaborate openly with contributors from other functional areas whom they previously might have just cooperated with.

While these outcomes are needed, a key benefit of taking this top-down & bottom-up approach is that it will create a "sandwich effect" squeezing those middle managers who are unwilling to change how they work. Without that outcome, it is unlikely that an agile transformation will succeed.

Posted on: October 18, 2020 07:00 AM | Permalink | Comments (7)

Why project work doesn't get completed early...

I usually advise my students to encourage their team members to not provide padded work estimates, but rather to make schedule contingencies visible and tie these contingencies to milestones rather than to individual activities.

This is intended to counter the potential confluence of Parkinson's Law (work expands so as to fill the time available for its completion), Student Syndrome (let's wait till the very last possible moment to start an undesired activity) and Murphy's Law (anything that can go wrong will go wrong).

While this behavior might be true in some circumstances, it is based on a rather Theory X view of the world. Student Syndrome hurts no one other than the student procrastinating on starting their homework assignments or preparing for an exam. With projects, the impact of delays from one team member ripple downstream to others so with the exception of that small minority of Homer Simpson-like workers most of us want to do a good day's work.

So if the fault doesn't lie with the individual contributors, where else could we look for answers?

Today's Dilbert cartoon provides us with better root causes for this behavior - the system which people work in or the managers they work for.

How could the system affect work completion? Poorly thought out performance measures are one way:

  • If staff are measured based on utilization, then completing work in less time means they are either going to be reprimanded or handed more work which they might not be able to complete by working a sustainable pace.
  • If they are paid based on the hours they work, they could be tempted to work to plan to avoid being financially penalized for completing early.
  • If they are measured based on the accuracy of their predictions (I.e. they are penalized for being early or late), then the work will tend to be completed exactly on time.
  • If they are forced to fill out weekly timesheets and the process to do so is onerous, it might be easier for them to just copy planned time over as actual time within their time recording system.

Managers can also inadvertently cause staff to complete work on time, but rarely early by:

  • Penalizing team members who complete work early on their future tasks by setting unrealistic target dates
  • Giving them additional projects or operational activities to do rather than letting them use that slack time productively
  • Breaking their focus by interrupting their work with urgent but un-important tasks

If we recognize that project activity durations are more likely to follow a lognormal distribution than the nice symmetrical normal distribution which we hope for, then we should praise team members for completing work early (within quality, safety, health and other constraints) rather than introducing impediments which discourage them from doing so.

Posted on: October 11, 2020 07:00 AM | Permalink | Comments (7)

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."

Posted on: October 04, 2020 07:00 AM | Permalink | Comments (13)

How does psychological safety relate to holding space?

I'm always happy to learn something new when it relates to the topics which interest me and even more so when it is something which I should have run across long ago. During an event this week, a participant shared that their secret facilitation power is holding space for the participants. I must have been living under a rock for the past three decades as I'd never heard of this term even though it is a core component of the Open Space approach which has had significant influence in the broader agile community.

When holding space was first described to me, it sounded almost identical to creating psychological safety within a team but after reading further I feel that there is an overlap between the two approaches rather than an equivalency.

While there is no single accepted definition for holding space, here are two frequently referenced ones which helped me better understand the concept:

  • Heather Plett: "It means that we are willing to walk alongside another person in whatever journey they’re on without judging them, making them feel inadequate, trying to fix them, or trying to impact the outcome. When we hold space for other people, we open our hearts, offer unconditional support, and let go of judgement and control."
  • Adam Brady: "Holding space is a conscious act of being present, open, allowing, and protective of what another needs in each moment."

What are some of the similarities between the two concepts?

  • Not judging or ridiculing others
  • Providing an environment where people feel safe to take risks even though they know that there is a chance that they might fail
  • Enabling team members to express vulnerability or to allow their emotions to surface
  • Being inclusive of others' diversity of opinion
  • Giving others the respect of our full attention when they are communicating
  • Demonstrating genuine compassion with others

But there appear to be a few differences too, including:

  • Holding space applies applies to oneself as much as it can be applied to a team as it is difficult to hold space for others if we haven't done the same for ourselves. Psychological safety is normally considered as a team characteristic.
  • When we are part of teams which are operating at higher levels of psychologically safety we are more likely to provide candid constructive feedback to other team members in a timely, direct but empathetic manner. This does not appear to be explicitly covered within holding space.
  • In "Open Space Technology: A User's Guide", Harrison Owen writes "As the world would see it, the ultimate facilitator will do nothing and remain invisible". Ego is taken out of the equation. While this is important when one facilitates an event, psychological safety doesn't require that team members bury their egos, just that they should be mindful of them when they interact with one other.

Our abilities to hold space and to create psychologically safe environments are complementary but are both equally critical to becoming effective leaders.

Posted on: September 27, 2020 07:00 AM | Permalink | Comments (5)

"Never hold discussions with the monkey when the organ grinder is in the room."

- Winston Churchill



Vendor Events

See all Vendor Events