In a previous post I made the comparison between a recent road trip and variance. My point was that as with the two directions of my road trip, we may encounter early variance in a project (front-loaded) before stabilizing, or switch from a stable start to late variance (back-loaded). I represented the two cases of variance this way, using the analogy of my road trip from Bellevue to Long Beach and back.
From the project manager's perspective, how might you prepare to respond to either variance pattern? To help answer this, I'll turn to my favorite mental model, the Project Triangle:
If you need a refresher on the Project Triangle model, check this out.
Time and front- or back-loaded variance
Applying time buffer (i.e. slipping the schedule) may be a common response to back-loaded variance, but would be very difficult to apply in response to front-loaded variance. (And I should say, for many projects extending the finish date is no option at all.)
I've worked on projects that encountered front-loaded variance and we typically interpreted them in these ways:
- This variance is just our normal startup hiccups and things will settle down.
- This is real variance and we'll (somehow) make up for it later in the project.
In either case, adding more time to a project in response to early variance is often not a palatable option.
For back-loaded variance, adding time to the schedule may be the only viable option--especially with fixed-scope projects. What I have observed is that taking a schedule slip seems to be an "out of the blue" idea when it's implemented, so may be sloppy in its implementation. One alternative is a "plan B" approach where the time buffer is defined well in advance (as a risk response strategy), and implemented whenever predefined trigger points are reached. If you're going to slip a schedule, you can make it a chaotic fire drill or do it with some degree of intent.
Scope and front- or back-loaded variance
By "scope" I mean either project scope--the work packages defined within the schedule, or deliverable scope--the measurable attributes of the project's end result.
Adjusting scope in response to front-loaded variance may be likened to adjusting time--an organizational throat-clearing. "Now that we're deeper into this project, we know more about our capabilities/the deliverable and should adjust based on this new knowledge." This is arguably a smart move. Call it "agile" and you may even sound edgy.
Adjusting scope in response to back-loaded variance however is more likely to be a hatchet job and/or fire drill. To the degree a project has a fixed scope, redefining it due to variance may lead to short-term project success but longer-term failure.
Cost and front- or back-loaded variance
By "cost" I mean mostly the cost of work resources such as the knowledge workers I work with.
Adjusting cost in response to front-loaded variance may be a legitimate fine-tuning of resource skills and capacity based on immediate data (i.e. actuals). This is certainly a smart strategy. I think it's smart as a project manager to acknowledge with the team that we'll know more later than we know now, so of course we'll act on that knowledge. There should be some basic boundaries around potential reactions though to avoid growing a sense of fear of the unknown within the team.
Adjusting cost in response to back-loaded variance almost always translates into "throw more bodies on the fire" and often produces worse results than holding steady. For knowledge worker projects in particular, it's likely that adding more resources late in the project when variance is highest will result in more confusion, more complex workflows, and of course the ramp-up penalties for the newbies as well as their assigned mentors. The project may fizzle out before the benefits of the additional resources arrives.