Why Transformation can go awfully wrong

There are some common problems I have seen recently on digital transformation projects.  This is by no means an exhaustive list of everything that can go wrong. This list is also not exclusively the domain of the digital transformation projects only but can happen in other types of projects

1. Poor road mapping and unclear understanding of the program objectives – Not enough time may be spent early enough to truly understand the multi-year vision, develop and disseminate clear objectives/benefits to all stakeholders direct and indirect (especially if the indirect stakeholders have undue influence on the CEO).  For example I recently had a client that took almost 1 year to close the sales cycle – during that sales cycle we agreed to a 2 year multi-phase road map where B2C Web Content Management was agreed to happen in Phase 1, B2C e-commerce was in phase 2 and B2B related events (content and commerce) in Phase 3 and beyond. However once Phase 1 started there was constant pressure (from VPs of Manufacturing and Engineering and Distribution) who owned ecommerce and B2B segment) to move up Phase 2 & 3 activities (priorities and people had changed over the 1 year sales cycle) and to do it in parallel with Phase 1.  This lead to huge additional pressure on the delivery Phase 1 team to start looking into alternative plans to move things up.  I fault this on organizational dysfunction and weak executive sponsorship where neither marketing nor IT were willing to push back appropriately (on Manufacturing and Engineering).  The lesson learned for me is that the SI leadership needs to really ensure with CIO and CMO through open and frank dialog that these events do not happen and if they do happen they get killed immediately (go to CEO) before it can cause wide scale confusion and loss of efficiency of the delivery team. (In this client the CIO and CMO were relatively weak compared to the other CEO direct reports and were viewed as COST CENTER vs a REVENUE and PROFIT center.  This is vital…how your exec sponsor is viewed in his organization is key to inferring how much influence they have in a project that is going to transform the client)

2. Ineffective Sponsor Management.   I am going to assume there are co executive sponsors for the effort i.e. CIO and CMO.  This is a one body, 2 heads problem and requires more than the normal efforts of a  typical IT engagement to manage.  More often than not the CMO and CIO can have an adversarial relationship – for sure their teams will have one.  (At least that’s been my experience). So the responsibility to maintain and establish harmony is going to fall on the SI.  This can prove challenging and is a classic case of managing expectations and constraints.  One effective technique I have employed is to have weekly CIO meetings and weekly CMO Meetings separately and work through back channels to head off disagreements.  (I prefer this to confrontation in a Steering Committee level meeting because then you will find that the two “C” levels can tend to grandstand a bit (unless the CMO is clearly more powerful that the CIO and the CIO play a deferential role to him typically in organizations where the CIO rolls up through the CFO office in my experience – which is now less common at least in the US). The other technique is to also have designated client liaisons especially to handle escalations at the working level. 

3. Bad short term decisions that create problems in the sustain phase (i.e. post go live). At Target I had a very unique perspective. I worked before go live on the project team (I ran Business Readiness) and then they hired me on as full time staff post go live.  So therefore I had a unique view of the ramifications of the project decisions on the post go live world. In many instances I found a pattern.  Project were consumed by timeline and pressure and budget so they took quick and dirty decisions frequently without taking into account things such as usability, simplicity, elegance etc. On more than occasions absolutely user unfriendly processes, technical architecture decisions etc. were made that had problems post go live.  So the question is how to realistically minimize this problem.  This is not at all easy to do…one hopes that the client project team has the long term hat on and can steer the contractor appropriately but often times that is not the case. The clients themselves don’t know the business well enough or have a good understanding of the vision to advise appropriately. The only advice I can have for this is for the SI to stay vigilant and stick to known best practices wherever possible. 

4. Starting Business Readiness (BR) activities late – BR is the area that is related to Day 1 and beyond.  In my experience it almost always starts too late and results in a mad scramble to get the enterprise ready for the big day.  One can argue that BR is more important than any other track but since the scope is almost always less understood than the project scope it can cause issues