Sourcing Enterprise Projects – Understanding and Meeting the Challenges (part 1 of 2)

In last two decades, much of the attention of customers and advisors has focused on outsourcing under the managed services model. The outsourcing era began with infrastructure outsourcing, which evolved from time sharing and facilities management. This was followed by outsourcing of applications maintenance and support and, on a parallel track, Business Process Outsourcing. This journey is littered with failed and successful delivery models, pricing constructs and business arrangements (including joint ventures). Some might consider offshore outsourcing as the most disruptive force to shape managed services.

These trials and tribulations have armed customers and advisors with a fairly mature level of knowledge and experience in outsourcing managed services. In contrast, there is a notable lack of maturity in the approach to sourcing and contracting for critical enterprise projects including ERP implementations, ERP consolidations and major ADM projects. Despite decades of experience with these projects, companies struggle to find and leverage the resources and tools necessary to execute them. Instead, they rely on anecdotal guidance from failed implementations. War stories of cost over-runs, time delays and abandoned projects abound.

How can enterprises avoid these mistakes? Let’s explore some of the challenges (and solutions). In this first installment, we’ll focus on two key front end considerations: (1) the role of executive leadership; and (2) proper planning and preparation (leveraging a sourcing “roadmap”)

Executive Leadership
A frequent challenge in Enterprise projects is the customer’s failure to anticipate the importance of early and informed engagement of executive leadership. For example, unlike many managed service outsourcings, ERP implementations or consolidations are business change initiatives that have broad impacts beyond IT. Early and persistent business leadership is paramount to the overall success of the program.
So what does this mean? Consider the following core functions that a company’s business leadership should serve (and the manner in which leadership should go about executing these functions):

• All key decisions should be strongly enforced in a top-down manner against the naysayers (and there will be naysayers) who oppose the type of change that these projects usually require.
• Top down leadership, however, is only as successful as the consensus it is able to foster (especially among the naysayers). Therefore, consensus building, through transparent communication of the benefits and challenges of the initiative, among others, is essential.
• To keep the project on track (and on time) a process must be established (and followed) to ensure that these decisions are made in a timely manner.
• Since ERP projects typically require process standardization across multiple business domains and, in the case of global companies, different operating divisions in multiple geographies, process standardization is a crucial (and often times painful) component. Success on this front warrants strong stewardship from highest levels of management.
• Engagement at executive levels should continue during the sourcing process itself to ensure the right mix of supplier(s) for this business critical initiative.

A Sourcing “Roadmap”
Large projects should follow a “roadmap” which describes the critical path activities for the entire project (e.g., multiple releases over 3-5 year period across all impacted geographies). To complicate matters further, each release often has multiple phases, many of which may run concurrently. This complicates the customer’s job of determining whether to select a single supplier or multiple suppliers for the project. Common questions include:

• Should I use the same supplier for both functional and technical work?
• Should I use one supplier for functional work and another supplier for technical?
• Should I consider engaging separate suppliers by region (for example for localizations in remote geographies)?

To make this decision, customers must balance the desire for lower cost with their own ability to establish and manage a program level governance regime that avoids or contains friction among multiple suppliers.

For example, if one supplier is responsible for technical work while a second supplier is responsible for functional implementation, it is critical to identify in the roadmap the handoff points between suppliers. Under this example, engagement of the second supplier during detailed design and all cycles of testing (unit, integration, regression, UAT) must be clearly defined and managed. Problems often arise if each supplier’s responsibilities and accountabilities (i.e. performance standards) are not clearly identified at the outset.

Anticipating (and knowing how to handle) these challenges at the outset will go a long way towards positioning the project for success. However, the story may not have a happy ending unless the downstream transaction is properly structured, including through the use of the appropriate contractual framework and pricing constructs. Stay tuned for part 2 of this entry where we explore these issues.