Project on contingency

In recent years, many companies have invested heavily in IT systems in order to become the industry leader or to gain a competitive advantage, believing that this will bring huge returns. But the result is often dashed hope, hard work only in exchange for failure. More than half of the investments were in so-called "packaged information technology," or information technology that can be used for the entire business process of an enterprise, rather than technology for individual work tasks. Such technologies include enterprise resource planning (ERP) systems, supply chain management (SCM) systems, customer relationship management (CRM) systems, and e-commerce systems.

Multiple case studies have shown that 30%-75% of new IT systems fail to meet expectations, generate significant profits, improve work processes or bring about new organizational changes. In some cases, the results were even catastrophic. Nike, for example, spent hundreds of millions of dollars developing a system to predict sales, but the results were wildly inaccurate. Hershey's missed the Halloween season by not stocking enough candy at major retailers. FoxMeyer Drug filed for bankruptcy at least in part because something went wrong with its ERP implementation.

Failures like these don't happen because there's a technical bug or because no one has good advice for managers. Whether it is scholars, consultants, IT system providers, or managers themselves, they have done serious research and put forward many effective guidelines for problems that may arise during the implementation process. Nor have these guidelines been ignored. Most executives are well aware that IT project implementation is a big project with great risks, so they read books, attend conferences and training courses, hire experts, and are always trying to find the best implementation plan.

A study suggests that the problem boils down to managers who, when implementing a new suite of information systems, often follow hard-and-fast rules, believing that they apply in all circumstances (see Subcolumn "Basic Rules for Managing IT Projects").

The problem is that these rules assume that all system implementations are essentially the same. That is, they are just undifferentiated findings and conclusions, not comprehensive solutions that can help implement a particular system. The manager responsible for implementation has to discern which conclusions are applicable under what circumstances and why.

Managers don't need to listen to any good words. What they should do is to treat things differently, because changes in the external environment determine that the implementation of each IT project is different, and the implementation of each project is buried. There are hidden dangers, which will make the utility of the project deviate and reduce the investment value of the project.

Ground rules bring five hidden dangers

When following ground rules to implement a project, pitfalls can crop up. No matter how hard managers try, five pitfalls are bound to arise: inertia, wrong definition, misuse, and abandonment.

Idleness is the main perpetrator. Although everyone agreed that implementing the project was a good idea, there was a lack of timelines and decisiveness in the execution. This situation is easy to find, for example, there is no deadline for project implementation, the project schedule is always delayed, and the date for the project to be put into use is still far away. Laziness is very expensive. Staff and consultants were paid despite nothing being achieved.

A number of factors increase the likelihood of laziness delaying project implementation. One factor is introducing too many new systems at the same time, say introducing an entire ERP system at once. Another factor is the complexity of the project itself. Laziness also increases when a new system affects multiple departments in the enterprise, fearing that the implementation of the new system will jeopardize their original position in the enterprise. Naturally, they will slow down in the implementation of the project.

The second hidden danger arises when people have different views on how the project should be implemented or whether it is necessary to implement it. Like inertia, the lack of an execution schedule can make resistance more apparent. But inertia and resistance are easy to distinguish, as resistance is marked by arguments, overt or hidden hostility to projects, sparring with all kinds of political tactics, and refusing to give an inch to keep one's sphere of influence.

The third pitfall is misdefinition. When a project is incorrectly defined, it can be implemented successfully on a technical level, but does nothing to improve business performance. Misdefinitions can also arise when companies outsource IT technology to improve business process templates. Customized templates can become unstable and negatively affect other related templates.

The fourth danger is misuse. If the users of the new system are ignorant of the new technology, the system itself is a brand new system, and the system involves multiple departments in the enterprise, or involves more than one enterprise, misuse may occur.

Abandonment is a more subtle pitfall that only arises when people have discretion, that is, failure to use a new technology does not automatically jeopardize the execution of other tasks or projects. If people had this option, they certainly wouldn't adopt new technology, especially if it affected their core business, or if the new technology was too advanced.

Instead of treating different system implementations indiscriminately, business leaders should begin to consider the pitfalls they may face and develop countermeasures to address them. Here are five main areas where managers need to make choices:

● The level of the project (which level of the business affects the most)

● The most beneficial management style (the top-to-bottom implementation) or negotiation)

● the scale of the project (only partial or comprehensive)

● the choice of the timing of the project (step by step or one step)

● Degree of enterprise readiness (basic or adequate)

Project leadership: senior or non-senior

To avoid the potential for inertia and resistance, project managers and project supporters High weights are important. Those who have the power to make important decisions should be able to ensure the smooth implementation of the project. Without such authority, groups with different vested interests in the enterprise may adopt a conservative attitude (inertia) or insist on a stubborn position (resistance) during the project implementation process. The more interest groups there are, the more likely it is that one or both of the above pitfalls will arise.

In this case, an effective approach is to select a person above all relevant groups to manage the project. That is, the ultimate decision maker for the project is someone higher than all the relevant group members. This is also the approach Cisco has taken to overcome the hidden danger of inertia. When implementing ERP, it is led by the Chief Information Officer (CIO) and the VP of Production, who report directly to the Board of Directors. Senior leaders ensured that the company completed the implementation of the complete new system in less than nine months, which is very fast in terms of effort.

Does the Cisco example imply that all IT projects require senior leadership involvement? of course not. When the project involves only a certain group in the enterprise, it can be solved within the group without the intervention of top management. A sales automation transformation is one such example.

Management Style: Directive or Consultative

Regardless of their level, project executives can choose how to conduct their work. They can adopt a top-down, iron-fisted style of management (command management style) or a bottom-up management style based on the participation of the whole group (consultative management style). Most managers use both, but it's important to differentiate because each style works in some situations and not in others.

The imperative style is suitable for large companies like IBM, Tektronix, and Harley-Davidson. In these companies, the business of the company is not very complicated, the employees are familiar with the IT business, the management style of the company is also imperative, and the employees have no say in the adoption of the new system.

But in at least three cases, using the imperative style is a bad idea. First, when the new business process system is very complex, or has the potential to be incorrectly defined, it is a mistake to decide on the system structure too quickly or not to hear more. Second, if the adoption of new technology is not mandatory, an iron-fisted style increases the risk of abandoning it. Third, if the project involves more than one enterprise, the imperative style cannot be adopted. Quite simply, most enterprises are reluctant to let people from other enterprises decide their own IT projects.

In these cases, a negotiated style must be used. Project leaders must bring all adopters together, move the project forward gradually, listen to everyone and seek their support. This style works well at Alibris, an online company that helps people find old and out-of-print books.

A respected bookseller used his industry background and connections to persuade a group of booksellers to contract with him to create Alibris. When it is necessary to update technology or change business processes, Alibris consults with customers, explains the reasons for improvement and the benefits of improvement, and then makes corrections based on customer feedback. Like Amazon, Alibris will also consider keeping in line with the wishes of large customers. Alibris has recognized from the very beginning that the resources at his disposal are only a small part, and success can only be achieved by relying on the participation and consultation of all clients.

Project Scale: Partial or Comprehensive

One of the most effective and direct means for the project executive manager is to determine the scope of project implementation. The scope of a project's implementation can be divided by department (Should Sales and Marketing be included?); By Geography (Should Latin America be included?); or By Technology (Should Database be included?) . Reasons can often be found to extend the scope of the project to the entire enterprise: for example, taking on a large project can turn a business upside down, and improving more business processes can double its profits.

However, project leaders must consider scaling down the project when the pitfalls of inertia, conflict, and misdefinitions can arise. The smaller the project, the more flexible it is, the less likely it will cause internal fighting, and the less chance of technical errors.

If possible, it is best to scale down the project before it is launched, but scaling down halfway through the implementation is also effective. A few years ago, medical device maker Becton Dickinson found that project implementation was bogged down, largely because of inertia and partly because of resistance. Company leaders reviewed the entire project and decided to exclude some sites, features, and modules. After that, the project execution team was more able to focus on the remaining projects and found it much easier to implement the project across the company than it used to be. As the scale dwindled, there was a turning point in the progress of the project.

Execution schedule: Phased or one-off

Under certain conditions, managers have a lot of freedom, they can extend or compress time, push the project forward or retroactively, move a large project The implementation process is divided into many small stages. Few of the major projects currently underway are accomplished overnight.

Many projects are implemented through a series of stages, each divided by function, department, or geographic area (sometimes a combination of all three). Proper phasing can positively promote the project and thus avoid abandonment, but its greatest strength is that it effectively avoids mis-definitions.

The step-by-step process enables enterprises to continuously learn which parts are working well and which parts have problems during the progress of the project. Through repeated inspections of IT and business processes, the mistakes made in the past can be found and improved in time. In the late 1990s, Nike made the mistake of being too hasty when it bought the SCM system from i2 Technologies. Nike soon found that the accuracy of the system's predictions was very low, causing some products to be over-produced and some products to be under-produced and in short supply.

In addition, Nike discovered that some production orders were being double-counted in the system, while others were being missed and not produced. In 2001, Nike complained that sales fell by a quarter to $100 million because of system software problems. But i2 accused Nike of not adopting the business process design in the original software, but made major changes to the software and made inappropriate changes to the supply and demand planning software.

The two companies did not agree on what was wrong with the system, but it was clear that the system was very complex and that modifying the software modules to meet Nike's needs was the only functional requirement of the system. It is precisely because of these characteristics that appear in the process of project execution that the wrong definition becomes a real and potential hidden danger.

In addition to advancing the project in stages, there is an option to introduce an entire new technology to the enterprise at once. This approach is only effective when the hidden dangers of misdefinition, misuse, and use are not serious. For example, a few years ago, Quantum, a $4.4 billion maker of disk drives, put its ERP system into operation across the enterprise at once.

Being decisive is not about choosing between "one-shot" and "incremental" models. Managers should have the judgment to decide how far each step needs to go, whether to choose a series of small-scale, multi-stage processes or a larger, fewer-stage process. In general, take big steps to avoid inertia, and take small steps to avoid mis-definition, misuse, and uselessness. Because ERP implementations are susceptible to the first two pitfalls, it's best to take the leap. The implementation of SCM is susceptible to the influence of the latter three hidden dangers, and it is best to take small steps.

Preparations: Basic or Sufficient

Of course, some preparations must be done, and employees should know how to introduce new systems and learn how to use them. But in addition to these most basic preparations, preparations are also very different according to different needs. For example, if the end of the system is only some daily affairs and peripheral online business process processing (such as office supplies management or travel expense reimbursement management, etc.), and these are for employees who are familiar with IT business. Misuse is less likely in these cases, and mandatory orders can be used to avoid misuse so that rolling out the new system in the enterprise is not difficult.

But in most cases, the hidden dangers that need to be fully prepared to deal with are mainly "misuse" and "non-use". Preparatory work that must be done includes: stressing the significance of introducing new systems to employees before and during the project implementation process, training employees to use new technologies when their enthusiasm is mobilized, helping to build desktop systems, and in the later stages of system introduction Do all kinds of support work.

After Hewlett-Packard's California branch replaced the original decentralized information system with a comprehensive enterprise information system, the company's work tasks have undergone major changes and its independence has been greatly enhanced. Although the company's employees were all computer veterans, the project leaders recognized that misuse could still occur and went to great lengths to prepare. It is worth noting that after the official operation of the new system, they also provide various supports. The experts of the project execution team answer various questions raised by employees on the spot and help them operate in the new operating environment.

Also, some level of training is always necessary, but project leaders must carefully consider when to hand over resources to employees, while taking other factors into consideration and reserving some resources.

While many companies have experienced setbacks in their internal or business-to-business systems, the transformational trend to improve business processes through technological advancement is far from over. Enterprises will continue to replace old systems with new IT systems and integrate old systems to automate and streamline their business and further improve their business. But unless project leaders abandon general rules and look at each project in isolation, the transformation process of IT systems will always be fraught with disaster, full of failures and disappointments.

Translated with permission from the Winter 2003 issue of the MIT Sloan Management Review. Published by the Massachusetts Institute of Technology and copyrighted in 2003. Distributed by Tribune Media Services International. Translated by Xiao Dongyan.

Andrew McAfee is an Assistant Professor of Technology and Operations Management at Harvard Business School.