From Backlog to WIP Part One

So let's assume you've been following my recent blog posts and have put in place a "Three Column Planning" or "TCP" system as I've outlined. You've got a growing list of things you could work on (your "Backlog" or "Project Pool"), a nice tidy list of what you're actively working on (your "Work in Process" or "WIP"), and you're starting to see a steady stream of items hit the "Done" column. Today I'd like to touch upon when you should move something from your Backlog or Pool into your "WIP".

The first thing to keep in mind is that this is a business decision. In my prior blogs I've talked about "drive-bys" where the VP of a given division pops his head into your office on his way to a meeting and drops an IT project on your desk in a high-level 20-30 second description. If you've implemented the TCP system appropriately, these encounters are very different now and the VP's dropping by are very clear all they are doing is giving you a head's up and not putting something directly into your WIP.

So the first step is to give your internal clients a good sense of your capacity and how much of it is dedicated to "keeping the lights on" and how much can be deployed to new projects--your reserve capacity. In most cases, it becomes clear you and your team can't do everything anyone in the organization can think up right now. Some things will need to wait. Others might not happen at all. Priorities need to emerge.

Too often this process is delegated to the IT Director or CIO/CTO along with project execution. When business unit managers/VP's/members of the Executive Team can come up with an idea and dump it on IT without having to think through and articulate the business value this new IT widget will provide, the opportunity cost of doing this instead of some other Executive's pet project, the budget and other resource implications, etc. it just means someone else has to because you can't do everything. Usually this means the IT Director spends time trying to read minds and keep everyone happy. I suggest that's too much to ask of an IT Director or CTO. I suggest these are questions that need vetting by the Leadership Team. Peers need to work together to share a finite amount of IT resources and to prioritize according to what's best for the enterprise--not necessarily for their division.

In an upcoming blog post I'll describe the process I've implemented with my clients that seems to work well. As a preview, it involves getting all stakeholders around a table or some online collaborative workspace to weigh proposals next to one another. For today, I just want to make the point that the IT Director or CIO/CTO should certainly have a seat at the table, but they shouldn't be driving the boat on this yet. That comes after the next step when the business is clear on what IT initiative we should be working on right now.