Chris Heisel

Life is full of limitations: No parking, no running, no diving, [no stairway](http://www.youtube.com/watch?v=WStE470Nu4s) etc.

One of the keys to project management is knowing and embracing the limitations of a project. One of the other keys is being able to help others see and embrace the same limitations.

In software development there’s been a lot of talk about “Fast. Cheap. Good. Pick two”. But I think the most common [iron triangle](http://en.wikipedia.org/wiki/Project_triangle) we face is actually **”Scope. Schedule. Quality. Pick two.”**

Very few clients would ever actually pick Scope and Schedule, and say “Meh. To hell with quality.”

So the real limitations of our discipline are **Scope** and **Schedule**, because almost no one wants an on-time piece of garbage, or an incomplete piece of garbage.

There are two strategies that I use to embrace these limitations:

### Kanban (fixed scope)

If you haven’t heard of Kanban, I recommend you read up on it as it really is a great system. Here’s just [one quick tutorial](http://www.kanbandistilled.com/), and my [running list of links](http://delicious.com/chris.heisel/kanban).

For me, the essence of Kanban is fixed scope, but flexible schedule. Sure, you can quote a [lead time](http://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-time/) — an average of how long it’s taken features to go from the backlog all the way to done in the past — but that’s an estimate, not a commitment.

This works great if you’ve got clients who are flexible enough to accept a fairly open-ended delivery date.

### Scrumban (fixed schedule)

[Scrumban](http://leansoftwareengineering.com/ksse/scrum-ban/) is a great transitional step for teams and clients when trying to go from Scrum/Agile or, *shudder* [Waterfall](http://www.waterfall2006.com/), to Kanban.

In Scrumban you’ll fix a schedule, a release every two or three weeks similar to Scrum. But unlike Scrum you **don’t fix the scope** for the sprint.

Instead you work with the client and the team to come up with a prioritized backlog of items for that sprint.

Work during the sprint is popped off the top of the backlog stack, so that the most important work (as judged by the client) is done first.

If the backlog stack gets too small, then, aside from celebrating your productivity, the team and client can regroup and fill the backlog up again.

If the backlog isn’t completed by the end of the sprint, that’s OK because we decided to **fix schedule (and quality), not scope**.

In consultation with the team and the client, you can take the remaining items and start the next sprint with them, or throw them all out if priorities have changed!

Show your system administrator a box running at 100 percent system utilization.

If you can find one who thinks it’s a good thing, then you’ve got yourself a bad system administrator. A good sysadmin knows that if a box is pegged at 100 percent, then it can’t handle any more traffic and it’s likely to fall over at any moment.

Show some managers an employee working at 100 percent. Many will say, while patting themselves on the back, that must be a great worker who’s been properly motived by a good manager… wink.

But some, myself included, would think “there’s an employee who can’t handle any more traffic and is likely to fall over at any moment.”

Machines can’t run at 100 percent all the time, and neither can humans. That’s why we have slack time.

Slack time benefits employees by giving them time to cool down and recharge their creativity between projects. Managers benefit by constantly having a pool of refreshed, ready talent to handling incoming work.

Good managers should have a pool of low priority, deadline-less, “it’d be nice if” projects and tasks.

That way, when higher priority work has been completed and there’s down time, there’s something for folks to work on that can be easily set aside should an emergency arise, or new work arrive.

Editor’s note: This is the first in a series of posts where I’ll try and espouse on the some of the principals and practices of Kanban.