Life of a Business Principal in Consulting

Big programs of work tend to be comprised of several small IT projects stitched together. Business architecture makes sense that way - build and release in small doses and keep building. Momentum - in both IT roadmap and business outcomes - is great and demonstrable in this way. Theoretically, Everything goes smooth and the program is complete and every one is happy. However, in reality, things never go as per plan. No plan survives the impact when the rubber meets the road.

Wicked problems are now a well discussed and an on-going subject in various disciplines - predominantly public policy and design. They do apply to IT strategy as well. I am consciously using the term “IT strategy” instead of something more tactical as software development or even more strategic as “Business strategy”. I will explain my choice later in the post.

For the last 25 years, IT systems - be it COTS (Commercial Off the shelf) or custom built - are started with trying to understand how they can accomplish a business process. However, it ends up with business stake-holders having to make compromises to the business process to use an IT system. For some time now, the focus has shifted on the users - finding their pain points and trying to design with the users in mind. This change has done a lot of good. However, that is not enough

The other day I was working on a strategy document for one of my consulting assignments. What was strange was that I had access to all information but I was not sure how to present it in a clear way that would mean action from the stake holders. As consultants, the reason we present the strategy and tactical plans is because we hope the stake holders can gain value. However, we always have impediments in terms of selecting the right information to present, providing the right context and suggesting the right set of next level activities. Frameworks for Decision Making Let me start with a simple decision framework that I used to get the strategy document presented.