Emma Hamer is a change management specialist and passionate about helping organizations match people to tasks. She's also trained in Classic French Cuisine as a Cordon Bleu chef, so she knows that preparation (and timing) is everything. Along with her background in technical publications, this expertise has led her to managing change that occurs when organizations move to structured authoring and content management systems. While choosing a system, converting data, and learning the software are all important steps, they are only part of the mix. The system will bring a new workflow, and the new workflow will be performed by people who need to be coached towards new behavior. No worries. Emma has cooked up to a strategy to assure your CMS implementation project is a success from soup to nuts-or should we say, du potage aux écrous.

DCL: First, how about telling us a little about yourself and what it is that a change management consultant does?

Emma Hamer: My passion is getting the most out of people, helping them do the tasks to which they are most suited and helping organizations move from managing workers' limitations to exploring and using workers' strengths. In a previous life I was a tech pubs manager for a large research institute so I am very familiar with deadline driven processes. If the concept of content management, structured authoring, and reuse of content had been around then, I would have embraced it dearly.

I got away from technical publication for a while when I moved into executive operations until I became interested in performance consulting. Performance consulting is based on the concept that no one really gets up in the morning to go to work and mess up, but if it happens there has to be a reason for it, particularly when you put it in the context of a large-scale system implementation that affects the way people work and the kind of work they do. In that context people have to learn the new system, new ways of doing things, and new behaviors. Inevitably productivity will go down initially, to come back up - and improve - as staff regains their confidence and mastery of their craft. It's that process of learning new things that fascinates me - helping people go beyond their self-imposed limitations.

But as with many types of change, it always has to get a bit worse before it gets much better. We can't really do anything about that, but what we can do is look at the circumstances we are going to put people in so we can manage the risk, mitigate the effects, and accelerate the transition for these workers in order to reach the desired results that much faster. It's also important to say that managing these changes-and all the procedural changes that go with implementing a content management system-gets better really quickly if there is strong executive support.

Otherwise one can choose to do nothing and the chances are they will not get the results they are looking for. It's clear that when companies say their people are their greatest assets, it means they need to make the kind of investment in their people they are otherwise making in software, or machinery, or equipment. A lot of companies are coming to that realization, but they may not know how. They've never done it before.

DCL: What is the key idea behind in the type of change management you do?

EH: I like to say the most important three words in moving to a content management system are: Preparation! Preparation! Preparation! Much like with cooking, you can do it all on-the-fly, without much planning, in which case you end up doing everything all at once and at the last minute. Or you can do your slicing and dicing ahead of time, as it were, look at the possible changes, conflicts, and problems that could occur, and plan accordingly.

The type of change management I do is very much people focused. I've been on the receiving end of change management in organizations where we've been told what we were expected to do and when, but given no clue on how we were actually supposed to do it. The kind of change management I help companies with is to create supportive environments that help them coach the people towards new behavior. The best way to get the value-add from their content management systems, that will help them manage content and authoring, is to ensure that the folks who will be using the system can go beyond 'coping'. Sometimes that takes a little more than just 'application training' in order to have greater success. It has been my experience that companies that are willing to invest in this type of people-centered change management absolutely reap the benefits.

DCL: You have noted in the past how some organizations have downplayed the changes that occur when implementing a CMS. What can you tell us about that?

EH: I like to compare implementing a content management system to preparing a perfect omelet. First, you are going to have to break some eggs. Then you will need to mix the contents so that each individual egg is no longer recognizable as an individual egg. The pan has to be just the right temperature with the right amount of butter. There has to be an understanding of how egg solidifies, how to manipulate and fold it so that it cooks through steam instead of through heat. It's not enough just to break the eggs. Even the most enlightened companies only invest in application training or train only one or two persons in writing DTDs thinking that is all they need. But that's not enough. All they've done at that point is broken some eggs.

While investing in the software training is very important, it is only one part of it. Most technical documentation professionals can figure out how to use the system. Training them on the application doesn't guarantee success. Success is just as dependant on deciding on the governance of the new process, defining the new roles and responsibilities, and analyzing the work environment. Who makes the rules around the new system? How do you get people who work in different departments with very different agendas to collaborate in a way that is effective? It's not just about having a lot of meetings anymore.

There is a saying in our industry: If you have a bad process, and you automate it, you will have a bad process that screws things up faster. If a company puts in a new system and thinks that they can continue to work as they did before, with all its dysfunction and all the broken links, they have their heads in the sand. As soon as a company changes the process, they change the way their people behave in that process. The question is not 'What kind of changes will occur?' because everything changes. The question is 'How much do we want to change?' That ties into the question 'What do we want to achieve, do better, faster, smarter than we were doing before?' The first thing they need to do is capture what they were doing before and ask if it still makes sense to do it that way. They also need to involve the people who are actually doing the work-from the beginning during the requirements gathering phase. Because that is when you build support for the changes that will come.

If what you're looking at is improving the user experience, which is very often at the core of why we are looking at managing content as a strategic business asset, you very often need to look at the internal power structures and how decisions are made. In the new environment it becomes a matter of negotiation. The engineer's expertise is in how the product is put together, and writer's expertise is in how information is presented to the user. They are the advocates of the end user. Both voices need to be heard in order to have a successful product. It's not about egos. It's about working together to produce the best product, and part of that product is the instructions on how to use it.

DCL: What are some of the cultural changes that should (or do) occur to ensure a more successful outcome of implementing a content management system?

EH: One of the biggest changes that I advocate for is the concept of real collaboration. By this I don't mean the process that some describe as collaboration, where a writer does his or her part, then tosses it over the wall to the Subject Matter Expert (SME), then at some point it comes back to the writer to make changes, then the writer sends the whole thing out for review again. That's not the most efficient process. Sometimes the writer doesn't get it back, so they have to track it down. Then they find out that so-and-so went on vacation, so it's been delayed by a week or two. How can anyone manage a department like that?

True collaboration means that people are actually working together on things at the same time. In the same room, sometimes at the same desk. Sometimes it's called co-location. Where, to develop the documentation for a product, one or two writers work in the same room with the engineer, industrial designer, tech illustrator, perhaps even the product manager. And they stay together for the duration of the project and hammer out whatever issues arise as they occur. And if anyone needs some distraction-free time to do some research or to write a particularly challenging piece of documentation quiet work areas are provided. When the documentation is finished, has been approved, and the product is shipped out, the team disbands. And a new one is formed for the next project. Sometimes it is the same team, or sometimes the team members are different, depending on what other projects the tech pubs manager has going on. So I advocate 'Death to the cubicle.'

DCL: Does this type of "off-site" collaboration make it hard for tech pub managers to manage?

EH: Not really. The work is self-managed by the team through their collaborative efforts. The team is responsible for delivering the project on time because everyone knows what the deadlines are. The team keeps one another in check so no one goes off on a tangent and the whole process drastically speeds up because there are no more of the hurry-up-and-wait problems. But the manager is still in charge of setting standards, quality control, professional development, budget, and resource allocation (among other things). It's even possible to develop an entrepreneur sort of mind-set within the company, whereby when it's time to start a new team, workers can, in a way, bid for the project they want to work on. The managers decide if that person is the right person for the project based on experience, timelines, and so forth. They still manage the people and the department, but let the team take responsibility for the work. The writers don't even need to be in the same building as the managers. Or even in the same town, state, or country.

DCL: How does this entrepreneur mind-set help improve the outcome of a project?

EH: Research has shown that if a company can increase employee engagement by as little as 10%, they can get productivity gains by as much as 50-60%. It becomes a combination of personal accountability and accountability to your team. So the manager can say 'You as a team are going to deliver this project to me on time and on budget, and if even the smallest obstacle gets in your way, it's my job to remove those obstacles. It's not my job to micromanage your team.' So the manager puts the responsibility on the shoulders of the team, giving them the authority to make the decisions it needs to make.

DCL: How can an organization avoid the pitfalls of change that occur and sometimes cause CMS projects to fail?

EH: The resistance to change sometimes has its roots in the fact that workers have spent a great deal of time and personal energy working around problems in the old system, and don't want to let go of that because they are afraid that what they are getting isn't any better than what they already have. So the key to taking away fear is to give information. Not just about what is going to happen, but how it is going to impact people. I think one of the biggest mistakes companies make is to downplay the fact that change is going to impact people and it may even impact people to the extent that some individuals won't be able to make the change. It's always going to be a little disruptive, but the plus side is that humans are very good at adapting to change. If we weren't we'd still be living in caves. But it's a process and workers will probably need some help making the change. The one thing a company cannot do is ignore the issues and hope they'll go away; they won't.

When the project is in its earliest phases and budgets are being reserved, it is important to reserve a certain amount of the budget to deal with the people issues. They are not necessarily all negative, but there will probably be a need for some coaching for the managers to help them communicate the changes to their people. There may need to be some group work with teams to understand how to get the best use of the CMS, and some help learning to interact in a more collaborative and effective way with the people who are producing the product information. Being realistic about it is very simple if you think of a triangle model for it. One side being the systems, the second side is the procedures, and the third side is the people who actually have to use the system. So if you think about investing about the same amount of effort in each of the sides you have an equal sided triangle.

Industry experts are quite clear on the fact that although 70% of the effort is made in selecting and rolling out the technology, only about 10% of impact of the success of the project hinges on the technology. Forty percent is procedures and governance, and the remaining 50% is getting the people to adopt, embrace, and use the system in a way that will actually enhance and improve the process and productivity.

DCL: And how can organizations go about actually communicating for change and managing it?

EH: I spend about 50 or 60 percent of my time working with managers on communication. The message needs to be clear from the top to the bottom. But what is really critical is that it needs to be made clear that communication is a two-way street and it's unambiguous. While organizational change needs to be championed and driven from the top, the "hows" of change need to come from the bottom. There must be a willingness for managers to say 'We will do whatever we can to help you through this change, mentor you, bring you in the process early, etc., but you need to be able to make this change,' and draw a line in the sand. Working through a change process, things are invariably going to go bump in the night and it needs to be understood that there is no room for any passive aggressive resistance, or backstabbing. And managers need to be able to confront workers when it's appropriate.

On the other hand, there's nothing wrong with an employee confronting management on things that affect their work. But managers aren't usually used to that type of environment. There's nothing wrong with respectful confrontation. Conflict, on the other hand, is a critical confrontation that has been postponed too long. We should all be comfortable confronting one another; holding each other accountable-and not just managers.

This can be done in a variety of ways. Some companies have a 12-minute meeting every morning, called an issues meeting. There is no hierarchy at this meeting. What is said there is dealt with there and if it isn't resolved it can come up at the next issues meeting. This works well in environments where there is a lot of trust between managers and workers.

In cases where there isn't that trust, initially someone else can be brought in to run the meeting so that everyone is on equal ground. If there is a change consultant working on site, bring in that person to run the meeting. If not, bring in someone from HR or the marketing department. Have the team pick the person to lead the meeting. It can be anyone, as long as they have -or can obtain- the trust of the group.

DCL: What is the advantage of bringing in a consultant versus organizations trying to manage the changes themselves?

EH: Most tech pub managers are under a lot of pressure and have a lot of projects going on. So I consistently say that unless your organization is large enough to support a dedicated organizational development group with internal people who can give the project the constant attention it needs and can constantly reinforce the new way of doing things, bring in a consultant. The benefit is in avoiding much higher costs of project failure later on, plus the indirect benefit of workers having the sense that the company is taking the process of their transition seriously enough to put some resources into it, rather than just sending them off for training for a day or two. In the long term it will save a lot of money, but it does cost something to hire a consultant.

DCL: Where can our readers find you and find more information about this topic?

EH: I've written a number of articles that are published on my company website I regularly present on this and other topics at STC, ISPI and CMPros events. Readers can also call me at 604-317-2234, or email me at info@hamer-associates.ca

DCLNews Editorial
September 2007