Planning horizons

I know of an IT department with just three full-time developers. Yes, just three. So what do you do with a team that size? What they are doing is developing lots of small enhancements and defect fixes, and not much else. They don’t have enough people to do much else. Which got me thinking…

Any decent IT department needs to consider three planning horizons – what I call the three 5s.

  • Five days – you have to have someone resolving that backlog of production glitches, those occasional emergencies that occur from time to time, and all those minor enhancements that have been irritating the business for months. Call this the Production Support Team.
  • Five months – the Project Teams work in this area, tackling that prioritised portfolio of projects.
  • Five years – someone needs to be thinking about what your platform is going to look like in five years time and, more importantly, doing something about it. For this you need a Strategy Team.
  • If you don’t have three separate groups of people dedicated to those three horizons, something is missing in your organisation, because you can’t survive long without all three.

    Without the Production support team, project teams are forced to include production bugs and small changes into their project scope. Which means they take longer to get delivered. A lot longer. Because when it comes to prioritisation, the project sponsor cares a lot more about his project than someone else’s small enhancements, so they go to the bottom of the stack and are frequently not delivered at all.
    Without the Project Teams, you are limited to having the Production Support team working on only the smallest of work requests (like the department I mentioned at the start of this post). Anything over a few weeks is too big to handle because it would require more people than you have, and besides, nothing else would get done during that time.
    Without the Strategy Team, the other team/s are always thinking short-term, not caring about maintainability, architecture, or upgrades in coding standards, languages, design patterns etc. So you start building up technical debt to the point where you have an inflexible legacy system that is ponderous to maintain.

    Having three separate, dedicated groups of people mean that you can simultaneously deliver the urgent fixes, and small enhancements, as well as the bigger, more valuable projects, and define long-term technical strategy, monitoring adherence and progress along the way.

    So, does your IT department have three separate areas? Or if you have another way of solving this problem, I’d like to hear it.

    Advertisements

    About aterny

    Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
    This entry was posted in Agile and tagged , , , . Bookmark the permalink.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s