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 cost-benefit 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, high-level 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 one-on-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’