Scriptorium Publishing

content strategy consulting

Managing DITA projects (premium)

July 11, 2014 by

A DITA implementation isn’t merely a matter of picking tools. Several factors, including wrangling the different groups affected by an implementation, are critical to successfully managing DITA projects.

Note: This post assumes you have already done a content strategy analysis, which determined the DITA standard supports your company’s business goals.

Wrangling people

Good content addresses its audience at the right level. During a DITA implementation, you must do the same when working with the different groups affected by the DITA project. Talk to them about their particular concerns and requirements in language they understand.

circus tent

Managing DITA projects is a lot like running a three-ring circus (flickr: Nathan King)

For example, engineers who occasionally provide bits of content don’t care about all the fancy features of the XML authoring tool used by the tech comm group. The engineers are far more interested in contributing content as quickly and easily as possible (through a simple web interface, perhaps). Also, engineers will understand the value of DITA’s topic-based, modular approach when you compare DITA to object-oriented programming.

Content modeling

Even though you’ve chosen the DITA standard as your XML model, you still have to do content modeling. You can start by creating a spreadsheet cataloging the tags in your current template and then list out the DITA equivalents. Seeing how existing information works in DITA is a good way to learn the DITA structures—but be careful not to focus exclusively on how you created content in the past. You probably didn’t follow DITA best practices in your old content, so be aware of what you may need to change—or throw out altogether—to develop quality DITA content.

You also need to figure out how to track metadata—data about your data. In DITA, much of your metadata goes into element attributes. You can use those attribute values in many ways, including filtering what content does and does not go into output (conditional text), narrowing your searches of DITA source files, and including processing instructions for particular forms of output (for example, the IDs for context-sensitive help).

Metadata isn’t just at the topic or paragraph level, either; you need to think about its application at the map file level. (The map file is what collects topics together for an information product such as a PDF book, a help set, an ebook, and so on.) In map files, there are elements expressly for tracking publication-level information: publication date, version, release, and so on. Don’t fall into the trap of thinking metadata = attribute.

There are other content modeling considerations. Do you need to create a new element or attribute type through the process of specialization (creating a new structure based on an existing one)? Also, how are you going to use special DITA constructs, such as conrefs (reusing a chunk of text by referencing it) and keywords (variables for product names and other often-used words and phrases)?

Evaluating tools

Choosing a tool is not a content strategy. Choosing tools that support DITA does not mean you have a DITA strategy.

Ensure those evaluating tools aren’t suffering from “tool myopia.” They should not use their current tool’s capabilities as benchmarks for a new tool, particularly when a group is moving from a desktop publishing tool to an XML editor.

Also, tool requirements go beyond primary content creation. Think about the entire workflow; get input from all the groups affected by your DITA implementation, and remember that a tool for one group may not be a good fit for another.

Create a weighted spreadsheet so that the really important requirements get precedence during ranking. Also, you don’t have to limit your requirements to “yes or no” questions. If necessary, create short narratives that explain specific use cases and ask vendors to demonstrate how their tool supports those use cases.

Parse vendor claims carefully. Ask specific questions about a tool’s support of DITA constructs: How does your tool support the use of conrefs? If you’re not comfortable with the answers you get from a vendor during the evaluation process, you’ll continue to be uncomfortable (and unhappy) after you purchase a tool from them.

Strongly consider involving a third-party consultant (yes, Scriptorium!) in developing requirements and vetting vendors. The consultant can help you cut through the bunk and also act as the “bad cop.”

Understanding outputs

Default outputs (PDF, HTML, and help) generated from the DITA Open Toolkit are hideous—but fixable. Don’t be scared off by the ugliness of default output, and don’t let project naysayers use the default formatting as a cudgel: See, we can’t use DITA because the Open Toolkit doesn’t create decent output!

Take a software development approach to your outputs. For PDF content, you can create requirements that specify the formatting for different heading levels, admonishments, body paragraphs, steps in procedures, tables (both for table formatting itself and the text in the table), and so on. If you want to re-create what you have in a template file for your current text processing tool, you can take all the formatting aspects (font, line spacing, indent, color, and so on) from it. Detailed specs are going to make it easier to modify the stylesheets that transform your DITA XML into PDF, HTML, and other outputs.

Get significant budget for modifying the transformation stylesheets. PDF transforms are the most complex and expensive; transforms for web pages, ebooks, and so on may run less, but that depends on their complexity. Even if you have transform experience in house—and most companies don’t—you still need to block off that person’s time, and that is an expense as well.

Considering conversion

Before you even think about conversion, research DITA best practices. Reading the DITA spec won’t help you with that. Instead, get a book such as The DITA Style Guide (download the free EPUB edition) that offers advice on the best ways to implement the many elements and features in the DITA model.

If your legacy content is not tagged consistently and has lots of formatting overrides, you cannot convert that content cleanly through scripting. Also, if your content is not easily broken into chunks that are the equivalent of DITA topics, you may be better off just starting over.

Even if you’re not going to convert legacy information, you still need content to test your DITA model and the transforms for output. Create what I call a “greatest hits collection” of DITA files that represents real-world content you create and distribute. I’d recommend 50 to 100 pages of content to be sure you’re thoroughly testing your processes and outputs.

I have yet to see a conversion project completed without some sort of complication: there is going to be bad tagging, layout quirks in your source, or some other lurking horror that will pop up. Resign yourself to dealing with these surprises, and give yourself lots of lead time so you can handle those issues.

Read more tips on converting legacy content to DITA.

Have questions about managing your DITA project? Contact us. Also, watch this recording of my webcast on DITA implementations:

 

 

Keys to content strategy: consultants

July 8, 2014 by

Are you thinking about engaging a content strategy consultant? Here are some thoughts on successful content strategy consulting relationships.

Over at easyDITA, Stephen Morse wrote a great post about determining whether you need a DITA consultant:

A consultant can help you define where you want to go, then recommend the right people, process and technologies to ensure you reach your destination.

But that’s just the beginning. Once you decide that you need a content strategy consultant (or DITA consulting), then what? How do you make sure that your project is successful?

Rule #1. Understand your consultant’s scope of expertise.

The best consultant is the one who has deep expertise in your type of problem. Here at Scriptorium, we specialize in content strategy for technical content. If you need to deliver lots of content in many languages and diverse output formats, we can help you. Approximately 80 percent of our work revolves around XML and structured content; the rest is mostly unstructured FrameMaker. Need help with SEO? Look elsewhere.

Rule #2. Content strategy consultants have limited psychic abilities.

Zelda the fortune-telling dog with a crystal ball, just like a content strategy consultant

Content strategy consultants have limited psychic abilities // flickr: aussiegall

One of the most frustrating things that happens in our day-to-day work is that we carefully construct a recommendation, which is then shot down with a casual, “Oh, we can’t do that because of <REDACTED>.” <REDACTED> is nearly always important information that we should have had before we even started our work.

For example:

Client: Figure out the best solution for X.

Us: What are the constraints for X? Budget? Expense? Timing? What features are critical?

Client: A, B, and C.

Us (much later): We recommend solution S. It addresses A, B, and C in these ways.

Client: Oh, no, that won’t work. We can’t do that because (IT doesn’t allow SaaS | our CEO loves Word | our CEO hates purple | did I mention that we need to support WordStar?).

Rule #3. You are special. Your problem is not.

Over our (many) years of consulting, we have identified common problem patterns, like this one:

Our system worked fine, but now we have to scale up with lots of languages and/or lots of output formats. We cannot scale our current approach.

If your basic problem is scalability (or lack thereof), we know that we have a certain set of levers we can use, such as:

  • Automated formatting
  • Rigorous use of style guides
  • Consistent terminology

These items are the starting point for solving a scalability problem. We then add your unique content and organizational requirements to the mix to develop the right solution for you.

Rule #4: We need to trust each other.

When you bring in a consultant, you are taking a leap of faith. A great consultant will help you succeed, and all will be well. On the consulting side, we are also taking a leap of faith. Our business is built on our reputation, and a bad project will affect our reputation.

We understand the difficulty of establishing trust. Scriptorium does not resell CCMS or other software or receive referral fees from software vendors. This helps us to align our interests with our clients—our success depends on providing a good recommendation, not on referral income. Some of our projects last for years—we want to enjoy working with you and you with us. The alternative is a dreary implementation slog. So trust and a strong working relationship are critical to working with a content strategy consultant like Scriptorium.

 

Consultants: What are your rules for consulting success?
Clients: What do you need from your consultant?
Tell us in the comments.

Keys to content strategy: aligning expectations

June 24, 2014 by

An effective content strategy requires participation (preferably enthusiastic) from a diverse array of people. When you are communicating with executives, IT specialists, marketing writers, translation coordinators, and more, recognize that each participant (including you) begins with a certain set of expectations and biases.

For example, consider the proof of concept stage. What are the expectations for the proof of concept?

  • Engineers: show that something is technically feasible.
  • Marketing: show that we can produce something comparable to the highly designed content we produce now.

In one project, this mismatch of expectations caused huge problems. The question was something like, “Can we produce InDesign output from XML?” The answer, from the software side, was yes. But the proof-of-concept InDesign file was, let us say, aesthetically challenged. The marketing team looked at the very unattractive output and was ready to veto the entire workflow.

Hippopotamus: The HiPPO is the key to content strategy success

Don’t forget about the HiPPO!
flickr: frank_wouters

We have to have extreme clarity on the proof of concept. Are we showing the best-case scenario? “We created some initial output, and cleaned it up for the demo.” Are we showing the initial default output? “It’s ugly, but we can fix the formatting later; the technology works.” And most importantly, have we communicated those expectations or limitations to the people looking at the information?

Team members who are very visually oriented (most marketing and design staffers) need to see attractive demos. Team members who are very process-oriented (often IT and tech comm) need to see demos that promise efficiency. It’s also important to address not the elephant in the room, but the HiPPO—the Highest Paid Person’s Opinion.

Is it acceptable to spend six months on a proof of concept that simply moves your current PDF look and feel onto another production system? Do you need quick wins to keep momentum (and funding) going? How soon will legacy content move to the new system, or will it be updated in the old system?

If these assumptions and expectations are not aligned across the team, you are going to have some big project problems.

Other posts in the keys to content strategy series

From soccer balls to content strategy: the kick of change resistance

June 10, 2014 by

Your content strategy can learn a lot from soccer ball manufacturing plants in Sialkot, Pakistan.

The town produces 40 percent of the world’s soccer balls, and it’s now in fierce competition with other Asian companies eating away at Sialkot’s dominance in the soccer ball market.

soccer ball being kicked

Yes, a soccer post just before the World Cup (flickr: Michael Johnson)

When economists offered the plants technology to decrease the amount of wasted synthetic leather, they thought the plants would jump on the chance to adopt the innovation and save money.

Wrong!

 

“I told the owner that it’s not going to work,” says Mohammed Iqlal Urfnana, a worker at one of the soccer ball firms. He is a cutter, meaning he operates a die-press to cut out the hexagons and pentagons that are sewn together to make a soccer ball. Like many workers, Urfnana didn’t like the new die. “For us cutters, this means lower daily wages.”

That’s because Urfnana, like most cutters in Sialkot, is paid by the piece. Learning how to use the new die would slow him down, so he would make fewer pieces and therefore less money. While it was in the factory’s interest to save money by cutting the fake leather more efficiently, it was not in the worker’s interest.

Change resistance has a long, storied history of wrecking innovation in the workplace—whether it be in soccer ball manufacturing or in the creation and distribution of content. Workers become accustomed to The Way Things Are (TWTA), and talk of higher corporate profits isn’t an enticement for those doing the work to change TWTA.

In the case of the soccer balls plants, the economists offered a bonus for workers who learned about the new die. That incentive realigned the workers’ self-interest (money) with the company’s goals to reduce wasted leather. With the bonuses in place, about half of the plants implemented the new die system.

Despite the fact that money talks (and quite loudly), I’m not recommending paying content creators bonuses to learn about the tools and processes for a new content strategy. Staffers in tech comm, marketing, and support departments aren’t usually paid on a per-topic or per-paragraph basis, so that model doesn’t make sense.

However, there are other ways to gain support for new processes. Employees are often concerned about productivity loss when changing tools —reduced productivity usually means late nights at the office to meet deadlines. Simple gestures (ordering in food during those long workdays, for example) can make a huge difference in workers’ perceptions. It’s also unfair to hold employees accountable for hitting productivity benchmarks during process change, so give content creators time to adjust to new systems before calculating metrics and using them in performance evaluations.

Further mitigate change resistance by pinpointing and communicating the value of change for all the different groups affected by proposed process modifications. For example, if there is manual drudgery that everyone in a particular department hates, ensure the new process automates those tasks. Making unpleasant things go away is powerful force in gaining support. You should also offer training and establish strong communication channels for addressing inevitable pushback.

Forcing process change from the top just doesn’t work. You must align the company’s goals with workers’ self-interest. Otherwise, your strategy will end up in tatters—like scraps of synthetic leather swept from the floors of soccer ball factories.

 

Keys to content strategy: ROI

June 4, 2014 by

Content strategy requires you to connect information with business results. The key to getting a content strategy approved? Return on investment (ROI). Once you show that your content strategy is beneficial to the business, you are on your way.

Here are some common approaches to content strategy ROI.

Web analytics

Your web site offers a wealth of data about site visitors. But what does the data mean? You could base your content strategy on increasing visitors to your site, but a better measurement would be quality visits or lead conversions (perhaps people who fill out a contact form). If you run an ecommerce site, you can look at revenue, shopping cart abandonment percentage (less is better), and more to get an idea of whether and how your content is improving matters.

For most technical content, however, you need to look deeper.

Support metrics

cowbells. MORE cowbells

You can never have too much ROI // flickr: mecklenburg

Providing one-on-one support, via telephone, email, or chat, is expensive. Technical information provides one-to-many support–a single document can be read by many people, which spreads out the cost of developing and delivering that information.

Therefore, content strategy ROI may involve measuring technical support costs along with content development costs, and trying to shift customers over to using more of the self-service content instead of the technical support.

Sales impact

The basic premise of content marketing is that providing useful content leads to customers—better, more relevant content results in more sales. But how do you calculate the ROI? How do you identify the share of sales produced by better content (as opposed to a marketing effort or a sales initiative)?

You need a way of measuring why people buy your product. Talk to the sales organization and find out what sort of metrics they track. For example, do they ask people why they bought a particular product? Or do they want to emphasize a feature? Can you provide content that talks about that feature?

Another possibility would be to look at product return rates. Can better installation instructions reduce return rates? Can more upfront information ensure that customers select the right product the first time? (For some interesting statistics on product returns, check out this article by Sharon Burton.)

Time to market

Can you create content better and faster? If so, you may be able to accelerate time to market for your product, which in turn means you get revenue sooner. Time to market calculations are most common for localized content. Cutting a shipping delay from six months to three months means that the organization gets revenue three months earlier. For many of our bigger customers, this type of improvement is enough to justify a substantial investment to create a better content process.

 

Do you have other ROI justifications for content strategy?

Other posts in the keys to content strategy series

Keys to content strategy: Discovery

May 20, 2014 by

In the legal world, discovery refers to the compulsory disclosure of relevant documents. In the consulting world, disclosure also important, but it is usually spotty and not in writing. Instead of disclosure, we have discovery.

A good discovery process looks a little like the Discovery Channel line-up.

Mythbusters

First up, we have to bust some myths.

Who is the actual decision-maker? Is it the senior executive sponsoring this project? Most often, it is the person that the senior executive listens to. Sometimes, that’s the consultant; often, it’s an employee whose job title in no way indicates any potential influence.

The decision process rarely resembles the official org chart.

Deadliest Catch

Our road to a successful project is fraught with peril—and the perils, like the Bering Sea, are constantly changing.

Every project is different. Superficially, they have a lot in common—same industry, same legacy content problems, same budget limitations. But an approach of “just do what you did for customer X” doesn’t work. Instead, we need to understand all of the subtleties of a specific customer—especially their corporate culture and their risk tolerance—before making any recommendations.

The technical solutions are often similar, but change management issues and in-house skill sets affect recommendations, budgets, and sometimes even results.

Even when we put in the same technology, the projects don’t look the same.

Hoarders

All of us like to hoard things. Some of us hoard knowledge.

New content strategy often means new tools and new ways of doing things, and this can be as painful as decluttering a house.

Most people hate change and will resist it.

Understanding the level of change resistance is a key part of discovery.

Shark Week

Not all of the people we work with have our best interests in mind. Some of them think we look like a tasty snack.

Don’t be shark food. // flickr: travelbagltd

Where are the bodies buried? Is someone determined to sandbag the project and if so, why? Some projects run smoothly; others are filled with political land mines. It’s critical quite early on to figure out who is who. And bring a shark cage.

Don’t be shark food. 

Gold Rush

Gold. Gold nuggets. Gold fever.

If you want your project approved, show ROI.

Naked and Afraid

Every content strategy project starts with huge unknowns. The key to success is to fill in our gaps in knowledge as fast as possible.

At least we get to start with clothing.

Other posts in the keys to content strategy series

XML publishing: It is right for you?

May 12, 2014 by

Wondering about a transition from desktop publishing to XML publishing for your content? Check out our new business case calculator.

In five minutes, you can estimate your savings from reuse, automated formatting, and localization. If the results aren’t compelling, you have your answer—XML is not right for you. For many of you, though, the results will tell you that you need to do some additional work.

The implementation side is more complex, so we haven’t provided that calculator. (Yet.) Keep in mind that your content strategy is more than just XML publishing, and more than just cost savings, but this is a starting point.

Like it? Hate it? Let us know in the comments here.

XML business case calculator

Ten mistakes for content strategists to avoid

April 28, 2014 by

As content strategy spreads far and wide, we are making old mistakes in new ways. Here are ten mistakes that content strategists need to avoid.

1. Overly technical

Some content strategists are more comfortable with technology than with strategy. (I’m looking at you, technical communication people.) So instead of discussing how better content can help the business, they focus on how the awesomeness of DITA specialization will enable better semantics.

Which brings me to the Scriptorium’s first law of content strategy:

Every time you use a word the funding executive doesn’t understand, your project budget is reduced.

2. Bad pitches

When you ask for resources, funding, approval to proceed, or anything else, your pitch needs to be tailored to the person you are talking to. A technology-heavy pitch won’t work for the CFO. A budget-focused pitch won’t work for your technical experts. A pitch focused on efficiency and ROI will not appeal to writers. And so on.

Know your audience and deliver the message at an appropriate level.

(Yes, you’ll need more than one presentation.)

3. Ignoring office politics

Office politics are a reality everywhere. Ignore them at your peril. Content strategy is a cross-organizational function, which means you need allies. It’s unlikely that everyone you need reports to you. Let your charisma and your brilliant ideas dazzle them. Or, you know, get executive support and therefore grudging cooperation from their direct reports. Whatever works for you.

Master leadership without authority.

4. Ignoring the big picture

Some content strategists prefer to focus on copywriting, voice and tone, and other writing facets. But what is more important? Fixing typos or delivering relevant content? Criticizing someone else’s word choice or identifying effective communication channels? Style guides are important, but they are not content strategy. If you are mostly focused on word choice, you are a copy editor.

Forest, not trees.

5. Involving the wrong people

Content strategy projects are often high-profile. As a result, some people may want to participate to get face time with executives. (Others will avoid the project for the same reason.) Motivated self-interest is acceptable, but make sure that your team members also have the right skills. Beware of people who join the team because they want to sandbag the project.

Build the project team based on people’s skills and project needs. Include key stakeholders.

Don't kick Darth Vader

flickr: pasukaru76

6. Acting on bad assumptions

Bad assumptions can kill your projects, and they come in lots of flavors:

  • Long-held biases
  • Learned behavior
  • Holdover from previous job/project
  • Extrapolating from not enough evidence

Before you assume that an executive has certain strategic priorities, have a conversation with her. Often, you get different information at every level—content creators, managers, directors, and executives see their world differently. For example, I asked about localization requirements in one company and was told by content creators, managers, and directors that there were none. But the CEO said differently—he knew about a pending (large) sale that would result in a need for localization.

Validate your assumptions.

7. Not enough planning

Your strategy needs to amalgamate industry best practices with your organization’s unique aspects. Is your organization agile? Do you make products that are regulated? How quickly does your organization move and how are large projects normally handled? The answers will help you create a plan that makes sense for you.

Plan or Fail.

8. Too much planning

“No plan survives contact with reality.” (paraphrasing von Moltke)

As you build your plan, recognize that it will change. You’ll need to be flexible. The initial plan needs to be just good enough to get approval to get started. You cannot build the perfect plan, so don’t try.

Analysis paralysis kills projects.

9. Leading with technology

Choosing a particular content management system is not “content strategy.” Opening discussions about an organization’s content strategy with “And we’ve already decided to use XYZ CMS” is not very helpful. What if your strategy dictates an approach for which XYZ is not a good choice?

Unfortunately, this is a common problem. Sometimes, the technology constraints are imposed from the outside, such as the IT department that insists that SharePoint is Awesome for Everything. Content strategists should be technology agnostic.

Don’t lead with technology.

10. Ignoring internal talent

Most of the companies that hire us have plenty of talent on their staff. In those cases, our job is to amplify what the insiders are saying and ensure that it is communicated and understood within the organization.  Don’t ignore the smart people that are already on your team.

Even people who don’t commute on airplanes are smart.

What other mistakes are content strategists making? What’s your “favorite” mistake?

Alan Pringle and Bill Swallow contributed to this post.

Content strategy—cold as ice

April 21, 2014 by

Technical writing and marketing writing attracts people who love words and books. (This definitely includes me.) In the emerging discipline of content strategy, content is an asset. Its value is determined by what it can do for the business, not by artistic or literary merit.

If you are an executive who is responsible for content, this shift is welcome and long overdue. After all, content creation (and localization) is expensive, and it’s about time that somebody found a way to make it useful. But many content creators see their content not as a (potential) business asset, but as a carefully crafted, much-loved objet d’art.

In response, I give you Tina Turner.

And while I’m in the process of dating myself, here is something that explains how some content creators feel about executives who demand business results from content.

Managing the conflict between the artistic and the business perspective of content is a big part of our consulting work.

Have you experienced this conflict?

Side note: I will be moderating a panel on digital marketing at NCTA’s State of Technology event (May 16, Durham, North Carolina). Hope to see you there!

Beware the monster of change management: THE MAGNIFIER

April 15, 2014 by

For his 1959 horror movie The Tingler, director/producer William Castle had movie theater seats rigged with buzzers to scare moviegoers during a scene when the Tingler creature is loose in a theater. Patrons in those seats probably didn’t enjoy the jolt—or making a spectacle of themselves because of the Tingler’s “attack.”

If you’re managing the implementation of new processes and tools as part of your job, you’re in a hot seat of your very own—and you need to be on the lookout for another horrifying monster: THE MAGNIFIER.

Poster for The Tingler showing a chair and the words, Do you have the guts to sit in this chair?

Poster for The Tingler (Columbia Pictures)

When you’re determining how changes will support corporate goals and calculating the potential return on investment (ROI) for process improvements, it’s easy to get caught up in the excitement generated by the positive things that new processes and tools will bring.

But don’t be lulled into a false sense of security by all the goodness. Lurking in the darkness is the Magnifier, and it will pounce on you if you let your guard down.

So, what is the Magnifier? It’s a phenomenon I’ve witnessed again and again on process implementations: the very act of process change can magnify existing personnel problems in an organization.

For example, if employees do not have a significant understanding of the company’s products and goals, they may create a lot of busy work to mask their lack of domain knowledge. When it comes time to update processes, “busy worker bees” want the details of their unimportant work codified as part of the new processes to make themselves relevant and indispensable (at least in their own minds) in the new workflow. These employees are less interested in the company’s goals than saving their own skins, and that trait becomes even more evident in times of change.

Employees with control issues are highly inflexible and want everything done their way. During process change, they will take a “my way or the highway” approach. For example, if they are dead set on a particular tool set, they will sandbag the tool selection process by exaggerating the feature set of their favored tool and by overemphasizing “problems” with other tool solutions.

Before you think I’m wallowing in unproductive negativity here, please understand I have witnessed the preceding poor behavior on multiple consulting projects (and I’m not even close to cataloging all the bad stuff I’ve seen). As the manager of a process change project, you must be prepared to fight the Magnifier. Effective weapons against it include:

  • Outlining clear business goals for process change. If a proposed tool or process does not support the company’s end goals, it should not be part of the solution.
  • Establishing clear communication among all parties. Start the communication channels up early as possible, and involve everyone, even those who are indirectly affected by the process changes. The company’s business goals should be front and center as part of all change-related conversations. As the project manager, you need to differentiate between legitimate concerns and outright recalcitrance during conversations. Pushback from others can help you identify weaknesses in the proposed workflow that you had not considered.
  • Hiring a consultant, even just part-time. A consultant has seen the Magnifier do its evil thing on other projects and can therefore help you locate and dispose of it early—before it does too much damage. Because consultants come from outside the company, many employees give what they say more credence, even if the consultants end up repeating the very things you’ve been saying all along. A consultant can also act as the “bad cop” in unpleasant situations, particularly ones involving personnel changes (detailed in the next bullet).
  • Realizing that successful change management may depend on personnel changes. Implementing new tools and processes is not going to magically transform poor employees into model workers. In fact, bad employees will have a negative impact on process change. If an employee’s recalcitrance is having significantly detrimental effects, consider reassigning them to another project (for example, maintaining the legacy system), placing them on a performance plan, or even terminating their employment. You must weigh the employee’s value to the company against the drag he or she is creating on the project.

Have you fought off the Magnifier in past projects? Please detail your battle scars in the comments below.