IT transformation is a big deal: it can make or break a company's ability to adapt and therefore to keep the lead or to stay in the race. These high stakes, combined with the ongoing business as usual turmoil make it feel like hitting a moving target:
Here are 5 "snipper" hints which tend to lead IT transformation programs to success...
The main characteristic of a transformation is that it is business driven. It's a mandatory, entreprise-wide change to either respond to changing market conditions, tap into new market segments, or in worst cases avoid the decline of the company.
IT transformation is only a part of a larger plan, or at least shall be. It can bring value to the company only if it is integrated in a larger transformational move. If it's not, it's only a supplementary layer patched onto the existing IS, which entails additional costs (maintenance, evolution, IS complexity) without gain.
In order to favor value brought in by IT transformation project, project sponsor has to:
Project sponsor is a key stakeholder on projects, and especially on IT transformation projects. He's accountable for alignment between IT transformation and business objectives. Contractor's project direction team has to know project sponsor well, foster a good relationship with her/him and raise alerts to top management if Project Sponsor do not perform as expected.
Overarching company's transformation strategy shall be shared with contractor's project direction team in order to enhance value propositions from contractor.
IT transformation projects are often large and complex. Large because of the number of applications involved in entreprise processes, of the large number of resources involved, and complex because of intrinsic complexity of existing entreprise processes, inertia and organization's resistance to change as well as changing landscape due to ongoing operations (business as usual).
In this fast paced moving world, business case shall always serve as a reference to stakeholders to take decisions. This business case shall come from project sponsor and be mastered by project management team.
Current operation stakeholders will always urge project management team to embed changes that come from ongoing business, and the related value has to be carefully questionned in order to avoid scope creep.
Client's project management team responsibility is to mitigate and deal with stakeholders' expectations by studying and questionning benefits vs costs. Contractor's responsibility is to alert whenever scope change requests could lead to scope creep by blasting out Project Management Baseline too widely or too often.
A shared vision of business drivers may help contractor to give better advices related to business case (Contractor has a vision on industry standards).
Given the 2 previous hints, managing an IT transformation project is not an easy journey. Each stakeholder has a role to play in order to ensure project success.
However, too often have I seen project sponsors busy with day-to-day operation and current financial results lacking of vision on project's benefits, project management team not aware of company's strategic drivers of the transformation. This situtation has several consequences:
Champions team is a team. Clients resources are member of the team and the outcome depends on them too.
Contractor has to alert whenever client's side of the team has not the appropriate level of expertise / involvment. Some useful indicators are
As mentioned above, changes are inevitable. During a 1 year-or-more project, companies need to do their "company jobs", eg. struggle with competition, be innovative, buy other companies, review internal processes to face organic growth...
But changes are to be managed very very very well in order to avoid leading the entire project to failure. Here are some tips:
In a fixed price contract, managing changes is a matter of economic survival. Don't play with it, and set-up a change management governance and toolkit right from the start. Spread the word to teams to carefully register any new request during design but to never commit during sessions on embedding a change, even if it seems obvious and cheap.
Lessons learnt: More than 2M€ changes which could not be charged, all of this being a sum of small changes between 5 and 20 m*d in implementation accepted on-the-fly by inexperienced design team: "A journey of a thousand miles begins with a single step"... It' worth paying attention to.
Last but not least, value is leveraged by not-reinventing-the-wheel. Every industry builds standards which represent a set state-of-the-art best practices skimmed through millions of work hours across various contexts. No one shall be arrogant enough to claim "These standards cannot be applied in my business".
Standards can be tuned, right. Instanciated, right. But somehow, the company which accepts to review its intrinsic processes to go the-most-standard-as-possible leverages a powerful bunch of aggregated experience and can be pretty sure to generate value from it.
Moreover, one of the great benefits of standards is that they come along with
If involved in upstream steps of a transformation project, always be sure to have a Subject Matter Expert who knows industry standards by heart. If you don't, hire one.
If you're not involved un updtream steps of a transformation project, get involved. The earlier you're involved, the more value you can leverage with standards: