A new, better, year is slowly coming. Of course focus of most companies is still set on closing current one, but we also start detailed budgeting for 2009. We think which projects we’re going to do. We revise roadmaps for our products. We look for changes in business environment to find new niches to fill them with our software.
That’s the time when we look at projects from bigger perspective. These aren’t simple post mortems anymore. We look rather for coarse-grain issues instead of small details for fix. Why the heck, after 5 quarters, the key project isn’t yet completed? Which reasons are beyond our control and where we can look for improvements? How it maps on future projects we plan to do next year? What is the impact on budgets and why so darn negative?
Usually that kind of thinking is forced by setting/adjusting strategy process but it’s very valuable. Most of the time we try to go into lowest possible level to catch what’s going wrong omitting really serious issues. When you come back to closed project after some time and try to make quick high-level revision you can come to quite different conclusions.
Maybe it wouldn’t be possible to make in 5 months, even if we implemented every single idea which had come out during retrospectives session. Maybe it’s high time to do serious redesign in the architecture if are going to catch up deadlines we’re going to have. Maybe with current project teams we just don’t have enough capacity to satisfy our extraordinarily productive colleagues from sales department.
Looking at both past and future projects with long-term perspective is important. It allows you to avoid some icebergs. If you look just on the closest surroundings you won’t have enough time to react before you hit hard those icebergs. And then you’ll end up analyzing during post mortem whether the rescue action was efficient.