Search
Close this search box.

Managing Multiple SI’s? How to Avoid the Blame Game

When it comes to implementing any transformational initiative, companies are faced with two primary challenges: capacity and experience. How will they free up the internal resources needed to ensure a successful program, and how do they quickly transition that team from an operations focus to one that is project-ready? This causes some companies to opt for managing multiple SI’s to free up internal capacity.

Your SI’s can regularly manage large enterprise projects and are very experienced in managing all aspects of a transformation. Unfortunately, they are also experts at shifting risks to their clients, especially when it comes to responsibility for project execution mishaps and delays.

The good news is that by engaging more strategically when managing multiple SI’s you can mitigate this risk transfer by ensuring they have more accountability for program outcomes. These three models of engagement are most common on large, transformational programs.

Program Participant

In this scenario, the system integrator (SI) is an extension of your team, usually bringing specific functional and technical expertise to the table. They simply manage their part of the program and keep you informed, having little-to-no responsibility for managing and coordinating the overall program.

This model is most commonly used when managing multiple SI’s who supplement the skills and services provided by the lead SI, but can quickly become an endless source of headaches when the areas of shared responsibility are not clearly defined upfront. That’s where creating a solid RACI (Responsible, Accountable, Consulted, Inform) matrix as part of the Statement of Work (SOW) is essential.

The purpose of a RACI matrix is to identify whether an SI or the client is responsible for program deliverables, work products, and activities. However, in cases where there is a lead SI and one or more third parties, the RACI needs to be jointly developed with the lead SI.

It should include a column for the lead SI which indicates any areas of overlap and clearly specifies the expectations of both sides. Whether it’s data migration, testing, or status reporting, having this matrix in the SOWs of the third-party as well as your lead SI will eliminate lots of finger pointing later on.

Program Lead

This model is fairly self-explanatory and is the norm for most programs where the SI takes the lead role in running the PMO (Program Management Office). In this scenario, your SI either leads or has joint responsibility with the client for planning and managing the following components of the program:

  • Program governance
  • Developing, validating, and maintaining overall program roadmap & project plan
  • Developing a detailed program RACI that spans the SI, subcontractors, third parties, and the client
  • Developing and maintaining comprehensive program resource planning estimates (staff loading charts)
  • Tracking and reporting on program status
  • Delivering comprehensive program quality reviews.

In most cases, though, the lead SI has no responsibility for planning or managing any third-party involvement. Why is this an issue?  Consider the case where you have brought in a third-party to implement training or manage data conversion. Unless those providers are sub-contracted through your lead SI, the client is going to be completely responsible for any deficiencies in either deliverables or schedule.

Moreover, even if the lead SI suspects things are getting off course, they may not be motivated to raise the red flag for a number of reasons. The end result is that risks turn into issues overnight, and even if you’ve developed joint RACIs that clearly delineate responsibilities of all parties involved, you may not have enough time to course-correct and avoid a change order.  This is where the next model can help.

Master Conductor

In the case where the SI is made the “Master Conductor,” the SI also has increased levels of accountability for areas that are the responsibility of either the client or any third parties. In other words, even though your lead SI is not responsible for failures or missteps where others have an “R” in the RACI, they are nonetheless responsible to stay on top of potential risks and issues and escalate them appropriately.

So, in addition to the responsibilities of the Program Lead, the role of Master Conductor is responsible for working directly with third parties to plan, manage, and track the entire scope of the project:

  • Reviewing and aligning milestones to deliver a single, integrated plan
  • Designing and coordinating the third-party participation process
  • Monitoring and tracking delivery
  • Facilitating third-party contract compliance, identifying issues, and recommending corrective actions.

This added level of accountability ultimately reduces the likelihood as well as the impact of change orders when third parties do not perform. Not because the Master Conductor is now responsible for delivering, but because they are responsible to ensure it doesn’t get to that point.

Thus, when managing multiple SI’s, a rock-solid SOW is a prerequisite to beginning any IT project. This is the only tool you will have to hold your providers accountable once the project is in flight – regardless of the engagement model – and ensuring that there are clear lines of responsibility defined and documented in the SOW are your best defense against blame shifting and change orders down the road.

Managing multiple SI’s can be a daunting task while trying to manage other aspects of your digital transformation. Explore our Project Execution Advisory Services to learn how UpperEdge’s trusted experts can help you hold your SIs accountable.

Related Blogs