25October

Effective Change Management is critical for any project. Note that we’re talking about Change Management from a project and business perspective – not the ITIL process). In this context, Change Management has the goal of transitioning your organisation from one set of business processes to a new and hopefully improved model. Although the transition usually involves changing technologies, it’s really more about people and processes.

The essentials are:

• Clearly define what needs to change and why. What are the benefits of the change?
  

• Have a plan showing what the new model looks like, and how to get there.
  

• Communicate this with your stakeholders and staff, and keep communicating throughout the planning and transition.
  

• Provide channels for feedback so that staff can highlight issues, and suggest refinements that help you deal with these. Actively engaging with people affected by the change builds trust and goodwill. Moreover, the best ideas (and biggest supporters) will often come from operational teams out in the field.
  

Change Management Framework

Having a conceptual framework to visualise the process and activities is a big help. A quick search of the Internet will reveal many different change models, but the one that I find helps me most is below.



This is a variation of IBM’s Change Program Framework (and is similar to another used by Towers Perrin). It was introduced to me by a Project Manager that I was working with a few years ago. The first three stages get you to the point of deploying your solution - whereas the remaining three stages represent post-deployment activities. This highlights the fact that Change Management is about getting people to use your application effectively (or adopt your process), such that it eventually becomes the “normal” way of doing things.

My take on the stages within this cycle are as follow. Sorry if these are at odds with any “official” version.

1. Lead, Communicate and Engage

This covers the Project Initiation. Leadership is needed to:

1. Clarify the reason and benefits of making a change, and
2. Define the change itself.

This also involves communicating the message and getting your organisation’s stakeholders on board – which is essential since the change needs support and funding. Communication is a two-way process. This means its as important to listen to your stakeholders as it is to talk with them. This builds engagement. It also helps you refine the change to increase your chances of success and gaining stakeholder approval. However, it can present a problem for technology managers who enter into the process with a full technical solution already mapped out. In practice, you’ll need to make sure the business needs and business solution are understood and acknowledged first – then you can start looking at the specifics of any proposed technical solution. Be aware that the practicalities and office politics of your organisation can make getting what you want very difficult, so be prepared to adapt as necessary. Although, if you’re lucky enough to have a CIO or CTO who sees things your way then it should be a little easier.

If your full solution is too much, then try breaking the change down into phases. At the very least, getting Phase 1 approved and underway gets your organisation onto the right path even if it’s not perfect. Successive phases can then be added/approved once your management team has seen demonstrable success and can see the benefit of adding further capabilities or refinements. Like the saying goes, Rome wasn’t built in a day.

2. Develop Capability and Capacity

This involves building capability to plan and execute your change (or project). It’s useful if you have a project methodology, such as PRINCE2 or Scrum. The specific method typically depends on your organisation and the nature/size or your project. Personally, I don’t think it matters a great deal which method you use - so long as you have one. The method gives you a framework and set of basic checklists for managing for your project. A method isn’t a panacea and it won’t guarantee success … but it will help you reduce your risk (and increase your chances of success) by ensuring that all essentials are covered. Central to this is the task of identifying all the project activities, activity dependencies, and resources. You can then use these as a basis for estimate, schedules and ongoing project tracking.

Recruitment: Consider what skills are needed for:

• Project management.
• Business analysis and requirements specification.
• Change Management (communications, etc)
• Development
• Management of infrastructure, environments, and databases
• Test planning and managing test execution
• Training plan and execution
• Deployment planning and execution
• Production Support

Design the team you need, and recruit the right people.

Obviously you need people with the right skills and experience - but (personally) the best recruitment advice I ever had was Joel Spolsky’s “You need people who are smart and get things done”. I’ve chosen a couple of folks who mightn’t have been picked by the usual recruiters, but who’ve turned into the most valuable assets on my teams. Besides the right technical background, I look for people who are problem-solvers and good communicators - and who’ve demonstrated resilience and adaptability. For example, I hired a BI Architect from Iran several years ago. He was qualified, well-spoken, and had some good local experience - but (at the time) didn’t have the fancy padded CV that I’d seen with other architects. He definitely knew what he was talking about in the interviews, and I’d noted that he’d had a large role implementing and supporting Oracle-based systems within major Iranian oil and energy companies. This is in a country subject to several decades of trade sanctions, and where Oracle (and most other software/hardware providers) don’t operate. Therefore the implementation and support of the latest Oracle technologies there relies on people with in-depth product knowledge, experimentation and ingenuity. Given that I was supporting a system with a very long list of stability and capacity issues, I figured this was an ideal candidate - rather than other “better qualified” candidates who would simply have told me I needed a bigger system (which I knew I wasn’t likely to get very soon). I’ve had other candidates who were unconventional in other ways - but who’ve still proven instrumental in saving our systems and business users when the chips were down.

At the end of the day, I want someone who can think for themselves, adapt, and handle whatever weird curve-ball that the project throws at us. However, that’s just my preference - and I’m sure other managers have their own spin and ideas about candidate selection.

Business Solution (and Data) Analysis: When building the capability to develop a solution, pay close attention to the initial requirements specification and analysis. Aside from the reporting needs, I focus on trying to understand the business data and its quality (see article: The Business Intelligence Data Analysis Phase) since this gives me an idea about the raw material I have to work with … and if the introduction of new BI reporting systems needs to go hand-in-hand with improved data capture processes and business rule clarifications.

• Getting this upfront analysis done right increases your odds of success.

• This involves Business Analysts doing user interviews, process documentation, and exploration of the existing business data.

• Once this work is completed, work on your solution design. Also revisit and fine-tune your estimates, milestones and schedules.

Test Planning: Requirements are also important for your test planning, since they help you define what tests are necessary, and the associated acceptance criteria. In addition to the user acceptance tests, design automated scripts to verify your transformed reporting data against the original source system or transactional snapshots in your Operational Data Store.

Deployment Planning: When you’re out doing your business analysis and requirements specification, find out what’s needed for deployment. This should cover both the requirements of the business (e.g. training, support, timing) and the requirements of IT teams (backups, test summary reports, change approval boards, production readiness reviews etc). You also need to determine the deployment approach that’s going to work best for your situation - such as a phased rollout with a pilot, followed by a location-by-location deployment (to facilitate the delivery of user training) and a period where both the old/new reports are available in parallel. A Training Plan (for users and support staff) is another deliverable associated with the deployment planning activity.

I’ve been disappointed by the number of Project Managers who consider that the solution build and UAT constitutes the end of their involvement. They never stopped to think how their solutions got rolled out into production or how they’d be supported/enhanced afterwards. Most large organisations have processes to safeguard their production environments and users. These processes include formal reviews and verification of the solution design/architecture, test documentation and release/backout plans. In some cases they’ll also need capacity estimates and sign-offs to verify that the solution has the required hardware/software support, and ongoing funding. It’s all a very tedious process of jumping through hoops, meetings, and filling out documentation in the required templates - but is necessary to ensure that you can actually deploy. This takes time, effort, and planning to manage - and usually won’t be something that you can throw together a few days ahead of your intended release. Hence, find out these requirements early and ensure that (1) resources are allocated, and (2) these steps and lead-times are factored into your project plan. As Change Manager, I’ve also made a point of establishing relationships with all the people involved in the planning and approvals to ensure that we’ve provided the right information, and that approvers are satisfied with our production readiness. This reduces the risk of having our deployments unexpectedly postponed.

3. Design Organisation and Governance

The governance and design of your project is likely to have been established already in stages 1 and 2. Project governance is largely determined by your existing organisational standards, alongside the standard project methodology. Therefore, this stage is more about designing the mechanisms and processes to support the ongoing operations of your proposed BI solution.

• Design the structures which will be used to provide support and future enhancements of your solution once in place.

• Draw up job specifications and,

• Recruit permanent team members.

Chances are that those involved in your project’s analysis and development effort will be contractors. These contractors will likely move onto other projects, and other organisations, once your deployment is complete. Therefore you need to ensure that a permanent team gets built up and put in place to maintain and extend your solution ongoing. Recruiting these positions (and getting the approvals to do so) can take months - so don’t leave it till the last minute.

Often its a good idea to recruit your resources while the project is still running. This way, delays experienced with approvals and the recruitment process are less of an immediate issue. And, when you get people, you can involve them in the build and deployment effort. This means that they’re already familiar with your solution and systems prior to taking over the official support. Having your permanent resources involved in the project also helps with Quality Control and ownership of your project’s documentation and support materials - since these resources know they’ll be responsible to looking after these in the long term.

During this stage, I also work on putting together the Production Support model and getting it approved. At the end of this stage (assuming the the build and testing have been running in parallel), you should be getting close to deployment.

4. Align Individuals and Team

From my perspective, this stage is all about getting the new processes and organisational changes up and running effectively. This means delivery of training and ongoing support to ensure that your users can use your solution … and that the change is working as planned. Transitions take time and support is needed throughout that period - not just in the first week.

Up until now, most operational staff would have been safely removed from your project.

• Ideally they will have been aware of your project and goals through your communications, BUT

• Only a small number of people will yet have had hands-on experience developing and testing the new systems.

However, now that your new systems are “in the wild” your intended users will be putting them to the test … and it’s pretty much guaranteed that users will do stuff (or get results) that you never envisaged. This stage presents the opportunity to begin your refinements and enhancements - tuning your systems, production support, user training, data-entry, usage practices, and governance structure to ensure they’re practical and deliver on the needs of your organisation over the long term.

As with the earlier phases, collecting business feedback is important. Aside from being a wealth of good suggestions, this illustrates to your user community that you’re listening and taking on their ideas. Once again, this builds trust and a sense of ownership in the new processes.

5. Manage Performance

This stage covers the ongoing enhancement and performance tuning which occurs in the period once the systems and processes have settled into a stable production state.

6. Transform Culture

This follows on from the performance management, and is associated with making the new systems and new processes part of the “normal” way of doing things. This is all about changing the mindsets so that the new processes become ingrained as part of your organisation’s culture.

Go to Part 2

Tags: Change Management, Business Intelligence