Easy in theory, difficult in practice

After I had reviewed how Monte Carlo simulation could help a team to understand the distribution of potential schedule or cost outcomes for a release or project, one of the learners in the class I was teaching pointed out that while such techniques can be helpful, they are only as good as the inputs provided.

When Monte Carlo is used in project contexts, these inputs are usually expected duration or cost ranges for the activities. If those ranges are inaccurate the resulting outputs will be useless and all it takes is one poorly estimated activity to skew the entire distribution curve. And even when reasonable estimate ranges are provided, if the wrong probability distribution types are selected for those activities, we wouldn't get a usable output. For example, if the default provided is a normal (i.e. bell curve) distribution and we are evaluating an activity which is primarily people-driven, in some cases a log-normal distribution might be more appropriate as the worst case could tail off towards infinity!

Such garbage in-garbage out challenges are not restricted to simulation tools alone. Take Expected Monetary Value (EMV) which can be used to quantify the expected impacts of uncertainties. EMV can help to define contingency amounts and could be used in combination with decision trees to support decision-making. While it is a powerful tool, if the estimates for risk impact and probability are invalid, the outputs will be useless.

Even a tried-and-true technique such as parametric estimation will produce the wrong results when the input data is suspect or the underlying assumptions supporting the use of the model are invalid. For example, if we use a formula to calculate how many cans of paint we will need based on wall measurements, unless that formula also incorporates factors such as the desired number of coats or what the wall's surface is made of, the formula might produce bad results.

How do we overcome such challenges?

Expert judgment on the part of the people performing the activities helps. Your own past experience can help to sanity check the estimates you receive. Independent consultants with deep experience in the work being done or published historical data for similar projects might offset knowledge gaps with the first two approaches.

But all of these methods are predicated on the assumption that the context of our new project is similar to what we or others have experienced before. Unfortunately, the accelerated pace of contextual change resulting from factors such as advancements in technology or environmental disruptions means that past results are more frequently not indicative of future performance.

We might still be able to use the same tools as before, but we will need to design and implement experiments to tell us if the underlying assumptions supporting their usage are invalid, build flexibility into our projects and coach our stakeholders to increase their resilience for plan pivots.

Faced with complexity, trust but verify (as early as possible) becomes our mantra.

I wrote an article a few months ago about the importance of securing contingency reserves, so I didn't expect to return to this topic so soon. However, earlier this week a discussion thread on Projectmanagement.com prompted me to write one more.

In that thread, the contributor asked which methods could be used to meet milestone dates when all schedule contingency had been stripped out by a client. The project manager is well aware of the risks of proceeding without contingency, but the client is adamant.

Contingency exists to protect a project's success criteria from the impacts of realized negative risks. In any project schedule, the likelihood that each activity lying on the critical path for achieving a milestone will be on time or early gets progressively smaller as the number of activities and parallel non-critical network paths increases.

This is the rationale supporting Rule #74 in One Hundred Rules for NASA Project Managers: "All problems are solvable in time, so make sure you have enough schedule contingency, if you don't, the next project manager that takes your place will."

So when something goes wrong with one of those critical activities and it appears that the milestone date can't be achieved, what do we do then?

If it isn't possible to negotiate a reduced scope with the client, the schedule compression options of crashing or fast tracking could be considered assuming we have sufficient discretionary dependencies, effort-driven activities exist, or funding is available to attempt one or both of these tactics. But we must remember that there is always a cost associated with such techniques, either in terms of increased expenditures or increased risk.

This is closing the barn door after your prize-winning stallion has raced off into the sunset.

Being unable to secure schedule contingency is just one example of risk management failure. It is also an example of project management weakness as described by Neal Whitten almost twenty-five years ago.

But it goes beyond this.

Practitioners have argued about the need to recognize project management as a profession. If so, a core require is professional responsibility on the part of practitioners of a profession which is why PMI identifies Responsibility as one of the four values within its Code of Ethics.

When we knowingly accept an action from a client or sponsor which puts our projects in harms way, is this demonstrating responsibility? Is it sufficient to merely have the risks introduced by this action captured in a risk register, communicated to stakeholders and even signed off by the right governance bodies? Risk acceptance is a valid risk response strategy, but is it appropriate when faced with a high probability, high impact risk?

If we want to demonstrate professional responsibility, once we have have exhausted our attempts to influence the client, we need to escalate to an appropriate authority who will support us in doing the right thing. And if no such support is willing or available, we need to decide whether proceeding against our better judgment is a bridge too far.

If we don't draw a line in the sand when it comes to the values and principles of a PM role, do we deserve to have project management considered a true profession?

I've previously written about the importance for an organization's operational capabilities which support delivery capabilities to evolve when there is a move to increase business agility. Whether it is procurement, finance or human resources, all supporting areas will need to align with delivery teams' new ways of working.

Scott Adams has perfectly nailed one of the biggest impediments to increasing agility in his Dilbert cartoon above. When the Pointy Haired Boss states that good team work will lead to successful outcomes, Dilbert reminds him that their current compensation system is designed to stymy team work by causing individual contributors to vie with one another for a limited amount of funding.

Bad managers can certainly discourage their staff from working well as a team through their own toxic behaviors such as purposely chumming the team waters to entice "sharks" to attack the weaker team members or by playing favorites, but even well intentioned managers can sow divisiveness through recognition tactics such as employee of the week or month awards.

But such poor behavior pales in comparison to the negative effects created by a company's compensation and performance recognition systems.

If those systems provide people managers with complete authority over compensation evaluations, not only could this encourage biased decision making, but it also provides no incentive for their staff to prioritize team success over their own success.

Mandating the use of tools such as 360 degree feedback might provide some peer-level input into the process, but having this done semi-annually or annually to align with a formal performance review means the data quality will be affected by the same issues as we occur when we wait till the end of a project to identify lessons learned.

This also doesn't avoid the risk that promotions ignore mounting evidence that someone doesn't work well in a team setting, especially if the key inputs into the promotion decision come from the people manager and the candidate themselves.

Finally, even if well-meaning leaders want to recognize teams as a whole, they may have no budget to do so as all discretionary funding is fully allocated to individual recognition programs.

To resolve this, systemic changes such as the following ideas could be considered:

1. Request and evaluate team-level feedback on individual contributors. This could be done at regular intervals or could be tied to specific milestones or phases of a project. People managers should be encouraged to review this feedback and discuss findings during the one-on-one meetings with their staff.
2. Make team-level feedback a mandatory component of an individual's formal performance evaluations. Regardless of the weighting given to this factor, it should not be possible for someone to be financially rewarded for acting only in their best interests.
3. Make team-level behaviors a mandatory component of the evaluation process for promotions to avoid the risk of poor team players becoming worse team leaders.
4. Balance the allocation of recognition funding between individual and team budgets.

If we want our staff to behave like team players, we need to recognize and compensate them accordingly.

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.

(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!