IT is a business inside the business to provide business solutions, that's the way to go.
IT implementations are core to strategic changes today, but many fail to achieve the business objective. In very few implementations, IT organizations make effort ascertain how a "day in the life" of any worker at any level (from labor to management) will be impacted due to the new IT initiative. No measurements are made and then it severely impacts when you do a typical technical go live. So how should IT change management and project management go hand-in-hand, aiming at improving customer experience (ease of doing business) and optimizing overall organizational agility and maturity? Does it achieve the original objective? Does the customer experience actually improve significantly? And, how sustainable is the change or would it break down, has the entire organization embraced it well?
Leadership engagement: Particularly the leaders who really need the changes and have sponsored it throughout the journey is low or sporadic- either due to underestimation of the need to be involved or overestimation of the executor's capabilities. There should be enough collective wisdom and experience in any organization these days on change management to make these changes sustainable. In many circumstances, all along implementation, the same business user community puts its complete resistance as the majority of the time, management has not made their clear intentions or goals while embarking on the IT initiative. There needs to have an uninterrupted channel which will keep explaining about management vision and expectations from this IT initiative. The channel should also enable training so as to make the change management process easier. However, for many of the IT initiatives, such channels do exist as a formality, but the messages are not communicated clearly, the deliverables must be driven by a leader who has a vision, power, influence, and respect. The success of any implementation is in managing the change. This needs somewhat of a salesmanship to sell the product as the one which will solve the problems. Sometimes showing how an individual tough user's pain points are addressed and solved helps to get a buy-in from a group of hardcore pessimists and cynical user. Then they become your salesmen - project champions within the target group. When cynics converted to project champions and they are the best opinion makers. Of course, that helps organizations to embrace the change better.
Every IT initiative is to solve business problems, not a purely technical challenge: Many IT organizations still run as a silo function and back office to “keep the business light on,” and running IT project as technical challenge only, the focus always remains on technicalities of implementation and preparedness of business / user community gets forced to focus only at the end. So this one important aspect to engage customers and users earlier on is missed or overlooked majority of the time. Apart from the 'normal' best practices, the following two aspects differentiate a successful change from a failed one:
(1). A Clear understanding of the monetary benefits the customer is going to realize the intended change.
(2). More importantly, serious awareness of the adverse impact (monetary as well as brand value) due to the failed change.
Design, cost effectiveness, and customer satisfaction all have a big impact on the implementation success. The customer-facing employees will be better suited to handle problems or issues, and suggest solutions to the satisfaction of the customers since they will have a better understanding of the system and its capabilities. In today's world, if you can think that a product, be it hardware or software is a technical solution to a business problem, then you have achieved a great success of paradigm shift from the techies.
(1) First question all structural inefficiencies; These lead to bad process which cannot be undone by automation (Customer, Product/Service, Organization, Market position...)
(2) Remember constantly that the tool and automation are not the goal - the operating model, structure, process, automation, and tools are all means to something else. If you forget this your requirement set will be sub-optimal
(3) Then balance costs - of the change to that of the post-change operating model. For example, if this exercise leads to a forecast that 'if we do not do this expensive customization, then the cost of operation will be too high ...', question whether you have violated #1 or #2, If not, then question if you have placed the function appropriately or using the wrong tool!
Pre-forecast and post forecast and track actuals against the forecast. every aspect should have a measure. How do you measure the success of the change - you have to be honest about it and should have the measures laid out beforehand to clearly indicate the extent to which the "why change is needed" is achieved through the change (not just the milestones of the change project).
While some changes could be business critical, but without a measure, the effort cannot be justified. At times you tend to conclude that measures are applicable only in operations world or sales and marketing world and so on, every project implementation should not just capture technicalities and high-level functionalities, but also a measure of success and sustainability, keeping in mind the long-term vision of the IT initiatives.
IT is a business inside the business to provide business solutions, that's the way to go. So, when IT reduces the cost of doing business and delight the customers, it increases the margin. It is the time for business and IT to take each other more seriously, and ideally, integrate as a whole, with the ambidextrous talent to achieve common goals and deliver high-performance business result.