Case Study: Lipton Canada Introduction August 1997: Five months into a ten-month timeline, and Tim Pallant knew the January 1, 1998, project deadline was in jeopardy. The team had been unable to find a practical way to configure SAP R/31 to handle trade spending in the flexible manner the company required. As project leader of Lipton Canada's SAP R/3 implementation team, he had to make a decision very soon on what to do next. The basic functionality required to support this process had been identified during the system evaluation, but prototyping had revealed that, in general usage, it would become a maintenance nightmare. Now, despite the many possibilities he and his team had explored, he could see no easy way to make it work. At this point he had identified three alternatives, and he didn't particularly like any of them. One option would be to rewrite a section of the SAP R/3 softwarewithout the appropriate functionality, the company wasn't going to get the benefits it had anticipated. Alternatively, the company could give up on the way trade spending was handled. The final alternative would be to keep searching for a configured solution within SAP R/3 for a little while longer. Given SAP's complexity, Tim wasn't fully convinced that all possibilities had been exhausted. He didn't even want to think about the ultimate alternativeabandon SAP R/3 altogether and quickly tackle year 2000 compliance some other way. Background Lipton Canada was a division within Unilever Canada that manufactured and sold packaged food products, predominantly to the retail trade. The business case to implement SAP R/3 for handling order management had been developed in the fall of 1996. Up to then, Lipton had been using a highly tailored order management system (OMAR) that had been developed in-house fifteen years earlier. By 1996 the company knew it had to either update the existing system to make it year 2000 compliant, or replace it. While the straight cost of updating OMAR was expected to be less than purchasing and implementing SAP R/3, other considerations made the SAP proposal attractive. OMAR had been continuously enhanced over the years and was finely tuned to provide excellent support for the business needs of the day, but it was based on older technology and would need considerable modification to support future needs. As the system aged, integration with other, more recently acquired systems became increasingly difficult. In addition, support and maintenance depended on the knowledge of a small number of Lipton employees, making the company vulnerable to normal turnover of personnel. Unilever as a whole had also adopted a policy of moving to common open systems across the company. Not only was this expected to alleviate IT management problems such as those mentioned, but it would also support the parent company's desire to integrate its global operations. SAP R/3 software had been recommended by Unilever and it was already in use in over thirty Unilever operating companies worldwide, including Lipton United States. Even so, Lipton Canada wanted to ensure that SAP R/3 would meet the company's specific needs in the extended order management process. During the fall of 1996 an assessment was conducted. (Only order management was under consideration, although other SAP R/3 modules, particularly finance, were candidates for future implementation.) The first step was to ensure that SAP R/3 would support current practices in order management. A high level analysis of existing processes was conducted, and compared with SAP R/3 functionality. Several gaps were identified, specifically for certain payment processes related to distribution, and for many EDI transactions, but by and large SAP R/3 appeared to be a good substitute for OMAR, and offered significant additional functionality in some key areas. It was judged that the gaps could be handled by add-on modules, implemented at designated "user exits" in the software. The second step was to identify strategic initiatives in order management that were planned for the near future, and that would require either new systems or enhancements to OMAR. If these initiatives were already supported by SAP R/3, the cost to develop the capabilities could be avoided. The assessment determined that in addition to providing year 2000 compliance, SAP R/3 offered flexibility in pricing, apparent improvements to the planning and execution of trade spending, and the ability to track contribution by customer. Further, it would enable migration from the current AS/400 platform to a UNIX environment. The Implementation By the end of 1996 the assessment was completed. SAP R/3 appeared to match about 80 to 90 percent of Lipton's requirements, and a plan was in place to address the gaps. A budget and timeline were established, based both on some consulting advice and on the experience of other organizations. Ten months, while an aggressive target, was considered feasible. In February 1997, the business case was presented to the executive committee, and the proposal was approved. Eleven people, six from the business and five from IT, were selected to be on the project team, with Tim Pallant as the leader. The users chosen for the team were selected on the basis of their competence and knowledge of their particular functional area. In Tim's words: The argument I used with the various departments to get the right people is that these are the people who are going to design how your department works for the next five years. You need to release your best people to work full-time on the project, and back-fill their positions. By and large I got the people I wantedit was a very strong team. But that's what you need, the senior peoplea team of leaders. Tim himself, coming from the sales and trade marketing area, was well versed in the business processes being affected, and he also had considerable experience working with IT on various aspects of the company's systems. To support the team members from Lipton and add specific SAP R/3 knowledge, a well-established systems implementation consulting practice was hired. The consulting firm assigned six consultants to the Lipton project, although this number would vary over the life of the project. The consultants were expected to lead the implementation, but also to provide sufficient knowledge transfer for Lipton to be self-sufficient by the end of the project. Tim expected three things from the consultants: 1. Leadership/mentoring. Lipton had no experience with SAP R/3, and needed the expertise of the consultants. 2. Depth of knowledge. Whether specific individuals on the team personally knew all the details or not, a big consulting practice had the capacity to leverage both its special knowledge of the product and corporate experience from previous implementations. 3. Workmanship. In addition to providing knowledge and leadership, the individual consultants were expected to be able to execute the mechanics of implementationi.e., configure the software. The project team reported to the executive committee, which had overall project oversight, and met biweekly with the Business Review Group (BRG), senior managers who had line responsibility for the business processes being affected. In accordance with the SAP R/3 implementation methodology, the first six weeks were spent developing a blueprint of existing organizational processes. Unlike the high-level analysis of processes conducted during the assessment phase, this analysis was detailed, and provided not only a documented starting point, but was also intended to help educate the consulting team on Lipton's way of doing business. As the Lipton users worked on developing the blueprint, the consultants explained how SAP R/3 handled the same processes, and indicated where Lipton might have to alter the way it handled certain operations. In fact, to the frustration of the team members, the consultants seemed to respond to most issues with the phrase "SAP doesn't work that way." Before long, Lipton team members found they weren't willing to accept this response without pushing back, demanding a fuller explanation and more research. Once the blueprint was complete, configuration began. For most areas, SAP R/3 processes, even where different from existing practices, were acceptable. Because the users on the team were fairly senior, they had the mandate to make process changes in their areas. If changes had a significant business impact (such as altering the level of service to customers, or requiring additional resources), they were taken to the BRG for discussion. In accordance with recommended practice, this group was expected to provide rapid (forty-eight hour) turnaround on issues brought to them by the project team. In general, issues were presented to the BRG with the team's proposed solution, and for the most part they were resolved in a timely fashion. On those occasions where the BRG delayed making a decision or changed its mind, the team would have to reconfigure the software, which put pressure on the completion date. Trade Spending By August decisions had been made on how to handle most business processes. The major exception turned out to be trade spending, where the team had run into a brick wall. From the beginning they had known that existing processes would have to change, but they had expected that SAP's built-in functionality would be an improvement. For trade spending, the SAP R/3 solution appeared to be an unacceptable step backward in terms of both the information provided and the ease of use. Trade spending was the process through which Lipton supported cooperative promotional work with its customers. Lipton agreed to set aside a certain amount of money when the customer promoted a product through flyers or special displays, Lipton covered some of the cost. Apart from managing the mechanics of the approval process and payment to customers, the software was expected to support analysis of return on trade spending, both by promotional program and by customer. Ironically, the initial assessment of the software had suggested that SAP R/3 would address inefficiencies in the existing process. Lipton wanted to plan and execute trade spending by individual customer. The original system had been designed on the basis of regional planning. Numerous work-around plus great flexibility in allowance type and payment had resulted in a system that provided the desired customer-specific functionality, but not efficiently. SAP R/3 offered customer-specific planning and execution as part of the base system, and provided the opportunity to simplify the overall trade spending processes. With improved process efficiency and more effective tracking of trade spending, the expectation was that SAP R/3 would be an improvement. That said, there was general recognition that the approach in SAP R/3 was quite different from what the company had been used to, and would have a significant effect on the way that customer agreements were set up and the flow of funds tracked. For example, decisions would have to be made on whether account managers would now be responsible for setting up and maintaining their own agreements, and how this would affect overall control. However, because of the overall potential that SAP R/3 offered for the customer management process, these changes were considered worth implementing. Unfortunately, when the team encountered the details of configuration, they realized that instead of an improvement over the existing system, they might end up with something worse. The original expectation was that the customer rebate agreement process in SAP R/3 could easily handle the functionality required for trade spending. Unfortunately, to do what Lipton required increased the clerical workload dramatically. Rather than improving efficiency, following this route would slow the process down and require increased staff to handle the process. Part of the increase in workload came from the required complicated, multiscreen data entry, which not only meant the process took longer, but invited errors and update difficulties. This was particularly problematic because the new system would operate in real-time, so errors could have widespread ripple effects beforeand afterbeing corrected. After trying many different ways to configure the software without success, a proposal was made to create custom screens to make data entry easier. However, the implications for long-term maintenance were not acceptable. Members of the BRG were also unwilling to forgo some of the functionality that they felt added value both for Lipton and for customers, but which also added to the complexity of the process. By August, Tim felt he was facing a brick wall. The team had been working flat out, desperately trying to come up with a solution, and stress was mounting. Deep down, he couldn't believe that SAP R/3 was unable to handle the process in the way the company wanted to operate. Trade marketing was not, after all, unique to Lipton, and with all SAP R/3's built-in functionality, he felt sure there was a way to make it work. Hadn't other companies faced the same problem? He was irritated that the consultants had provided little help on this. While they were competent enough at straight configuration, they hadn't been able to provide much leadership on helping him assess his options, nor had they been able to find any answers within their own organization or through SAP. Their pat response was to change the process to fit with the software, but that meant SAP R/3 would reduce rather than add valuenot what Lipton expected from its investment. Unfortunately, time was growing short. The team was already behind schedule for going live on January 1, and he didn't know how much longer he should ask them to keep trying to solve the problem. Since the fiscal year ended in December, missing the January deadline would require a much more complicated cut-over. Tim had to sort out his options, and take a proposal to the Business Review Group and the executive committee within the next few days.

Source: Project Management Case Studies (Harold Kerzner, 2006)

Question 1 (25 Marks)

There are three universal characteristics that feature prominently in all projects. The first universal characteristic is that every project is unique. This implies that no two projects are similar. We notice that the Lipton Canada project was indeed a unique project with various challenges. Critically discuss the characteristics of projects and clearly relate the uniqueness of the Lipton Canada project.