FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
Change management is paramount
1. Change Management is Paramount Matthew C. Clarke Artwork by Dario Campanile CC-BY-SA
2. Context This presentation was made on 11 May 2011 at the Intranets 2011 conference in Sydney, Australia. This document is lightly protected under the Creative Commons Attribution Share Alike 3.0 License. The presenter can be contacted via LinkedIn or by email to matthew.c.clarke@gmail.com
3. Outline Intranet projects often fail ... but why? What is change management? Eight verbs for an intranet project
10. Damsgaard, J., & Scheepers, R. (2000). Managing the crises in intranet implementation: a stage model. Information Systems Journal, 10 (2), 131-149.
15. 1. Reverse the thinking BAD: A new (or changed) intranet is just a technical project BETTER: A new (or changed) intranet will need significant change management BEST: The intranet is a significant tool for organisational change
16. 2. Seek senior sponsorship Patron Champion Sell the business value to them
17. 3. Maximise employee participation Moral principle Pragmatic principle Avoid rather than overcome resistance
18. 3. Maximise employee participation Moral principle Pragmatic principle Avoid rather than overcome resistance
19. 4. Increase the appetite for change You can lead a horse to water ... Gaining permission Unfreeze – Transition – Refreeze
20. 4. Increase the appetite for change You can lead a horse to water ... Gaining permission Unfreeze – Transition – Refreeze
21. 5. Design for change Change is the only constant Intranet design must be extensible Intranet processes must facilitate change
35. 7. Test user reactions and usefulness Test design choices early Usable does not imply useful or used Run pilots in authentic contexts
36. 8. Generate a critical mass of users Create expectation and excitement Most useful content first Royal decree
37. 8. Generate a critical mass of users Create expectation and excitement Most useful content first Royal decree
38. ...and one final thought Lighten up a bit! Matthew C. Clarke http://matthew.clarke.name
Editor's Notes
For any team driving an intranet implementation project, change management needs to be of paramount concern.I know this cheap animated rip-off of the Paramount Pictures logo is an amateurish gimmick, and I promise it is the only one in my presentation. I hope it is at least memorable. But I also hope there are more memorable aspects to the presentation that help you to increase the organisational uptake of the intranet projects on which you are working.A piece of trivia about this logo is that the original was painted by Dario Campanile, shown here next to the painting in 1975. At least that’s what Wikipedia tells me!
I will start with a short background on what makes so many intranet projects failAnd then some even shorter comments on change management But the main body of what I want to say is some suggestions that you can put into practice. James Robertson said to me “Make sure you give them lots of verbs”. So I will offer you 8 verbs … 8 actions items … that will help your intranet succeed by addressing the crucial non-technical aspects of change management.
I will start with a short background on what makes so many intranet projects failAnd then some even shorter comments on change management But the main body of what I want to say is some suggestions that you can put into practice. James Robertson said to me “Make sure you give them lots of verbs”. So I will offer you 8 verbs … 8 actions items … that will help your intranet succeed by addressing the crucial non-technical aspects of change management.
There is a lot of anecdotal evidence to suggest that many intranet projects fail. That needs to be considered against a background of failure in IT in general of about 25%. That means that a quarter of IT projects are either never delivered or are dead on arrival.This raises the question of course or what we mean by an intranet failing. This could be any of the followingThe project was ill-conceived and set off to deliver the completely wrong goalThe goal might have been worthwhile, but the design did not match goalImplementation did not match designPerhaps the project was never delivered because of resource constraints, internal politics, key people leaving the team, scrapped because it was too far over budget etcSome intranets work, but fail to generate the expected ROI Some intranets are implemented and turned on, but never used. Perhaps it is too complex for the intended users, lacking in visual appeal, the perceived learning curve is too daunting, or the employees are just too resistant to changeLet me give you just one example …
The US Navy, according to this news article in 2006, spent $9.3 billion over 10 years on their intranet. In this case, the intranet was designed, implemented and delivered, but its success was questioned because the plan to measure the success was never implemented.
Before looking at the common causes of failure, it may be important to understand several different consequences of these failures.Lost investment and associated opportunity costLoss of personal credibility and motivation for the project teamLost trust from users increases resistance to future initiativesLost trust from management reduces likelihood of their future support
There are numerous opinions about why so many intranet projects fail, some based on good research.I won’t attempt to collate or summarise those opinions, but just draw on two that are both typical and insightful.
Damsgaard and Scheepers propose a model with three key points of failure. The main curve shows the trajectory of a successful intranet in terms of how well embedded it becomes in an organisation’s culture.When an intranet commences operation, it needs a sponsor to gain any traction within the organisation. Without that, it is likely to fail in the initiation phase.In the Contagion Phase, the intranet may fail because not enough people get excited about it.Once there is a critical mass of users committed to the intranet, the next step towards sustainable success is to impose some control – consistency, governance, standardisation etc. That may prove impossible and the intranet may collapse.
Now, some brief comments about change management in general. Many books have been written on this, and I won’t even attempt a definition or overview. But I want to indicate that an intranet team needs to be aware of three domains of change to be managed.Technical: The intranet as a entity itself will undergo frequent and substantial change. Those changes need to be managed if chaos and derailment by scope creep are to be avoided. By what process are changes requested and approved? How stable is the system when changes are made? How well does the IT infrastructure scale in response to changes in usage patterns?Organisational: the intranet exists within an ecosystem, an organism, a system that has its own life independent of the intranet. The organisation has its own culture, processes, values. Like all systems, the organisation seeks equilibrium. And an intranet is virtually guaranteed to require changes that disrupt the established equilibrium. Changes to business processes. Changes to data entry, reporting, document filing practices, staff induction etc. For a viable, improved equilibrium is to be reached, the organisational changes need to be understood and managed.Individual: An organisation is made up of individuals. Each with their own preferences and motivations. They too will have to change in one way or another to make use of an intranet, or to adjust their behaviour when the intranet changes. An intranet project team that appreciates how people approach change will be able to generate critical mass of supporters more easily.Lastly, in each of these domains, resistance to change should be expected. Think about change in your own life. We each sit in the proverbial “comfort zone,” where we know what to expect, feel reasonably in control and safe. To change requires effort. Something new must be learnt and mastered. Will that effort be worth while? Even when you look forward to a particular change, there is a sense of dislocation and loss – something needs to be released and left behind and that causes grief.
Rather than delve into change management as a discipline, what’s more useful is to list some change management principles that relate specifically to intranet projects.Well, “principles” is too abstract. What I really want to present is a list of “practicles” … and yes, I know the spelling is wrong. So here are my promised 8 verbs …
The first verb is “reverse” …From what I’ve said already it will be clear that the success of an intranet project does not depend solely on the technical quality of the system.A better attitude, which you the intranet project team and its managers need to accept and promote, is that to succeed, the project will have to address many important non-technical factors.But even that is not the ideal attitude.BEST: I believe that intranets are most likely to deliver real value to organisations that have a clear understanding of how an intranet can be wielded as a tool to drive change. Imagine a CEO who has both a clear business goal and a good understanding of how to change organisational structures, processes and culture to reach that goal. Under that CEO’s patronage, the intranet can be a channel for:communicating the business goal and the benefits of changeMaking new org structures visibleConnecting with the employees, e.g. via a personal blogFacilitating collaborationFostering stronger people networks and knowledge sharingEnabling employee contributions and recognitionCelebrating success storiesIn that environment, change management is not seen as a problem for the intranet team to overcome, but the very reason why the intranet exists.I’ve started with this as an ideal, but admit that it may be very hard to convince people of it in practice.
Whether the ideal is achieved or not, the success of an intranet project is significantly increased if there is positive, strong and sustained top-down influence.If you are working on an intranet project that does not have senior sponsorship, I strongly advise that your team put their heads together to plan how to get it. Use whatever personal networks and influence you have to work your way up the corporate tree to find supporters. Two roles are important:A patron should be the most senior person you can find who will give the project their blessing. That’s all they need to do. Just to verbally support your project when the topic of the intranet comes up. To show by the merest nod of a head that they approve. That gives you permission to co-opt other resources. There is nothing more powerful in corporate land than to say “The CEO said this is a priority”. Even “the CEO said to go ahead” is pretty useful!A champion is someone who has three characteristics: Personal interest and understanding about the project Time and enthusiasm to promote the projectCredibility within the organisationSuch a supporter can act as an advocate for the value of the intranet, help to remove roadblocks and allocate resources, and plays a major role in generate enthusiasm in others about the projectWhen trying to gain this type of support, sell the *business* value of the project. Best phrased in terms of the three things on the mind of all business managers:Increasing revenue: perhaps unusual for intranets, but not unheard of. e.g. By providing easy access to past tender submissions, an intranet may allow a bid team to put together higher-quality responses, leading to a higher win rateReducing costs: give specific examples of how your intranet could improve internal efficiencies, e.g. advertising preferred suppliers on the intranet may allow diverse business units to get discounted purchase rates.Solving problems: find out what keeps the senior managers awake at night and do your own creative imagining about how technology might help. Maybe your HR department is already talking about unacceptably high rates of employee turnover. Can you find an opportunity to describe how an intranet that includes some social-media aspects can increase the sense of connectedness and belonging, and consequently reduce people’s desire to leave?
The top-down influence of senior sponsors needs to be balanced with bottom-up influence among the user community.Planning and implementing an intranet change project and only showing the system to the user once it is ready to go live is a recipe for disaster.You are far more likely to succeed if the users have been involved from the very start. This involvement must be authentic rather than token. You should be honestly committed to finding out what the employees’ think about current systems and processes, what ideas they might have for improving those systems, and designing something with their personal goals in mind. This does not mean that they dictate the design – that’s a technical task best left to trained specialists. But it means authentic two-way communication about the purpose of the change and its benefits, the impact the change will have on the employees, and the timing of the changes.Suggestion: run some early forums or workshops with a broad range of user representation. The aims would be to listen to what people now like to call “pain points”, to discuss the ways an intranet might relieve some of that pain, and to start building relationships of trust between the user-base and the project team. An outcome could be for the user-base to nominate one or more user representatives who become part of the project team.There are two main reasons for this type of Participatory Design.Moral principle: I believe that in all human relationships, we should not impose changes in a way that dis-empowers others. The people affected by a change should be given some control over that change.Pragmatic principle: people who participate are more likely to feel responsibility and ownership and hence work with you rather than against youThe result will be that employees themselves will promote the adoption of the intranet. Rather than having to overcome resistance to change, the early and authentic participation of users can avoid resistance from gaining any traction in the first place.
(This slide here purely to deal with the Notes being longer than a page)I am not so idealistic to think that all resistance will disappear. There will often be changes that are necessary for business or technical reasons that are unpalatable to some of the users. There will often be obnoxious people who oppose any change, or insecure people who passively undermine the process. There may be times when such people can’t be brought on-side and need to be sidelined. Dealing effectively with those kinds of personality and political issues is an important skill to have within the project team.
It has often been said that you can lead a horse to water but you can’t make it drink. A psychiatrist once told me “aaah, but you can put salt in the oats”. That is, you can make the horse thirsty so that it wants to drink.Authentic employee participation is one way to make the user-base thirsty, or hungry, for change. It can assure people that management has heard their cry and is working on something that will help relieve their pain. It can build an groundswell of enthusiasm for what the project team is trying to achieve.An important aspect of that dynamic is that the project team has gained permission from the user-base to make a change. The employees are not being force-fed some pig slop, but are being drawn towards the aroma of a feast they helped to create.It is also important to gain permission to proceed from other stakeholders, such as the IT department who must provide the infrastructure to host the intranet, and the finance department who must provide funds.Coffey International: had recently undertaken a massive organisational restructure and there were still a lot of projects dealing with the effects of that transformation. The company was showing signs of change fatigue and consequently established a Change Control Group. The company’s appetite for change was then mediated by the CCG. Any project that would cause internal change, or even substantial internal communication, needed to be approved by the CCG. The intention was not for the CCG to veto any project, but to add a rate-limiting step so that people were not overwhelmed by too much change all at once. I was leading a project to migrate the intranet from SharePoint 2003 to 2007. Gaining permission to proceed from the CCG was a crucial step.
(This slide here purely to deal with the Notes being longer than a page)One model of change management, from Kurt Lewin, emphasises three stages: Unfreeze, Transition and Refreeze. That is, one must first loosen up an organisation, or prepare the soil to use another metaphor, before making a change. Then the transition from current to future state can be made. And finally, an important part of managing the change is ensuring that the change sticks; that the new state is sustained.The concept of unfreezing the current state is closely associated with the need to build an appetite for change. Going back to the example of Coffey International, the corporate restructuring was prefaced by a year-long process of motivation for change that including circulating lots of copies of a book called “Our Iceberg is Melting”, about a penguin colony coming to the decision to leave their traditional home.So how else might an intranet team help to unfreeze key stakeholders, or create a thirst for change by putting salt into the corporate oats? Perhaps by writing and circulating a clear business case for the project with a compelling statement of the expected ROI.Sometimes people suffer a sort of malaise about the shortcomings of the current situation. It may be useful to educate people about the inadequacies or inefficiencies of the current state and to show them examples of something better. So you might compare your organisation's performance with competitors or industry benchmarks and highlight how far you are falling behindShow people the results of last year’s Intranet Innovation Awards to inspire managers about what could be achieved
About the only thing to be sure of in the creation of an intranet is that change will keep happening.The org structure will changeBusiness priorities will changeThe supporting software will changeKey people on the team will changeExternal sponsors will changeSo plan for change.Don’t link the information architecture or navigation framework so closely to an org structure that massive manual work will be required whenever the org structure changes.If org structures appear in navigation menus, implement those menus dynamically based on a database query rather than hard-coding themSegment the storage design (through site collections for instance, if you are using SharePoint) so that portions can be moved around independently. Consider a global company whose IT department has decided to establish several regional data centres. The responsiveness of the intranet may be improved by moving departmental web sites to the data centre closest to the departments’ physical location.Create templates so that new sites can be added to the intranet as quickly and consistently as possibleDesign for decentralisation. People throughout the organisation need to be empowered to add and update content, not relying on a centralised intranet team to do so for them. That requires training to be provided for many people. It requires a decentralised security or permission framework. It requires ownership and governance to be clearly defined.What’s the process for deciding about changes? Who has to be consulted? Who is the final decision maker? Who needs to be informed about the decision?What’s the process for quality checking? Who’s responsible for ensuring currency of information? Is there an way to generate automated reminders that prompt content reviews?
A communications plan outlines the schedule of communications emanating from the intranet team for the life of the project. This includes your intention to:Send emails advising people about what to changes to expectKey meetingsPresentationsArticles in internal newslettersNotices about training sessionsRequests for assistanceAnnouncements of launch datesIt has two main sections. First, the comms plan describes the key elements that will unify all the project communication.What is the name of the project?A tagline or catch-phraseLogo, colour palette and other branding ingredientsWhy is the company doing this project?What are the expected benefits?Who does communication come from and who do employees contact for further information?How is this project positioned in relation to other systems and processes?These are essentially marketing concerns and it is important to realise that internal marketing of any major intranet project plays an important role in setting expectations, generating enthusiasm and reducing resistance.
(This slide here purely to deal with the Notes being longer than a page)Second, the comms plan includes a table with a row for each intended piece of communication. Typical columns in the table are these:When will this communication be sent, either a specific date or relative to some project milestoneIn a few words, what is the purpose of this communication, e.g. to invite people to a usability testing sessionTo whom will the communication be sent?What are the key points to include in the communication?How will the communication be delivered? In HTML via email? As a news item in the monthly employee newsletter? A verbal presentation at a meeting of department heads?What response do you want to elicit? Does the recipient need to reply or act in some way? How will the recipient be changed by the communication: increased understanding? More enthusiastic?Who is responsible for writing and delivering the communication?A thorough comms plan can help keep the project on track by ensuring consistent messaging, forcing the project team to think systematically about the interface between their project and the rest of the organisation, ensuring good coverage across channels and across org structures, and avoiding last minute or forgotten messages.
User testing is well recognised as an important ingredient to the success of any technology development. We no longer simply assume that the designers’ expertise and intuitions will produce a system that the target audience finds usable. It is important to test design choices early so that adjustments can be made before it is too expensive to do so.But I want to emphasise something else here rather than just the standard paradigm of usability testing.Just because an intranet is usable does not mean that it will be used. For a person to use an intranet, it certainly must be usable. Systems that are difficult to use -- by poor choice of colour contrasts, by unintuitive navigation, by irrelevant search results, by illogical process flow – such systems will lead to high error rates, personal frustration, and wasted time. But an intranet might avoid all of that and still fail to gain a critical mass of users because it does nothing useful for those users. To be useful, the intranet needs to help a person achieve some goal of importance to that person.As a consequence, it is very important to listen to user reactions, even when they don’t relate directly to the design choices you are seeking to test. If the test subjects go away having completed the test tasks successfully and yet are unenthusiastic about the outcome, it might indicate that you are designing a solution to the wrong problem. Conversely, if the test subjects all say “Wow, I can’t wait for you guys to finish that site – it will save me at least three hours a week!” or “I’m going to tell all my team about this because it is exactly what we need to work together more effectively” then you know you’re on the right track and getting the usability right is just a minor detail.
(This slide here purely to deal with the Notes being longer than a page)Late in the project, when usability testing and subsequent design decisions have been made and the changes implemented, the focus of the project team moves to the roll-out phase. In many cases, roll-out is incremental rather than achieved across the whole organisation all at once. There are still opportunities to adjust the system in response to the early reactions to the roll-out. Running a pilot project is a good way to see how the changes work in an authentic context. User reactions are often different in a pilot, where they are doing real work with the system, than in an artificial test environment.Choose a small but representative group within the organisation to work with. Role out the changes just to that group and evaluate the degree of success. This helps to iron out not only technical issues but also procedural ones such as whether the communication plan was effective.
As we saw earlier, one of the ways intranet projects can fail is if they don’t gain a sufficient body of users to be sustainable. Without a critical mass, the intranet can become stale and lifeless. People will find other routes to achieve their goals. “If no-one else is using it, why should I?”There are numerous ways to attract a sufficient number of people to the intranet, but I’ll mention just three.First, a lot of the actions I have suggested already are designed to create expectation and excitement. The intranet team can promote the project before and after it goes live. For instance:Run launch events across all the officesCollect and advertise success storiesEncourage conversation about the intranet, even design conversation into the intranetAcknowledge contributors, even build some contribution indicator into the intranetPerhaps more important than anything else is giving people a reason to come back.Is there something they need that can only be found on the intranet? In particular, is there some information that changes frequently that people will wish to see the latest version?An internal personnel directory? The cafeteria menu?Try to find out what the most useful, or most often requested, information is within the company. Make sure the intranet has that available front-and-centre the day it goes live.
(This slide here purely to deal with the Notes being longer than a page)Thirdly, there are legitimate avenues for managers to simply require employees to use the intranet. Contributing to an online community of practice may be a performance criterion in some people’s annual review. The process for recording timesheets or applying for leave might force people to use the intranetIn a project-oriented organisation, teams might be required to store and access project documentation through the intranetWe would hope that once they are forced to go there, the employees will stumble onto other benefits: seeing the latest internal news, connecting with colleagues, finding technical information that helps them do their job better, notifications about relevant training courses, quicker access to the internal help desk etc.
Well that’s my 8 action points for you.But wait, there’s more. For today only I offer you a bonus verb. 9 for the price of 8.Why are our intranets so serious? Why so business-like? Cold, rigid, controlling, risk averse?In your next intranet project, please suggest what many public web sites have already profited from: that a friendly, quirky, light-hearted persona can turn a dehumanising technological experience into an engaging, pleasant and interpersonal experience.