When IT is supporting a strategic alliance, it must take the time to plan. The time spent up front will be well worth it, ensuring that all parties are clear on the needs and desired results. A thorough project management methodology is critical to success and to compress the overall timeline. In particular, IT should:

-   Understand the business area’s strategy and objectives for the alliance: This includes reading the strategic alliance contract, charter, and other documentation. It is also important to meet with the project manager, and potentially the sponsor, to start building the relationship and to discuss the critical success factors. Once the overall objectives are understood, they should not change going forward. It is important to stay on top of changes in lesser objectives.

-   Understand the other company’s objectives in the alliance: If the objectives of the two companies are congruent, both will work toward a common goal. If the objectives are not complementary, conflict may arise. Although the overall objectives may be the same, there may be legitimate but different subobjectives. It is important to take the time to understand and agree upon all the objectives, clarifying and resolving all issues.

-   Get to know the other company’s IT area, culture, and processes: Understanding how the other company operates will be important in working through issues that arise. Up-front knowledge of the other company’s decision- makers, as well as its processes for setting priorities and change management, will speed conflict resolution.

-   Develop a project plan in conjunction with the business areas: With the overall plan established, the IT portion must be detailed. Both business and IT representatives should develop and walk through the IT plan, for understanding and clarification. It is key to define the roles and responsibilities for each company, as well as for the business and IT players.

The project manager must be informed if the implementation timelines change from the initial to the detailed plan.

-   Execute and monitor the plan, making changes as necessary: Once the project plan is initially established, it must be tracked. To do so, the steering committee and front -line team should hold regular meetings, documenting and communicating the content of the meetings, as well as decisions to be made. When changes are identified, a formal change management process is necessary to communicate the effects to all interested parties.

-   Follow up with lessons learned: This process can be undertaken during the project at appropriate phases, or, as is typical, after the project is over. The facilitated session is an open discussion to document the project’s positive aspects and potential improvements. This is where the organization learns and grows by clearing the air and setting expectations for improvements going forward.

-   Create a c hecklist for future alliances: Since the organization will be entering into more alliances, it can learn from its experiences by developing a checklist of the necessary steps, illustrating what worked well, as well as the pitfalls to avoid. This checklist can be used as a starting point for the next alliance, although there will be changes, additions, or items that may not apply going forward.

The Detailed Plan

The most difficult part of the process is to develop the detailed plan, possibly because there might be a gap between the business’s initial expectations of the alliance and what can really get accomplished at a detailed level. The project plan includes scope, timeline, and resources. While project managers cannot dictate all three, they should be able to determine at least one. Of course, even if the scope and timeline are set, IT cannot always accomplish the objectives by adding more resources to the project. No matter how many resources are available, some processes cannot be completed more quickly.

Scope The project plan’s scope should be as complete as possible. Here, a number of issues will be raised, and solving them quickly will be a key success factor. An issues log with origination date and required answer date is a necessity.

In an alliance, one company will typically have an unsuccessful line of business that is a strength of the other company. It is necessary to decide what to do with the potentially competing line of business: continue it, convert it, or sell it. This determination usually differs from establishing new linkages between the different IT resource efforts.

However, it is also critical to define new linkages between the companies in terms of systems integration and data sharing. Examples include marketing and financial information, revenue, and financial compensation. Detailed discussions are necessary for data definitions and mapping.

The size of the alliance effort depends on related experiences and expectations on the part of both companies. Companies with previous alliance experience are more

likely to reuse programs, interfaces, and file generation. Companies with little or no such experience will require more time, effort, and communication.

Identification of all the hardware, software, and staff costs involved will help expedite the transition. For example, an alliance will close more quickly if software licensing costs continue to run transition systems on the selling company’s infrastructure as a third-party administrative function.

In addition, both organizations should include enough travel budget and time to develop proper face-to-face relationships. IT should also build solid relationships with the vendors involved to ensure a smooth transition for packaged applications. Success depends on having a strategy for contacting vendors. For example, if one alliance company has a better working relationship with various vendors, it should be leveraged.

Planning should be included for all phases of the effort. These include requirements development, systems development, testing (of IT, the business area, systems, performance tuning, etc.), conversion, and implementation.

Unforeseen costs will arise. If the contract wording specifies that all costs are shared equally, all profits might also be shared equally.

The business’s general, high-level scope must be compared to the detailed scope as defined above. This checkpoint raises new issues that must be validated regarding if they are in or out of the initial project scope. This determination might require costbenefit information.

Timeline A timeline is typically established during the contract discussions. It might be a vague statement targeting the end of the third quarter, or it could be based on a company year-end.

IT should understand the exact commitments in terms of the business deliverables and logic, in order to gauge the flexibility for changes. When IT understands the business logic behind the timeline, the only options for change may be to reduce the scope or increase the costs.

Once the timeline is agreed to, there must be communication of status at established milestone checkpoints. Contingency plans must be developed in case the timeline cannot be met.

Costs The business area usually has a cost in mind for the alliance that has been approved in the project plan. Once the detailed IT costs are validated, they must be immediately communicated to the business area, to determine disparity between the initial and detail plans. All costs must be included, from hardware and software to staff time. The latter requires an assessment of the necessary skill sets, and some hard dollars may be needed for contracting.

The costs should be itemized and attached to specific scope items and deliverables so that the business area can analyze the costs and benefits of scope decisions. In some cases, IT and the business can work together to reduce specific requirement costs by scaling back or making slight changes that dramatically reduce the timeline

and cost. No matter what the final figure, the plan should include some level of contingency funding to ensure sufficient money to complete the project.

IT SUPPORT AND DIRECTION

While the above activities are IT responsibilities, IT can also help the business area by:

-   Defining the alliance’s critical success factors: IT can identify specific items to be measured and communicated regarding the alliance’s success, including conversion ratios, revenue, expenses, and quality factors. It is much easier to design systems to meet these needs up front, rather than redesigning them later.

-   Working with the business area to map out key processes: IT can draw a diagram of all the processes to show what is happening and when, so people can clearly understand what must take place in the alliance efforts. If there are gaps, it is easier to find them early on. Understanding the timing is key for daily, weekly, monthly, quarterly, and yearly exchanges. Mapping will also highlight differences in the companies’ reporting schedules; for example, use of calendar year versus the corporate year-end.

It is important to map key business, financial, and systems processes, including critical dataflows and timing. Mapping business processes requires showing how the current processes work now and how the new processes will flow in the future. Changes to business processes might target phone call routing, procedural changes, and technological changes based on different systems used.

Financial processes will be mapped in different degrees of detail. For example, highlevel financial reporting can be shown by summary numbers from a paper report, while detailed reporting is necessary to pay compensation based on transactions. Systems flows are important in showing different physical implementations of technology. Also, when an IT organization is switching to the new environment, it should not remove the old technology infrastructure too soon, in case there are transition issues.

-   Defining gaps in data definitions: In new alliances, where there is no existing business to transition, this step may not be important because each company will bring its own definitions to the table. Gaps in data definitions become more important when there is a transition of business from one company to another and detailed data mapping is required. The first step is to define data requirements for each system; for example, to illustrate what each field or file layout represents. Key business and IT staff must be assigned to work through the issues.

-   Developing comprehensive plans to address the gaps: It is important to bring alternatives and solutions to the table because IT has invaluable experience and knowledge. When IT understands the overall alliance objectives, it can strengthen its relationship with the business area by offering recommendations in solving business problems.

HOW TO AVOID COMMON PITFALLS

IT should build a positive relationship with the business area first. This cannot be emphasized enough because the alliance project will face obstacles and stressful times, and a good business/IT working relationship will greatly enhance the resolution process.

The companies’ business and IT areas should also spend time face-to- face and oneon-one. Not only is it important for IT to develop a good working relationship with its business area, but also with its strategic alliance peers. After the initial relationships are established, telephone calls and videoconferences are good tools to continue them. However, there must still be periodic face-to-face contact.

IT should understand the business and remain plugged in. Things change hourly during and after negotiations. Keeping up to date with the business can happen through formal status meetings or through informal talks with the project lead and sponsors.

The business area should direct and lead the negotiations. While it is the responsibility of IT is to benefit the business, there are other ways to provide necessary input to the business area.

IT should not publicly point out all the problems and pitfalls between the companies. Although IT staff members can be analytical and often correct in their assessments, they should remember to bring solutions to the effort. Options to overcome issues should be communicated to the business area.

IT should avoid having too many leaders. Instead, a point person from each company should be identified to direct the IT effort, which will help others understand their roles.

IT should also make sure both sides understand the other’s definitions of key data elements. In addition, IT should stay in tune with software and hardware versions and releases for both companies during the alliance effort. Versioning control is important in eliminating rework later on. Finally, IT should prioritize work and have a steering committee to elevate any issues when necessary.

CONCLUSION

In an alliance effort, IT can add value by partnering with the business area to become involved as early as possible in negotiations. A successful alliance will be more likely if IT takes the time to carefully plan up front, and then communicate broadly as soon as possible in the alliance effort. IT should also pay attention to the subtle cultural differences within and between the two organizations. Related problems are likely to arise and must be managed or they will create difficulty as the project moves forward.

Strategic alliances are here to stay and will continue to occur, both horizontally and vertically. It is critical for IT to change the business area’s perception of the function from that of a necessary evil and expense, to one of a partnership that can add significant value. IT can be valuable in helping the alliance get started and

implemented faster, and with a higher degree of quality. This translates into a strategic advantage for the company.