A pilot project is not always the best way to start your agile journey

Many of us would agree that when you are trying to implement a large change, start small. Just as it is easier to swallow a small pill than a huge one, the ability to adopt and sustain change is often simpler when the change involves baby steps.

This approach of small incremental changes applies to agile as well. For example, the improvement experiments which a team identifies during a sprint retrospective should be small to provide quick feedback on whether or not it they are worth pursuing further.

But when I read a recent HBR article by Ron Ashkenas and Nadim Matta on challenges with scaling a successful pilot project, it reminded me that this principle of starting small may not always work with agile transformations.

In the article, the authors listed some key challenges with successfully applying learnings from a pilot project to a larger context including:

  • Reluctance from the mass market of stakeholders who are being asked to work in a different manner if the target audience for the pilot is those stakeholders who are likely to be the most receptive to the proposed changes. This is a “crossing the chasm” problem.
  • Avoidance of organization blockers or impediments is relatively simple in the context of a single project but is geometrically more difficult as the scope of the change increases.
  • Struggle in trying to lift and shift practices and learnings from the pilot project to the varied contexts of multiple different projects.

To this list, I’d add one more.

The primary source of delivery uncertainty to most knowledge-based projects is the predictable availability of the right people with the right skills and the right time. With a pilot, it is possible to stack the staffing deck in our favor by pulling skilled people out of their normal roles to work on the project.

If we don’t replace those staff with temporary backups, it impacts the capacity of each of the teams they were part of and likely won’t improve our relationships with the leaders of those teams. But worse, when the pilot project is over and we start patting ourselves on the back for the improved delivery outcomes, the main reason things went well is not because we were agile, but because we allowed people to focus on one work stream rather than engaging in their usual level of multitasking. When we then try to expand our rollout to multiple projects, the results are less promising because we haven’t addressed how much concurrent work we are taking on.

This shouldn’t discourage you from taking a pilot project approach with your agile transformation, but before promoting the learnings from that pilot, address fundamental work management issues first if you wish to achieve sustainable delivery benefits.

Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , , | Leave a comment

What Saturday morning cartoons taught me about project management

(Image credits: Warner Bros. & Chuck Jones)

When I was a small child, one of the things I looked forward to every weekend was the chance to watch Saturday morning cartoons on TV. Unlike today where where a vast variety of kids programming is available around the clock, in those days such content was usually limited to that one special day each week. While the visual quality of cartoons has improved immensely, there is something about the Looney Tunes, Merrie Melodies and Hanna-Barbera short productions which still makes them entertaining today.

Thinking back to some of the more popular cartoons, here are some of the project management lessons which could be gleaned from them.

Perception IS reality

Penelope Pussycat is a black feline who accidentally ends up with a white stripe of paint down the center of her back. This has the unfortunate side effect of attracting the amorous overtures of Pepé Le Pew, the skunk. Pepé’s perception of Penelope results in a number of embarrassing encounters for both of them. Penelope repeated attempts to cure Pepé of his inaccurate perceptions are to no avail.

Stakeholder perceptions on how our projects are faring might be inaccurate, but if we are unable to convince them of the project’s actual status, then regardless of how much objective, quantitative evidence we present, they will believe what they perceive to be true.

Persistence (to a point) is propitious

Wile E. Coyote could have given up on attempting to catch the Road Runner after his first failed attempt. But he chose to follow that adage “If first you fail, try, try again”. But in spite of the creative genius of the folks at Acme Corporation, a conspiracy of gravity, explosive mishaps, and Newtonian physics prevent him from fulfilling his objective.

While we shouldn’t follow Homer Simpson’s advice (“You tried your best and you failed miserably. The lesson is, never try.” ), we should also learn the lesson which Wile E. Coyote never learns that repeated failures with a specific approach or goal might be a sign that it is time to pivot in a more favorable direction.

Don’t let business get in the way of interpersonal relationships

Ralph Wolf and Sam Sheepdog have a very interesting dynamic.

After they each punch in for work, Ralph tries as hard as he can to catch some helpless sheep whereas Sam, in spite of being a somewhat lazy sheepdog, is always able to prevent him from doing so. During working hours, Sam frequently punishes Ralph when he catches him in the act of abducting a sheep.

However outside of normal working hours the two appear to have a very amicable relationship, greeting each other pleasantly with a “Mornin’ Sam” and a “Mornin’ Ralph” at the beginning of each working day. They understand that in spite of their differing objectives, they are both just doing a job.

Misaligned goals and tight constraints result in increased stress, so conflicts between project managers and stakeholders such as functional managers are bound to occur. While project success should be our goal, this shouldn’t be at the cost of interpersonal relationships. Assuming we will continue to work together after a project ends, we need to ensure that the friction is focused on the problem and not the people.

Why not kick off one of your upcoming project meetings by streaming one of these short cartoons?

Even if the project management lessons are not realized by the attendees, the levity should help to raise everyone’s spirits!

Categories: Project Management | Tags: , | Leave a comment

Context is critical for learning lessons

Regular readers of my blog will know how much I loathe the term “lessons learned”. I’ve written and spoken frequently about implementation issues such as waiting too long to identify them, storing them in a manner which makes accessing them challenging and not responding to them in an appropriate manner. One of the more common problems I have encountered when reviewing lessons is a lack of contextual information to enable a reader to understand whether a given lesson is going to help or hinder them.

This is not a concern when the lessons are going to be applied to the same project in which they were identified. For example, if a team identifies a learning from a retrospective and decides to apply it afterwards, the likelihood of context drift is low, hence the lesson is still apropos. It is also not as big a deal if lessons are shared verbally, for example, through a Community of Practice meetup. During such events, if a participant shares a learning, contextual information will usually be shared through the normal back and forth discussion about the practice.

But when practitioners are reviewing lessons captured in the past without the benefit of access to the originator, if context is absent there is a much greater likelihood of practices being applied in situations where they won’t be helpful (i.e. a false positive) or practices being discarded based on the incorrect assumption that they weren’t applicable (i.e. a false negative). In both cases, an opportunity to benefit from organizational knowledge assets is lost.

So what context might we capture?

At a bare minimum, we should record when the lesson was identified, on which project and by whom. Doing so will take the least effort on the part of the lesson identifier and the lesson curator (the person who is responsible for distilling “raw” lessons into published knowledge). With this, an interested reader has the ability to follow up with the person who identified the lesson to get the missing context.

Unfortunately, memories do fade with time and people will move into new roles or leave the company so such minimalist context may be insufficient. Time and cost permitting, the following additional types of contextual information could be captured:

  • Quantitative metrics about the project such as its duration, cost, and peak staffing level
  • What stage or phase of the project is the lesson applicable
  • What type of life cycle was used to deliver the project (e.g. deterministic, adaptive, iterative)
  • A categorization of the project’s scope (e.g. process engineering, launching a new product, building a dam)
  • Specific background details about the lesson which may have been stripped away from the main description through the process of scrubbing it to be useful but shouldn’t be discarded entirely

This seems like a lot to capture and will take effort to do so. But if we remember that lessons are an investment in improved future project outcomes, the returns will justify the costs of doing so.

Categories: Facilitating Organization Change, Process Peeves, Project Management | Tags: , | Leave a comment

Blog at WordPress.com.

%d bloggers like this: