Ensuring program success in a global multi-vendor/multi-applications integrated solution delivery
This paper highlights key phases to be considered and incorporated as part of any IT program delivery methodology to ensure successful business transformation initiatives that impact global business processes and IT solutions.
While global conglomerates might use their own “best of breed” program/project management methodology, the key ingredients that have a high potential to ensure successful delivery of any global program involving multiple vendors have been detailed as part of this paper. Also, this is based on the “lessons learned,” by delivering multiple programs in a global multi-vendor/multi-applications delivery.
Collaborative Global Program Planning
The first key phase in a multi-vendor, multi-application global program is to define the global scope, which is very critical to aligning the various vendors throughout the phases of the program lifecycle. Also, an integrated program plan encompassing all the critical milestones for all vendors needs to be evolved during the program initiation phase. This can be done by working with the global project sponsor(s) and steering committee to determine the high-level scope and goals, by having an executive-level strategy workshop involving key stakeholders of all the vendors, and by highlighting the “business case” for the entire program. The outcome of this workshop should mandatorily contain a master program plan and a master requirements document.
Cross-cultural awareness training is a mandatory requirement for effective collaboration while developing the project charter and should be planned during the kickoff event. Due to multiple vendor teams with multi-cultural backgrounds participating in the program, it's a prerequisite to ensure proper communication among the teams. Also, a comprehensive communication plan and issues/risks mitigation plan needs to be finalized and agreed upon by all vendors.
Another key tool to establish as part of program initiation is a global electronic program repository that can be accessible by all vendor managers (with a “program dashboard”) to get a vendor's key project status at any given point in time. This should be available throughout the program lifecycle on a 24/7 basis. This can be done by using standard program/portfolio management tools that are available, and is at the discretion of the program manager to decide along with the stakeholders. This is extremely important to ensure that all program stakeholders across the globe can get an updated status, and to help the multiple vendors track their dependency on other vendors for timely resolution of conflicting program issues.
Based on the “dependency” on each milestone/deliverable from all vendors involved in a global delivery, the program manager may define a comprehensive dependency matrix, encompassing all key deliverables and milestones across multiple vendors involved in the overall initiative.
This will enable monitoring an integrated global program plan, without losing the focus on individual applications and projects that form a part of the overall program.
Most of the techniques and tools available for tracking dependencies are more time-driven and include:
- Kind of relationship in time (S-F, S-S, F-F)
- Lead and lag periods, and so forth
Apart from the time factor, which is critical, there are many qualitative aspects including:
- Must the whole facilitative product be finished, or may just parts of it feed the dependent product? (The facilitative product will be the one that feeds into the dependent product downstream.)
- What is the strength of relationship between the dependent deliverables? Is it vital or partially needed to enable starting the dependent product?
- Are there more products involved in the relationship or is it only one?
These dependencies can be quantified in a Relation Score:
R = S * V
Where S is the strength of the relationship on a scale of 1 to 5 & V is the “vitalness” of the relationship on a scale of 1 to 5.
While the strength of the relationship can be objective, the vitalness of the relationship is more a subjective rating, and depends on the program/project team's perception of the vitalness of the deliverable (Moret, 2003).
Exhibit 1 – Dependency matrix
Dependency matrix analysis (though with qualitative inputs) will be a useful addition in any program that has a greater number of products to be delivered or with a lot of external dependencies, as it will help to better analyze issues and consequences to the overall program planning of changes in any facilitative product.
Combined Evolutionary Archetype Solutioning
Due to globalization, the market is dynamic, and so are the business processes of the conglomerate that embarks on implementing an IT solution for enabling its business needs.
For this reason, the Rapid Evolutionary Archetype Solutioning concept is extremely useful to ensure quick validation that new business needs are viable in a multi-vendor, multi-applications global delivery. The simplified view of this approach is to have a linked chain of “proof of concepts” from respective vendors involved in the global program.
There are many terms used for the same concept, including Conference Room Pilots (CRPs), Proof of Concepts (POCs), and so forth. Due to the ever-changing business environment, it's always recommended to use Combined Evolutionary Archetype Solutioning, which will help in confirming the following:
- Validation that the new business processes are in line with business stakeholder's expectations
- Technical Solutioning that is done is meeting the business solution finalized during the requirements phase. This will also help in serving as a module/component for integration to the dependent product in the downstream application/system being built by another vendor.
- Early identification of potential issues in integration across multiple solutions.
Also, to ensure that critical business needs and functional requirements for the initiative are covered adequately, the following value/stakeholder matrix can be used as a tool.
Value / Stakeholder Matrix
A simple matrix/tool to analyze and classify the requirements is given below (Exhibit 2). Though it does not magically solve all requirements and expectations-related issues, this tool can be used to validate the team's understanding of the requirements to plan forward.
Exhibit 2 – Value stakeholder matrix
Business requirements that are of high business value in tangible, measurable dollar amounts and that have higher stakeholder interest as well, fall in Cell 1 and should be mandatorily met to ensure project success. Dropping any single requirement from this list will be a potential show-stopper for the project.
Prioritizing the cells has been done based on stakeholder interest primarily, and therefore the requirements in Cell 2 and Cell 3 have been obviously prioritized below the critical and mandatory needs in Cell 1.
Though the business value derived by enabling the high priority requirements in Cell 2 might be low, the client's culture and the history in which the project team operates will influence the delivery of these specific needs.
There might be many factors that could necessitate the stakeholders’ interest in the low business value requirements, such as:
- Requirements that are relevant in the local cultural context and are important to a specific user group in a specific country
- Requirements that have been committed to in the past and that have not been delivered as part of earlier initiatives
- Requirements that are related to user friendliness, such as easier system access, and that enhance the user experience with the systems
Another key aspect for program success is to avoid effort/cost spent on business requirements that are of lower business value and which have lower stakeholder interest, which fall in Cell 4. This relies on the skills of the project team (and the program/project manager!) to convince the business of the necessity to exclude the requirements from scope. Another approach is to incorporate them as part of changes after the global solution deployment/stabilization in production, during post-production optimization of the solution.
Hence, this matrix will be of immense use for validation, if there are a huge number of individual business requirements flowing in from multiple stakeholders who will be keen to push their business needs as critical to the project (“Stakeholder management,” 2007).
Critical Business Chain Linkage (Global Processes)
Although Individual applications/vendors have their own project plan, it is critical to understand the integrated business case for the overall program and to identify critical business processes driving the key business results.
A standard Pareto analysis can be used to identify the critical business processes that cut across the various applications/systems: identify the 20% of key business processes that result in ensuring that the program achieves 80% of the business case.
These key business processes should be part of the Combined Evolutionary Archetype Solutioning, that is, proof of concept, as explained in Section 3, prior to scaling up the entire applications for integrated go-live and movement to production environments.
The integrated program plan should have milestones integration of these key business processes, and the timelines should be agreed upon in a Common Business Process workshop with all vendors (Exhibit 3).
Exhibit 3 – Global process linkage
Synchronization is essential for excellence in execution. Synchronization means that all parts of the program have common assumptions about the external environment over the entire operating year/period (Bossidy, Charan & Burck, 2002, p. 234).
Also, due to the scale of global programs, the lead solution provider (among the total vendors), who delivers a substantial piece of the scope of the program, may tend to influence the overall program deadlines and may attempt to drive the program based on their component-based planning and on their schedules. Therefore, the program manager needs to be cognizant of these potential issues and will have to ensure coverage of key and critical business processes across each of the component delivery from the respective solution provider to ensure completion of the program.
End-To-End Business Process Testing
The biggest impediment to success in a global multi-vendor/multi-applications integrated delivery is the potential likelihood of individual silos of implementation of respective IT solutions. When the final integration testing of all the applications happens, many issues of both business process integrations and solutions-related interfaces are unearthed. This results in the entire program team across all vendors being forced to revisit their key business processes and the integration solutions proposed during Solution Design or Business Blueprint (or the equivalent phase) earlier in the project.
Therefore, to avoid the major issues later on, the relevant program team needs to include an integrated testing plan to prototype dependent processes, to scale up the solution further to include key business processes later, and to subsequently develop the complete solution to encompass all the business processes, as per the defined solution, across all vendors.
This is more relevant while executing the end-to-end integration testing phase, covering all the requirements once the respective solution from each vendor is completed. The integrated testing plan it is an iterative process and so should be included as a sub-phase starting with the Combined Evolutionary Archetype Solutioning phase and continuing until the final phase of development, spanning all vendors.
Co-Location and Team Exchange Program
Another innovative initiative that helps build trust among multiple vendors is to have team members of dependent team vendors operate from the same country/location for a specific time period. An example could be that during Key Process Integration Testing (of Global Processes), an agreement can been reached to keep the functional and technical consultants of the respective vendors working for a specific period of time in the same location near each other. This builds trust and will help the various team members understand the “areas of pain” for other teams. This also serves as an incentive for team members to travel and meet with team members of other cultures, fostering relationships in a multi-cultural environment. However, this is subject to the cost structure of the program and needs to be planned as part of the overall program cost.
Business Case Validation and Iteration
The business case puts the investment decision in a strategic context and that it provides the information necessary to make a decision about whether the program should proceed. Although it is the indispensable first activity in the lifecycle of an IT investment, constant validation of the initiative at the end of each phase/gate of the program is vital to ensure that stakeholder expectations are always kept at the center of the program lifecycle.
Define Global Glossary for Processes and Phases
Another significant area for potential conflicts across multiple vendors when working in a global delivery setting is assumptions around terminologies used in the program across various processes and phases.
For example, “integration testing” has different meanings for different vendors, so there should be a global glossary for use across the various teams. This should be part of the global communications done during the program kickoff.
This is relevant when multiple vendors use their own delivery methodologies for their respective components of the overall program.
Change management in the multi-vendor context is critically emphasized on the overall program scope and not to the contents of individual vendor's deliverables. While change management in individual sub-project scopes is also important, due to the dependencies of other deliverables on the specific sub-project's facilitative product, it is up to the individual vendor to make intelligent trade-offs within the overall program timelines to allow them to meet the master deadlines. If there are constraints in making the trade-offs within the deadlines, the respective vendor program/project manager should discuss with the overall program/project manager to decide on initiating the change management process to resolve the impact on the program deadlines.
Another key control that helps the program manager manage the global program is defining tolerance for delivery of individual project outcomes. Tolerance is the permissible deviation from a plan without bringing the deviation to the attention of the next higher authority (Office of Government Commerce, 2002, p. 222).
Based on the tolerances for the whole program given by the steering committee on scope, time, and costs, the program manager needs to finalize the tolerances permissible to individual vendors on scope, cost, and time, which will help to align the milestones without escalating issues and risks that are not an impediment to the overall program delivery.
Effective communications management is critical in any global delivery initiative. In a distributed environment, communications issues range from how developers interface with end users to the frequency of reviews by executive steering committees and decision makers (and everything in between), and should be discussed and agreed upon prior to project inception. The issue of communications cannot be minimized.
Communication planning and executing across the entire program lifecycle is highly critical, as it is the essential and vital element in the overall success of the program. With multiple vendor teams spread across geographies and time zones, it is extremely useful to have a well-structured and well-defined communications plan encompassing all key stakeholders. Using standard portfolio management software to enable this is mandatory.
Also, for each phase that cuts across multiple vendors, a single point of contact (SPOC) should be identified from the relevant vendors for issue resolution. As there are many deliverables spanning the entire program, having a SPOC will greatly help in ensuring process completion on time.
Special challenges arise due to differences in cultures, traditions, values, philosophies, and languages of the project partners and vendors. Therefore, having a single node of communications backbone, in the form of a reputed program management solution, is vital, and having a near-real-time global program electronic repository is required to ensure successful program delivery.
Bossidy, L., Charan, R. & Burck, C. (2002). Execution – The discipline of getting things done. New York, NY: Crown Business (p. 234).
Moret, R. (2003). Using the dependency matrix as part of the product breakdown structure technique. Retrieved on June 20, 2007 from www.pugnl.nl/index.php?menu=15&job=detail&id=11
Office of Government Commerce. (2004). Managing successful projects with PRINCE 2. Norwich, Norfolk, UK: OGC (p. 222).
Stakeholder analysis: Winning support for your projects (n.d.) Retrieved on June 10, 2007 from http://www.mindtools.com/pages/article/newPPM_07.htm
© 2007, T. Natarajan
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, GA