The industry statistics for technology implementations speak volumes. The KPMG Canada survey reported a 61-percent failure rate on projects. The Standish Group's famous Chaos Chronicle III reports that 66 percent of major IT projects fail. If you consider that U.S. companies spend more than $300 billion on IT projects annually, that translates to roughly $200 billion lost on projects that fail before reaching their intended launch date. In any other industry context—airlines, for instance—this would be an intolerable statistic. Would you fly a plane that had only a 34-percent chance of landing safely?
What is interesting about this issue is that, upon closer investigation, very few of the reasons for project failure—over-bloated budgets, derailed schedules, scope overruns, lack of buy-in within business units or unanticipated project risks—have anything to do with technology. Yet technology always seems to bear the responsibility for project failures.
Is your organization different?. If you think that your organization is beating the odds, guess again. Even if you believe that your company is doing better than the national average, there is probably room for improvement.
How the publishing industry measures up
The publishing industry, in general, is in the high-risk category when it comes to technology implementations for the following reasons:
- No IT project expertise. At the heart of the publishing business is content, which is the domain of content creators, such as authors, editors, photographers and designers, and content producers, such as the prepress and printing professionals who control the mechanics of publishing. The leadership of publishing houses is drawn from these content creators and producers, who rarely, if ever, have formal training in IT implementation processes. Technology projects driven solely by content experts without IT expertise have an increased chance of failure.
- Lack of publishing expertise in IT. The people in publishing IT departments who have come from solid engineering and project-management backgrounds rarely have publishing-domain expertise in editorial, design and production processes or tools. Cases where technology projects are driven solely by IT staffers—without participation of content experts—have an increased chance of failure.
- Methodology (or the lack thereof). Publishing companies, like many other vertical-market organizations, either do not have documented procedures for IT implementation or have procedures that are not strictly enforced. Without repeatable procedures to define requirements and then evaluate, procure and implement technology, projects have a higher than normal failure rate.
- Workgroup-driven projects. Most publishing companies have numerous vertical business channels with separate policies, workflows and business goals. These channels have difficulty communicating effectively with one another about IT implementations. The result: duplicated requirements in "balkanized" systems, requiring additional enterprise application integration software to get everything to work together, if at all. Another result is that one business division attempts to predict requirements of another, but falls short, and then tries to push the new technology onto the other division(s). This approach rarely succeeds.
- If you build it, will they come? Insufficient weight is given to gathering requirements from the end users and then managing how their professional lives will change once the technology is made available to them. Assiduous attention to how technology will affect the daily working life of end users is a hallmark of the successful IT implementation.
- The cart before the horse. It is common for management to believe that installing new technology will solve business problems as advertised. Some organizations go so far as to select a product without gathering requirements from the end-user community. This is tantamount to letting a different organization—the software vendor—dictate your business strategy, since it has envisioned functionality that you may not need without satisfying functional requirements that you must have. Publishing organizations get into trouble when they look at products (demos, literature, sales pitches) and use that to shape technical strategy. There is some wisdom in looking at software to see what is available in the market, but it is risky to do so before defining the objectives, requirements, resources and processes that must support this new model.
Minimizing your risks
Changing your operational approach to IT implementations may at first seem like a daunting task. However, instituting incremental changes will improve your chances for success. While this is a long-term strategy that should start at the top echelons of your organization, there are still things you can accomplish to keep your project goals on track.
Here are some ideas you might consider.
Understanding business objectives. As a project leader, before you begin to consider technology or gather any requirements for a new system, you will need to have a clear understanding of your organization's business objectives and be able to embed those objectives into your project goals. In past years, the publishing community was typically more reactive in selecting technology. We recommend that you document long-range goals for your organization, against which future technology acquisitions must be weighed.
Consider the case of an association that serves professionals in the aviation industry. After 9/11, the CEO determined that the organization should be better prepared to communicate about aircraft advisories, airport conditions and other important aviation information through multiple media channels. Once he articulated this major objective, all subsequent projects have been weighed against this main business objective.
IT department as consulting resource. This is a sensitive subject for many organizations. IT is often seen in the publishing world as an impediment to rapid deployment of technology. Because of this negative perception, workgroups and business units often deploy technology without the IT group's knowledge or sanction.
In the past, IT employees were thought of as glorified technicians—the ones called in to fix a broken computer or a malfunctioning network router. Today, organizations either create strategic consulting groups within the IT department or partner with a trusted consulting organization in order to:
- a) Protect the company's business objectives — does the business unit's needs conform to the organization as a whole's goals?
- b) Assess feasibility—is the proposed project or its parts feasible technologically and logically?
- c) Analyze the business case—how do we justify the initial and ongoing costs weighed against the benefits of the proposed system?
- d) "Blueprint" IT strategies—do business units share the same goals, and can they reduce redundancies and complexities by sharing technology?
- Consider the case of a major direct-mail publisher, where an internal IT consulting group has worked alongside editorial and production groups for the past few years. Management continually seeks ways to improve its publishing processes around direct mail. The IT group researches new technologies, meets with business units about their workflow requirements and business needs, then makes technology recommendations.
Management requires a formal feasibility study and ROI estimates to prove that the technology will both conform to the company's objectives and perform the needed functions. Over a three-year span, the internal consulting group has instituted in-house prepress capabilities, direct-mail automation and enhanced workflow, saving the organization several million dollars annually.
Project-management methodology. One of the best ways for you to improve your company's success rate with projects is by defining solid project-management methods. The goal is to define repeatable procedures for managing the life cycle of a project from inception to completion. This will offer a common language and rule-set to all participants in your organization, as well as to any external vendors you employ.
Many companies create templates for activities such as business-requirements analysis, functional-specification definition, communication planning, change controls, risk management and so forth. This reduces the need to reinvent the project framework with every new project. While there are many resources to help you define your project-management methodology, a good place to start for this type of framework is the Project Management Institute's Body of Knowledge, or PMBOK (www.pmi.org).
Consider the case of a global educational publisher with years of difficult project implementations. The company hired a senior project manager to implement an enterprise digital asset management system. Using DPCI's standard project-management methodology (based on PMBOK) as a starting point, the company teamed with DPCI to implement the DAM system, then further instituted a variant of that methodology for all new IT project deployments. Subsequently, the organization has developed an internal project-management office (PMO) to help define and guide project methods for the entire company.
The project-management standards that you devise should be a living, breathing rule-set that should be adapted as your organization faces new challenges. You will want to create a basic framework or set of guidelines that will help your project members meet the goals for each implementation.
Executive sponsorship. Regardless of industry, any project has a greater chance of succeeding if an executive in the organization steps forward to champion its cause. The executive sponsor ensures that resources are made available on a consistent basis throughout the course of a project. The sponsor also owns the project, so it is in his or her best interest to periodically audit the project to determine if it is meeting management's objectives.
We've seen powerful results stemming from strong executive sponsorship. For example, the CIO of a major publisher of government news on Capitol Hill was retained to revolutionize IT processes for the organization. He not only set up an internal consulting practice within IT, but also added teaming methods with product vendors and consulting partners. The organization has experienced remarkable results with recent technology projects, such as a new pagination system, a content Web portal that has remained profitable over three years' time and a recent move to a multimillion-dollar state-of-the-art technology facility.
Cross-functional teams. Technology is typically used in different ways by people with different roles in the organization's workflow. For a system to be implemented most effectively, the project team must consist of a representative from each of the different constituents that will be using that system. One of the biggest mistakes organizations make is to allow only a few people to take ownership of a technology project.
In the case of publishing systems, technology projects center on content or managing information about content or businesses supporting content. This means that content experts (creators and producers) need to collaborate with IT project planners, database experts, information design experts and other related application or Web-based skill sets. It is not possible for any one department or group to possess all of these disparate skills. To ensure success, cross-functional teams should be created consisting of representatives from each project area.
Consider the case of a weekly business magazine that went to every business unit, mapped out internal and cross-department workflows, discussed business requirements for a digital asset management system, and then mapped out the technological processes needed to support this new system. Although the project is still under way, we feel certain that this company will make a strong product selection and will have higher end-user satisfaction once the technology is implemented—provided that it upholds the work products that the cross-functional teams have prepared.
Communicate. Critical to any successful technology implementation is that the people who will be affected by the project know what is going on. We have already stated the importance of interviewing business end users for their requirements. Once you have interviewed end users during requirements gathering, don't forget them. You will always need to circle around to them, asking their opinions on the project progress, or inviting them to test out various aspects of the technology.
Your business leader—the CEO or someone from the executive team—should communicate with staff about how the project fits into the greater goals of the company. This will help motivate project participants to succeed and will help with end-user acceptance as well.
Finally, communicating your project's goals and progress is a bit like an internal marketing campaign. Use any internal advertising or marketing capabilities your business has to publicize project goals and benefits to the end users. Internal marketing can be in the form of traditional print, face-to-face meetings or group presentations. Be prepared to get critical points of view, and make sure that you take down people's comments and do something about them. Reporting back to the commentators about what will be done goes a very long way toward winning champions for your project.
Is it possible for publishing organizations to revolutionize the way they approach IT implementations? We believe so, but only if management first admits that there is a problem with technology failure rates being too high. Technology is integral to supporting the publishing organization's business model. As a result, you will need to invest in infrastructure to support strategic activities within IT to improve your chances of selecting and implementing the right technology for your business.
We close with a dramatic example of one international travel company that made the painful transformation. This customer has a reception area in one floor of its building with a polyurethane floor that consists entirely of proposals submitted at various times over the years representing projects that never got off the ground, or that failed completely. In spite of this, the organization was still able to generate incredible revenues over those years. The technology failures did not receive a great amount of attention until the recession hit and all processes and expenditures were thoroughly evaluated.
During the course of an enterprise catalog- management system project implemented by DPCI, the management of this company first resisted, then embraced the project-management principles DPCI espoused through the course of the project. The project was not without speed bumps, but ultimately succeeded in reaching its intended goals. Since that time, this organization has begun an internal audit of project-management procedures, working toward the goal of improving success rates on future engagements. DPCI's impression as it continues to serve this customer is that the improved project-management infrastructure has engendered an environment that enhances IT implementation success.
(Note: this article was written in 2004 by DPCI CEO Joe Bachana)
Statistically, two out of three IT projects fail, and historically publishers are notoriously bad at managing technology projects. The failures are often blamed on poor technology, though that's seldom the real reason. Here's a primer on the managerial steps you must take to put your next big project into the success column. Publishers today, in order to respond to both a shifting market and fast-growing consumer demands for digital content, are attempting to do two things: build capabilities for reusable content and reduce operational costs. These business-critical yet seemingly contradictory goals depend upon technology solutions that wholly integrate into the daily lives of publishing communities—employees, partners and customers.