Multi‐Vendor Project Management Best Practices 1.
Introduction .............................................................................................................. 2 1.1 Purpose.............................................................................................................. 2 1.2 Definition of Multi‐Vendor Product Development .................................... 2 1.3 Characteristics of Multi‐Vendor Projects...................................................... 2 1.4 Requirements for Successful Multi‐Vendor Projects .................................. 2 2. Multi‐Vendor Project Management “Soft Skills” ................................................ 3 3. Regular Communications ....................................................................................... 5 4. The Business Case .................................................................................................... 5 5. The “Overlay” Project ............................................................................................. 6 5.1.1 Requirements Phase ................................................................................ 7 5.1.2 Adding Product Value ............................................................................ 9 5.2 Planning Phase ............................................................................................... 10 5.3 Resource Planning ......................................................................................... 11 5.4 Test & QA Planning....................................................................................... 12 6. Change Management............................................................................................. 12 6.1 Change Review Team.................................................................................... 12 6.2 Suggested Change Management Process ................................................... 13 7. Conclusions............................................................................................................. 13
1. 1.1
Introduction Purpose
The aim of this proposal is not to teach project management skills but to highlight the differences between standard projects that an experienced project manager (PM) may have encountered within a single organization and projects that span multiple organizations, and how to succeed with the latter. 1.2
Definition of Multi‐Vendor Product Development
Multi‐vendor products are defined as suites of products orchestrated from two or more already existing applications. These applications are most often from different companies with a common interest in fulfilling the requirements in a particular market segment. 1.3
Characteristics of Multi‐Vendor Projects
Most project managers who have led projects in a cross functional team environment would find the Multi‐Vendor environment a new experience. Although it has some of the attributes of cross functional teams within a company, the experience of leading these projects is unique. The traditional project team may be geographically distributed between several countries or even continents. Multi‐vendor projects are not only geographically distributed but the project teams belong to different companies increasing the challenge of leading projects to successful conclusion. In this environment the success of the project can only be achieved through clearly defined and documented governances, building consensus and managing expectations amongst the different project teams. 1.4
Requirements for Successful Multi‐Vendor Projects
There are several means by which this can be accomplished, all of which are required for project success. • Good soft skills on the part of the project manager, and particularly the ability to influence, manage expectations and negotiate with various companies’ executives.
•
•
•
•
Frequent and regular communication, via regular conference calls, a readily accessible shared collaboration mechanism, mailing lists and so forth. A strong business case that clearly articulates the customer value and revenue opportunity of a multi‐vendor integrated offering, and why such an offering is the best way to meet the anticipated demand. Being sensitive to each company’s sovereign rights to manage their internal resources as they see fit, while ensuring commitment to execution at a sufficient level of detail to move the project forward. We propose the notion of an overlay project that is tied to the business case and managed against clear and measurable milestones, with each company accountable to delivering their portions of those milestones. Strict change management to help ensure that none of the participating companies are caught by surprise when delays occur or new requirements are adopted.
These are all important, as they are mutually reinforcing. For example, “soft skills” may get you in the door with each company’s executives, but the business case and regular communication will keep them engaged. The following sections discuss these in more detail. 2.
Multi‐Vendor Project Management “Soft Skills”
A large part of project management in any setting is accomplished thru so called “soft skills”, which is the project manager’s ability to influence participants and lead conversation toward result. This skill allows the PM to defuse personal issues and make requests from his or her team and get results without having to defer or escalate to authorities in each company. This skill set relies heavily on the PM’s ability to establish rapport with the team and credibility with upper management; both of which depends on prior and ongoing positive personal interactions with the team. In multi‐vendor application development, this relationship is not as easily established since most stakeholders of a project will be in different companies and will have limited interaction with the PM, e.g. only through weekly status calls. Because of this, it becomes it is important to define and document expectations, as well as solicit buy‐in from executive sponsors in the form of a steering committee to ensure adherence to the agreed on governance and resolve disputes.
Establishing Stakeholder Commitment Commitment from stakeholders, project sponsors and executive champions is the key to success of the project. In any project, PM’s first responsibility is to secure stakeholder and project champions’ commitment. But this commitment may not last the life of the project. Even in a project managed inside a single company, other issues such as higher priority projects, company finances and management turnover may delay or kill the project. It falls upon the project manager to keep the project in the forefront and in view of executive sponsors and defend the project’s ranking inside the company’s project portfolio. In a distributed development environment, this task will become even more difficult since each company has its own agenda and set of problems. Also, the PM may not have immediate access to other companies’ executive teams. Given the difficulties of managing teams belonging to different companies, the key to success of multi‐vendor projects is securing and maintaining the executive sponsors’ commitment to the project and continually drive the project from this top‐down point of view. The PM should set a regular schedule to communicate with the executive steering committee and champions, and make sure that the conditions of their initial agreement still hold, and discuss and resolve any new information that could lead to reduced commitment in the future. These communications are also important for setting and managing expectations. The PM must provide regular updates, and clearly understand and communicate each company’s deliverables and time lines and be able to gain commitment from executive sponsors. As an example of one such project that some OSA members are currently undertaking, a “Front Office Suite” that includes CRM, Business Intelligence and Instant Messaging products, we have been able to achieve this interaction through the OSA project activities. In this fashion, the OSA has served as a venue in which stakeholders can regularly interact and reconfirm expectations and commitments related to this project. In the absence of such structure, the PM may need to arrange for regular meetings with the sponsors and face to face meetings when possible
3.
Regular Communications
Clearly, in addition to keeping executive stakeholders informed, the project itself must proceed, and must concern itself with details at a much lower level than the executive stakeholders need to be exposed to. We don’t propose anything different than what is normally done for distributed project management, which includes: • Conference calls to report status to and solicit feedback from the project participants at regular intervals. (Weekly, bi‐weekly, or whatever the team mutually agrees to.) • A shared collaboration infrastructure, such as a common website, wiki, blog, document repository, or whatever helps the project participants share information and keep each other up to date in between conference calls. • Email lists or other means of “pushing” new information out in real‐time. 4.
The Business Case
Companies will typically enter into a multi‐vendor agreement thru their executives who see a common strategic objective, competitive threat or customer requirements. Therefore each executive will have great deal invested in the success of the project. A strong business case, aligned with company’s roadmap and vision, is critical for establishing agreement amongst the various companies’ executive sponsors. The bigger and more complicated the project is, the more attention should be made to the strength of the business case. The business case should include the following: • Market data and customer input pointing to the need for the target product, and why a multi‐vendor approach is preferred • Market requirements and use cases • Justification for project timeline and completion date (e.g. a window of opportunity in which the product must be released, else a competitor will claim “first mover advantage”) • Justification for why “business as usual” (i.e. the respective companies merely continuing to enhance their respective products on their own) is not sufficient. This can take two forms: o A “customer value” argument, such as pre‐integrated product being easier to deploy and use, and consequently more customers would be willing to pay for it.
o A “cost savings” argument, such as an interoperability feature having to be built only once when each company would otherwise “reinvent the wheel” themselves. While the business case is usually composed by marketing or product management, the PM must have a thorough understanding of the business case. Most PMs will sooner or later face the prospect of their project losing executive support. This could be either because a “bigger and hotter” project/issue/bug has taken precedence or somehow the executive commitment has wavered in favor tactical priorities facing each individual business. In these cases, the PM can re‐ gain support for the project by pointing to the business case and discussing the long and short term benefits of the project to each individual company. It is best for a PM not to assume knowledge of this information but rather obtain it directly from individual companies’ marketing and product management teams. Quantified data is best, in the form of marketing survey results, direct customer input, analyst data and so forth. 5.
The “Overlay” Project
The most efficient way to think of multi‐vendor projects is in terms of a master “overlay” project, with individual companies’ deliverables being managed through internal means. In other words, there should exist a “public” set of high‐level commitments and milestones, with individual companies “privately” managing their internal resources to deliver against those commitments. The “public” milestones can be used to manage expectations at the executive level, without requiring micro‐management of details at the individual contributor level. We assert that the best way of managing the “overlay” project is with basic waterfall methodology. The advantage of the waterfall is that it easily demonstrates milestone targets and sets expectations well in advance. It is important, however, not to involve too much detail at this level. Waterfall methodologies have become increasingly unpopular in recent years, coincident with increasing size and complexity of software projects in the face of ever‐more‐ rapidly changing requirements and market conditions. No one person can be so prescient so as to have all details planned up front that account for every possible change in requirements along the way. Consequently, more agile methodologies that allow for making course‐corrections during a project have become more popular. However, waterfall isn’t inherently wrong; instead the challenge of
waterfall grows with the level of detail one attempts to manage. Maintaining a waterfall project at a high enough level of abstraction, with a small number of target milestones, e.g. “beta code freeze happens on this date”, can work as long as there is flexibility in the details of features and other trade‐offs within each milestone. The “private” subprojects can be managed in any methodology suited to the given companies as long as the target dates are met. Companies that have adopted agile methodologies can certainly use them for managing their own deliverables, as long as they fit within the milestone dates set for the overlay project. In fact, we recommend agile methodologies because they allow for more real‐time course corrections and “early warning” of delays if a given company finds they must make trade‐offs in order to hit their milestone date. We summarize our proposed methodology as follows: Methodology Level of Managing trade‐offs Abstraction Public / Waterfall High‐level Time‐based (milestone overlay milestones (e.g. dates should remain design freeze, fixed, unless agreed by alpha date, beta all parties) date, etc) Private / Companies’ Activities per Feature/quality/resource Internal internal individual tradeoffs to hit deliverables preferences (agile contributor milestone dates is preferred) 5.1.1
Requirements Phase
The requirements for a product can come from many sources including the product and marketing group, customer and field request, familiarity of the team with certain technology, etc. Product managers from the involved ISVs will help define the final product requirements. We recommend that one product manager “take point” in aggregating all requirements, “owning” a master requirements document and helping resolve conflicts or differences of opinion, however product managers of each company are responsible for driving requirements into their respective product organizations.
In multi‐vendor projects, we recommend that the prioritization process should favor integration requirements over new features that are core to individual companies’ products. Wherever possible, the multi‐vendor product should consist of functionality already available in the individual products into a larger suite that adds unique value because it is integrated out of the box. In a way, requirements gathering becomes more like functionality augmentation of an existing product than creating a brand new product. There are several advantages to this approach: • Keeps the project focused on the unique value of integration, with a sense of “we can do this only if we do it together”. Core feature development, on the other hand, can result in questioning why it must be done in the context of a multi‐vendor initiative, e.g. “we can do this ourselves whenever we want”. • Allows tying project milestones directly back to the business case, which (if written correctly) should point to the unique value of an integrated offering. The one exception to this rule is when a core feature needs to be developed before integrations are even possible. For example, “centralized user management” and “common search” are frequent requirements in multi‐vendor products and frequently appear on prospective customers’ evaluation criteria, however these are not possible without each vendor having already implemented user management and search functionality in a programmatically accessible manner. Even here, it is important to tie such feature development back to the overall product suite’s requirements. 5.1.1.1
Prioritizing / Agreeing upon Interoperability Requirements
Consequently, we expect most requirements in a multi‐vendor project will be integration requirements. Our experience is that it is relatively easy to agree upon common market requirements (e.g. “single signon is important”) and much harder to agree on the implementations (e.g. which identity management framework to use) especially if significant changes are required in individual applications in order to implement them, or the priorities, if such changes require a commitment of resources resulting in other unrelated but nonetheless important business objectives not being met. This situation can easily degenerate into battles of will between architects and product managers in different companies, with the unfortunate multi‐vendor project manager caught in the middle.
In these situations, just having a business case may not be enough, as the challenge is implementation, not market requirements. It helps to be able to leverage objective third‐party recommendations, such as a standards body or de facto best practices, as a starting point for discussion. This helps focus attention on neutral tangible next steps that can be refined and agreed upon without second‐guessing motives. The OSA intends to serve as such as third‐party. Our interoperability recommendations, including this document, should serve as good “starting points” for such discussions. Also, these recommendations, if implemented prior to engaging in any multi‐vendor projects as a “good faith” effort to be more interoperable in the future, can dramatically reduce the possibility of such disputes arising in the first place. The “hard work” of making products interoperable has already been done, and now they just need to be wired together. 5.1.1.2
ISV Inventory
It’s important to collect an inventory of the technologies, platforms, etc. used by each application vendor to help identify commonalities and creating the inter‐ operability road map. Mismatches in platform support, for example, should be understood early on and planned for. 5.1.2
Adding Product Value
The project and product management team can use the technology inventory not only to fill in the gaps but to provide added value to the end user. For example in our Front Office Suite, the business intelligence product did not support a custom query language and it was tentatively planned to include it in some later release. But since this functionality was an obvious value‐add to the product, and also requested from customers of other vendors involved in the project, the vendor agreed to move up their development to build this feature within the suite’s milestone dates. 5.1.2.1
Gap Analysis
Gap analysis now becomes the main challenge of the requirement phase. The application combination is analyzed and compared to the end‐product goal and the gaps ◊ Which one of the suite’s requirements already exists in one or more applications ◊ Which one is a “common requirement” that has to work across applications
◊ ◊ 5.1.2.2
What is the gap, i.e. what needs to be built within each product Integration of different applications into one suite MRD
The MRD in this case is a general definition of the functionality required for the multi‐vendor suite, and gap identification document at the same time. As mentioned above, one product manager should be the “owner” of this overall document, but each companies’ product managers should own pushing their respective requirements back to their respective organizations. 5.2 5.2.1.1
Planning Phase Internal Planning
The following plans need to be developed within each company, in support of their individual deliverables: • Resource planning – Make sure the right staff is available at the right times • Change Management Process – How to push change requests back to the “overlay” project, and vice versa. • Engineering Plan – Typically includes functional specs, build and packaging requirements for the individual companies’ deliverables • Test and QA Plan – Includes test cases and plans for tools and automation. Should also include a bug database. • Risk Management Plan – An up‐front understanding of the highest risks and how to mitigate and account for them • Support and Maintenance Readiness Plan – Making sure the support organization is ready to handle cases, and in particular understands the integration points well enough to do effective triage. • IT Plan – Making sure that desktops and servers and other hardware are available for the project • Project schedule – Focused on company’s individual deliverable to the “overlay” project 5.2.1.2
Joint Planning
It is important that each participating vendor clearly understand their and others’ deliverables. We have found that creating a detailed matrix of requirements helps us clearly identify tasks and easily assign them to the appropriate ISV members.
The overall project schedule needs to be developed as a joint effort, with timelines driven from the business case, but each company is responsible for delivering their results according to the joint schedule and time lines. In our Front Office Suite project, we have created a matrix of project deliverables based on the functionality of the final product (single sign‐on, licensing, common UI, integration, etc.). This document is created to help each team plan and deliver their part of the project and is posted and regularly updated on a project web site readily accessible by all participating vendors. In large multi‐vendor projects, it may make sense to create sub‐multi‐vendor projects the deal with each functionality area. It is important to establish clear boundaries, both in terms of market requirements and implementation, in order for this to work effectively. This may result in its own additional product requirements, e.g. adopting web services standards to make the distinct modules easier to develop and integrate in a loosely‐coupled way. Other examples of the plans the need to be jointly developed are plans for Test/QA of final product, Sales, Documentation, Joint Go‐To‐Market Plan, and Joint Support Plan. 5.3
Resource Planning
Each company should assign the team members working on the project. The team should include a product and project manager, developers, an architect and marketing team members. Wherever possible, one person from each function (product management, project management, engineering, QA, marketing, support) should be on point for their respective company, to minimize the complexity of coordinating across companies. Also, when possible each participant should dedicate a minimum percentage of their time to the project. This may not be possible for the smaller companies, in which case the PM needs to understand those companies’ priorities. It is important that the PM should be able to contact the executive sponsors and request either dedicated resources or more time from the dedicated resource. Again the commitment to the project may lessen when there are obvious resource constraints that may affect the release schedule. These times must be clearly noted in the constraints and risks sections of project plan and reflected in the final project schedule to insure the accuracy of the project.
Since unusual events such as major bugs or security issues can not be easily forecasted, it is always a good idea to include some buffer or risk to the schedule (when possible). 5.4
Test & QA Planning
The individual application providers will be responsible for a series of tests. These tests must be planned and agreed upon by all application providers. There also has to be a set of pre‐planned test for the final product which must be developed. The QA bug‐track, bug‐fix and bug‐rating definitions must be agreed upon in advance by all parties; e.g. which are show stopper bugs and which can be fixed in next releases, etc. Another important item is the bug fix SLA, how long can an individual application provider take to fix the bugs before affecting the schedule for the release. 6.
Change Management
Change management in this context only applies to the over all project (for example, project milestone dates) and not to the contents of individual companies’ deliverables. It should be up to each individual company to make intelligent trade‐offs within the spirit of the overall project and that allows them to meet dates. If a trade‐off seems painful, that company should inform the overall PM, who can then decide whether it makes sense to initiate this change management process (to either delay the date or agree that a feature isn’t needed, for example). 6.1
Change Review Team
Change review team members • Marketing o Product managers responsible for the product and owning related features o Project Manager responsible for the multi‐vendor product • Engineering o VPs or lead architect o Lead engineer(s) responsible for the given feature(s)
•
6.2
o Engineering Project Managers o QA, if the issue is quality related Support o Designated support team member, if the issue is supportability‐ related
Suggested Change Management Process
Any changes or diversions from the project Plan/Schedule is subjected to the following process: 1. Requestor will inform the multi‐vendor project manager of the requested change 2. Project manager is responsible for setting up the change review team meeting 3. Project manager is responsible for end to end effect analysis on the project 4. Project manager and the requestor will present the change request and the effects of the change to the review team 5. If approved the project manager will enter the approved changes in the project plan 6. Project manager is responsible for entering the request and the resulting decision in the project log 7. Project manager is responsible for archiving the project logs and answering any subsequent questions regarding the change 8. Project manager is responsible for informing and resetting expectations with executive champions, as needed 7.
Conclusions
Although multi‐vendor project management poses certain difficulties, it also provides great rewards. The excitement of working on new an exciting functionality make possible only through collaboration should certainly outweigh the challenges. The PM must however walk an even tighter rope as far as balancing the needs of the project vs. maintaining positive relationships with key stakeholders. The project manager is much more visible in the case of multi‐vendor projects and short lapses of judgment can not only damage the project but can possibly damage the relationships between companies. Identifying senior project managers that have experience in relations between companies (e.g. business development) is key to success.
