IT Planning Issues

Several of the problems I’ve been noticing with all the Portfolio and IT Planning methodologies are the build-in assumptions in the process:

Most often in I see planning committees act if the transformations are developed and implemented as simple greenfield or state changes; current state “a” then state “b”.  In most situations this is never the case.  Typically one is forced to address changing the tire while the wheels are turning.  On a small scale initiative such as a software upgrade this is possible but still problematic, witness all the planning for deployments vendors do from readiness to rollback planning.  Businesses are much more complex so when a mission critical component used continuously goes down all hell breaks loose (e.g., Airline Reservation Systems).

The second common problem I see is non-integrated planning or planning in islands.  You would think after years of hierarchical management experience this would have been addressed by implementing a system like Hoshin Planning to provide linkage across the hierarchy but these tools are not so prevalent or understood…maybe because IT behaves as a product development and run organization rather than a service (despite all the recent hype).  I still see efforts to increase programmer productivity outweigh efforts to manage services ongoing.  Not looking at the interdependencies of that various elements in the system is like expecting a sports team to operate effectively in competition without a game plan, one that address every member of the team and its opposition.

This week I’ve stated to map out the IT Portfolio Methodology or rather IT Planning Process to account for such issues as well as the bigger issue alignment to the business.  Originally I figured the spreadsheet I was building to integrate all the components would be enough.  Now I see a complete methodology will be needed.