Business Change Management

Author: Brian JohnsonBusiness

This Whitepaper will largely focus on Business Change Management, as defined in Managing Successful Programmes (MSP®) published by The Stationery Office and how programmatic Change differs from Improvement as discussed in BiSL® Next. Programmatic change is consistent with BiSL Next because it is a good practice in its own right and is rightly considered as the means to manage large scale change. The Improvement domain in BiSL Next may well include elements of programmatic change but is primarily focused on improving the information services by making better use of information and ensuring the quality of information services by being involved in their design, build, test and operation. As an example, an enterprise wishing to invest in professionalization of Business Information Management (BIM) would be wise to consider that a programmatic change! Thus, where appropriate, specific references are made to a BIM programme.

1. Change Management or improvement?

Change is nothing new in business. Most businesses (except for perhaps a market stall fruit vendor) are used to continual change. What is new is the scale of change affecting enterprises. It has become commonplace for enterprises to experience strategic, disruptive, far reaching and fundamental change. So much so, that what is regarded as strategic is now largely a matter of perception. To you, a new line of business is commonplace; to another enterprise, it is a major strategic headache.

BIM is only one important component of Change that must be managed and this Whitepaper focuses on the wider issues and not only on the issue of business information services.

Innovative, strategic change can be defined as a change that has a high impact on the business enterprise and is carried out over a fairly short period of time, typically less than a year. This type of high impact change affects the:
* scope of the enterprise: choosing to supply to different types of customer and market, or selling or merging the enterprise, for example, privatization and management buy outs
* structure of an enterprise: changing the enterprise executive hierarchy and management controls by means of a large scale reengineering, including new sourcing strategies that can and do impact business and IT
* core processes of an enterprise: changing the way in which an enterprise makes its products and services and delivers them to its customers
* culture of an enterprise: implying changes in the values held by the people working in the enterprise, for example, changes in management style.

But, why change anything unless it is to improve? Large scale change and small scale should be focused on need and value. The request for change process well known in ITIL is often instantiated as a means to control change, not to facilitate change and rarely to assess the way in which a change will improve things.

2. Reconsidering IT within the enterprise strategy

The definition of strategic change matters less than the scale of change and the way in which IT is handled. Changes in the enterprise affect its desired deployment of IT to bring business benefits, in other words improve things. Changes may be required to accommodate the introduction of new methods and movements that aim to reduce the gap between identifying the need for new business services and the time it takes to deliver them, the Agile or DevOps philosophies for example. Most enterprises cannot afford to shutter up the shop while they are changing, so there is a need to manage these concurrent changes and at the same time keep the business running.

A question to consider is do you trust your IT people to make the correct decisions about technology and information without having a full understanding of the business, not just the business of IT? This question often leads to the issue of sourcing; do it yourself or bring in the experts? The fashion of the moment in IT is Agile, well, a well-managed agile development (meaning that adherents follow the principles set out in Agile training and instruction manuals to accelerate the development of applications that are part of business services) rarely is an improvement over a well-managed project of development run under PRINCE2® or PMI®. The key phrase is ‘well-managed’. And frankly, the majority of IT (software and hardware) vendors simply plug-in the ‘agile’ word to their usual advertising along with as many other words they can find that might blind you to what they are selling. ‘Leverage’, ‘business-focused’, ‘innovative’, ‘visibility’, ‘empower’, ‘out-of-the-box’, and best of all ‘ITIL compliant’.

Agile or ‘traditional’ methods are both useful though none of them address the governance and quality of information that is being captured, stored, secured, retrieved and processed; indeed, other supplementary good practices are needed in order to cover governance, information security and good practices such as programme and portfolio management.

3. Commitment from senior management

The single most important feature of owning and managing an enterprise strategy (including those with BIM being involved in designing business services), is commitment to change from the top. And this point will appear in every article or book you will read about adopting methods or good practices. It is a cliché though it is also obvious that top management must drive the changes aggressively. It has been said that in any enterprise facing change, only 10% of employees will be supportive, about 60% will be ambivalent but the remainder will be actively opposed. That remainder must be signed up, or moved to another environment (or deported as illegal immigrants…..). The 10% of active supporters will need to be encouraged, even rewarded, perhaps given top jobs in the new White House. How did that creep in? Anyway, the key to success is therefore strong leadership, commitment and an enterprise understanding of, and alignment with, what is to happen. Once the decision has been made to govern and manage information used in the enterprise, plans must be made to introduce new concepts and ways of working. In a large enterprise, the undertaking may be a programme of changes; smaller enterprises should still undertake the introduction of BIM as a project. Information Technology is only one of the aspects of concern in strategic change. Often it is the key component, mostly as an encumbrance, when it should be the source of opportunities to innovate.

4. Change to support business

The role of IT in an enterprise has evolved from its predominant focus on automation to achieve greater efficiency, to a wider role as a fundamental enabler. IT can provide the means not only for better customer services and products, or lower costs, but also, for example, for creating and maintaining a flexible business network of inter-enterprise arrangements. IT can be instrumental in facilitating joint ventures, alliances and partnerships; technology licensing, marketing and contract agreements. On influencing and challenging IT, fundamentally if need be, in order to provide changing (and changed) business with the IT information support it needs. The Information and Infrastructure lifecycles need to be in synchronization (see also Whitepaper ‘Basic principles of Business Service Design’), if change is to be part of a successful programme.

5. Programme management

As with enterprise wide changes, if you have a programme that includes or is focused on BIM, it is now time (in the programme definition phase), to define the programme in more detail: in particular, to develop the blueprint of future business operations and to direct any change to the information services, or to the IT infrastructure that is to support the business, and to firm up the business case and to define the profile of benefits to be realized by the change.

Whether or not you adopt a formal programme management approach, at this stage you need to:

• agree the programme management organization and procedures to ensure the successful execution of the programme, in tranches if appropriate
• initiate communications that will ensure awareness and commitment of all affected personnel
• define in detail the scope and interdependency of all projects in the first tranche of programme execution
• document the detailed scope, objectives and plans of the programmes in a Programme Definition Statement.

6. Programme and Project management

You should make sure that each project in the change programme has clear objectives, with roles and responsibilities defined unambiguously. The required outputs from the project, such as a new IT applications or trained users, need to be specified sufficiently precisely to allow you to assess when they have been delivered and whether they are acceptable. The project planning process will indicate not only when the outputs can be delivered, staged if necessary, but also the resources needed to deliver them. Project estimating is by no means an exact science, but the enterprise can certainly learn to improve through practice; in addition, BIM personnel can assist project management by properly estimating software development effort using good practice such as Function Point Analysis (FPA), or something like COCOMO (COnstructive COst MOdel), methods described in Whitepaper
‘Estimation techniques’.

7. Testing

As new IT services, systems and infrastructures are readied, they need to be tested before they can be released to the operational IT infrastructure. Tested information services, systems and infrastructure cannot just be installed and used. The new information services and infrastructure need to be integrated into, and tested as a part of, the operational infrastructure before they can be brought into use. The business is heavily involved in deciding the timing of such changes, as the changes directly affect the IT support the business receives. It is for the business to check that the new services and infrastructure provide the required business capabilities. The business should also satisfy itself of the technical soundness and the flexibility of future changes to the new IT facilities, in its role as IT design authority.

You should not regard testing as a ‘tail-end’ activity, after you have spent lots of time and money, to see whether you are happy with the results or shocked at their nastiness. Rather, you should think about testing from the context of your IT projects. When you are developing your requirements specification, you should include in that document, test criteria against which you will decide whether the delivered business information service meets the needs of your business. You can then ensure interim deliverables of the project are subject to QA or testing criteria which contribute to your confidence that the project is on target to deliver a satisfactory end product.

Remember that the requirements you want from an IT service and the tests that it must pass are effectively the same thing. Thus, designing and documenting acceptance tests is best done at the requirements stage. By conceptually applying these tests to proposed solutions, many expensive errors can be prevented before detailed work has begun on abortive approaches. As business requirements change, then the acceptance tests must be maintained in step with the changing needs. Again this maintenance of the testing needs provides a valuable control over the validity and desirability of such changes.

8. Dependencies

Where there are interdependencies between projects or there is a likelihood of knock on effects from one project to another, these should be clear in your programme plans. It is a responsibility of the Programme Manager to make sure these interdependencies and knock on effects are properly managed.

The business environment may well change rapidly, perhaps in unpredictable ways, during the change, or the objectives of the programme may change. Again it is a responsibility of the Programme Manager to make sure changes to the programme are translated into changes to IT- related projects within the programme.

Pay particular attention to contracts where IT, or portions of IT, are outsourced (or perhaps where the changes involve the outsourcing of any current in-house IT services). If you are relying on third parties, it is essential that you are protected by your contract with them. Who will pay if, say, applications are not built and tested in time for implementation? What are the consequences of having to revert to the original IT infrastructure if there is a failure in installing a new one? Indeed, who is responsible for developing and testing business continuity plans to be invoked when crises occur?

Bibliography
Managing Successful Programmes (MSP®) 4th Edition – Book, London: The Stationary Office, 20111

Johnson B C, c.s., BiSL® Next, a framework for business information management, Van Haren Publishing, 2017

Relevant reading

 

Title: BiSL® Next
ISBN: 9789401800396 
Author: Brian Johnson, Gerard Wijers, Lucille van der Hagen
Price: € 42.35

 

 

 

 

Trademark notices
ASL® and BiSL® are registered trademarks of ASL BiSL Foundation BABOK® is a registered trademark of IIBA. COBIT® is a registered trademark of ISACA. GatewayTM is a registered trademark of OGC.
ITIL® , P3O®, MSP® and PRINCE2® are registered trademarks of AXELOS Limited. TOGAF® is a registered trademark of The Open Group.

Leave a Reply