Posted by: David Scott
business change, change, change management, IT change, project management
It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage, than the creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old institutions and merely lukewarm defenders in those who would gain by the new ones.
It would seem pretty obvious that change is a routine part of life. However, you wouldn’t know this by observing some people. To them, change is an outrageous imposition: a bolt of lightening out of the blue. To them, when a “rare” occurrence of major change does come down the pike, it should be something that poses no special challenge, no obstacle to be overcome, and somehow those effecting the change should make it transparent to them.
Change is challenging – there’s no getting around that. Under the best of circumstances it will involve everyone’s best game – therefore, it is important to get everyone possible on board in support of the agenda for the change. For those who are determined to drag their feet, or even undermine the agenda (and there will always be those), you must be prepared to neutralize their impact. Certainly there are ways to work on negative people to bring them aboard or to at least gain a measure of cooperation from them. But recognize that the larger the change, and the larger the organization, the more the likelihood that you’ll have a measure of people that will simply forestall change. Be certain to get sanction and support for any workarounds you employ for these people, and document any stalls to protect yourself and the project.
Change must always support business, enhance business, and keep business current and moving. Change cannot, and does not have to, impede business – either situationally, or through delivery of unanticipated harm – such as poor fit solutions, hobbled systems, etc. Remember too that outside change (change external to your organization) demands internal change. As change is coming anyway, you must get on a footing to welcome it by being ready for it – and, barring unforeseeable circumstances, by leading and directing it.
Also, we must gain an important clarity. Today’s organization should keep foremost in mind that most IT-managed change (save for hard technical projects) has true origination outside of IT. Everything germinates through the conduct of business. A department may need a new module added to the organization’s core business application to accommodate new business, practices, or regulations. You may begin or expand an e-Commerce initiative. Perhaps your organization needs a new e-mail system that supports more capacity, better security, and easier user administration. Even seemingly “technically-driven” episodes can have a “business” motivation. For example, a vendor may have a new release of software that requires immediate implementation for security purposes. In this case IT notifies Business of this upcoming implementation, and negotiates schedule and necessary support. We could view this as IT-driven change. But even here, we’re really speaking about a “business” genesis; we’re accommodating the “business” of the world’s demands to our own business security posture. In other words, we’re never really implementing software or dispensing change at some IT whim, or pure IT instigation.
A Basic View to Understanding Change
In gaining a basic understanding of change, look at simple change that has direct impact on Business, and the way business is conducted. Leave consideration aside for the moment for the pure IT initiatives, as these should be transparent to business: updates to backup routines, network infrastructure, operating systems, the changing of Internet service providers, etc. These sorts of “computer room,” or backend, things certainly enhance business in important ways. But the real trick in handling change is when changes affect large groups of users in your organization. That is, “front-end” change – stuff that hits the desktop and creates a challenge for Business. Change that influences people’s day.
Also, be sure to qualify change as being appropriately “sanctioned” – approved in accordance with all other requirements. Change, being the challenge that it is, is often seen as some titular mount: Rather, change is wrapped inside ongoing business. At the first sign or plan of a necessary change – be it major upgrades to core business platforms, or more mundane things such as rollout of new PCs, upgrades to peripheral shelf software, etc. – IT and Business must always review the organizational calendar for obvious times that don’t offer themselves as good periods to support a particular change. It would not be good to implement a new e-mail system during the run up to the annual conference, for example. Talk to executive schedulers and key department heads; there is a wealth of information to be considered, formal and informal, regarding general schedules and burdens to the organization. Know the organization’s general calendar.
Also explore those demands that may not yet be documented – we’re back to knowing “where you are.” Then, through the BIT team, further survey departments and discuss their internal calendars regarding their major activities. When determining where best to place change, be sure that you view requirements through the people prism. After all, the priority and goal is to serve business – not to impact business. People need, and are entitled to, a period of adjustment even regarding relatively small initiatives that affect them. They will need to adjust and size their attitude – managers will need time to inform their staff.
Sometimes certain business schedules can make allowances to accommodate implementations. As well, IT will often have to adjust because of some unforeseen cycle of business. It’s a give-and-take. Also remember that departments aren’t “silos” operating independently of all other departments (although occasionally they may try to operate that way). Elements of change will need to be negotiated between many departments, and there must be appropriate lead-time to allow for this.
For the IT leader, most change can be negotiated and driven from your participation with the BIT team. Whether change originates through a debut within the team, or needs are identified elsewhere and subsequently brought to the team, the BIT team should be where most of the sizing gets done. That is: negotiations, agreements, sponsorships, schedules, ownerships, identification of metrics, standards of delivery, etc.
Change happens with or without your control. If you don’t direct and control change – it will direct and control you.