Who's schedule is it anyway?

Delivering new products on schedule is always difficult. At a recent Agile Software seminar, someone asked the crowd if they had ever had any home remodeling done. A lot of people raised their hands. Then she asked if it went according to plan; very few people raised their hands. The point she was making was: if something as well understood as remodeling can't go according to plan, what makes us think that we can do something that has never been done before, and predict the future outcome?

What can you do if your schedule is dictated? This happens in many or perhaps most organizations, and it's not going to change anytime soon. But you can manage it.

I remember an executive who once told me: once your organization gets to a certain size, you are expected to just figure out how to make the dictated schedules work. Whether this is successful or not depends on what percentage of your responsibilities has this attribute. If schedule is the number one requirement for 10% of your work, indeed, you should be able to manage it. Somewhere between that ideal and 100%, you will hit a wall unless you have a method to deal with the unsolvable problem.

I advocate for a highly transparent system to communicate the decisions you are going to have to make. Specifically, you really only have a couple of variables to play with to meet the schedule: resources and function (some people will say quality too is a variable -- depends on your environment). You may need to decrease function or adjust schedule in another area to free up resources to meet the schedule on a higher priority project. The transparency depends on your ability to rank the projects in a way that meets the corporate strategy. You will need to articulate and defend the priority of each; depending on the number of items, you may need a spreadsheet and a numerical method for ranking that can easily be explained. Once you have the ranking, you can justify hurting the lowest priority projects in function or time in order to fund the highest priority projects.

This seems self evident as I write this, but in practice it can be really hard to do when the project you are hurting is going to affect someone else's bonus. Once ranked, socialize the ranking before adjustments need to be made, so that your decision criteria has been vetted before you need to hurt someone's favorite project. To be really transparent, make sure the stakeholders of those lowest priority projects understand the risk involved.