1.         Multi-Site Simultaneous Implementations

Centralized Project Coordination

Centralized coordination is imperative in any multi-site project, even where most project management functions and decision-making are decentralized.

Why?  Several areas of coordination need to be optimized:

     The sites will encounter common issues, and may be able to utilize common solutions.

     Common software changes or custom-developed software may be shared.

     If package software is being installed, the status of expected fixes or product enhancements needs to be known by all site managers or project leaders.

     Site project teams will find it useful to share outside consultants who are less than full-time at one site.

For these reasons, a Consolidated  Management Summary Report should be prepared, distributed, and reviewed by conference call or video conference on a weekly basis.

A project coordinator should prepare the summary report, initiate the call, and moderate the discussion between the project leaders.

The Consolidated Summary

The report should include sections corresponding to each area of coordination: 

1.   Project Issues.  These are project-level, major issues.  Details include:

                 Issue # - For reference in tracking & discussion

                 Site - Site or division identifying the issue

                 Description - 5 to 10 word summary

                 Issue Type - Could be an application, or "Tech", "Hardware", "Training", etc.

                 Assigned - The individual responsible for resolving the issue

                 Status - Open, Closed, Delayed, etc.

2.   Custom Software.  This section identifies:

                 Item # - For reference in tracking & discussion

                 Site - Site or division requesting the custom item

                 Description - What the modification does

                 Design Approved? - A flag indicating whether this step is complete

                 Programming Completed? - A flag indicating whether coding is complete

                 Modification Tested? - An "X" indicates that unit-testing has been done

3.   Fixes and Enhancements.  Changes expected from the software vendor or development group.  Details on each item include:

      span style='mso-tab-count:1'>           Item # - for reference in tracking & discussion

                 Application - G/L, Sales Order Processing, etc.

                 Fix or Enhancement - A true software bug vs. a desired feature

                 Status - Pending Review, In progress, Undergoing Testing, Shipping, etc.

                 Estimated Completion - If and when the correction will be delivered

4.   Consulting Support Schedule.  This section identifies:

                 Item # - for reference in tracking & discussion

                 Site - Site or division receiving the on-site consulting

                 Purpose - Purpose of visit, or work to be performed

                 Date - Day or Week of consulting work

           Resource - the specific individual involved (This could be an external consultant, or a shared resource, such as a network engineer.)

                 Status - Tentative, Firm, or Canceled

The following pages illustrate a sample Consolidated Report:  (Since the report is updated throughout a project, some the item numbers have gaps in their sequence, where old issues or software problems have been resolved and deleted.)

Consolidated Management Summary Report

As of June 8, 19XX

2.         Multi-Site Sequential Implementations

A multi-site organization implementing similar software solutions at several locations may wish to conduct the projects sequentially, rather than all at one time.  The advantages are many, including:

1.   The company can develop in-house expertise in the software products being implemented, and bring this expertise to follow-on sites.

2.   Management can focus on supporting one or two projects at once, allowing it to leverage its technical and functional resources.

3.   A project team may share some of its members with subsequent installations, reducing ramp-up time for resources in the follow-on projects.

4.   The most difficult and complex implementations can be placed in the latter portion of the implementation sequence, allowing more experience and expertise to be brought to bear on these sites.

5.   The overall project can build momentum with early successes, increasing the confidence of users and management at the later sites.  This is particularly important when a site or division  has been reluctant to support the planned implementation.

Companies with multiple divisions implementing very similar sets of software applications are likely to select the Sequential Implementation strategy.  Companies whose sites or divisions are in different businesses, and are using different software applications, are more like to choose a concurrent approach.

Common Aspects of Multi-site Implementations

1.   Requirements imposed by a parent company must be combined with a software solution which satisfies the requirements of each particular site.

2.   The software will not be configured the same way at all sites, but requirements for common account numbers, item numbers, customer numbers and system interfaces are likely.

3.   There is a need for a distributed decision making process, while using consistent rules and procedures across all sites.

4.   Even though a solid strategy is agreed to by everyone at the outset of the overall project, the implementation effort requires continual evaluation and planning.

5.   At least one division or site will have resisted the decision to implement the software as selected by the company as a whole.

The "Multi's"

In addition to the multi-site or multi-company aspect of these projects, other "multi's" are often encountered:

1.   Multi-national

When an operating site is in a different country than the company's main offices or the software vendor, other factors need to be considered, such as:

     Different laws governing software licensing and service contracts

     Tariffs and Customs delays impacting the cost and timing of software distribution

     Work permits for consultants on long-term assignments

2.   Multi-language

Multiple languages at various sites in the organization require:

     Project team members who all speak a common language, even though the teams may be composed of members with various native languages, as well as foreign consultants. 

     Software to be translated into a foreign language before it can be implemented.  Screens, menus, reports, and documentation are often not translated by the vendor until several months after each release, if at all.  Many software vendors only support one language in their product and documentation.  The project schedules need to allow for a realistic delay caused by language translation.

3.   Multi-currency

At a minimum, the software solution will have to support consolidated financial reporting at the headquarters site, in its local currency.  Analysis reports may also be required to examine gains and losses from the fluctuation of exchange rates.

In the worst case, some individual sites may deal in multiple currencies.  For example, a receivable item recorded in Bahamian Dollars may be paid in Mexican Pesos, and a payable item recorded in German Marks may need to be paid from a U.S. Dollar bank account.  Addressing these types of requirements may involve customizing the application software.

Critical Success Factors

The success of a multi-site implementation using the Sequential Implementation strategy depends mainly on a few key success factors:

1.   A clear vision of company-wide project benefits/

Resistance to the project at a single site is best overcome through management's articulation of the benefits of the project for the company as a whole.  Benefits such as decreased operating costs, improved order cycle time, increased flexibility in responding to customer demands, or better financial reporting form management's vision for the long-term success of the project.  Every site, and every project team member, must clearly understand the project benefits.

2.   Consistent formal and informal communication

Communication among corporate management, site management, project managers, and third parties should remain consistent throughout each implementation.  Formal communication takes the form of status reports and regular conference calls. 

Informal communication is supported well by Electronic Mail, providing that all team members and appropriate third parties have access.  E-mail is particularly effective in projects that span several time zones.

3.   Consolidation points

Most multi-site implementations will require uniformity and consistency in the use of certain data elements.  For example, a standard chart of accounts is almost mandatory where consolidated financial reporting is a business requirement, and common inventory item numbers would be needed to support consolidated sales reporting.

These requirements need to be identified, and numbering rules agreed to, before the first site establishes its data base.  Representatives from all divisions need to concur on the design of these numbering schemes.

4.   Consistent software training and consulting

If a software vendor or outside consulting firm is involved, a single representative should be established to the project from this firm.  This Account Manager will be responsible for coordinating all consulting, training, and software distribution for all the projects at all sites.

If possible, ask the vendor or consulting firm to provide the same consultants for each project as well.  This will avoid the learning curve that consultants experience as they familiarize themselves with your business and project objectives.

5.   Consistent implementation methodology

Although the software will be set up and used in a different manner at each site or division, the approach to organizing and conducting each project should be consistent.  This factor is closely tied to the idea of resource sharing.

6.   Resource Sharing

Most of the benefits of the Sequential Implementation strategy are based on resource sharing.  If resources (team members) are not shared from one project to the next, the learning curve must begin again with each project, and no benefits are gained.

The Project Team Evolution diagram on the following page illustrates how resource sharing prevents each new project team from starting from scratch.

Project Team Evolution

Using the Resource Sharing Concept

                        An Overall Project Plan is developed,                                                         documented, and agreed to.

                     The Plan specifies which resources will                                                      support Project 1, Project 2, etc.

Project 1                                                                                     Project 2

Finally, a portion of the project team moves from Project 1 (Site 1) at its completion, to Project 2 (Site 2).  At the completion of the Site 2 implementation, members are selected to participate in the next project.

3.         Process Reengineering Projects

Performing a software implementation in a business environment where process reengineering is taking place places an extra burden on the implementation team.  Rather than automating processes which are long-established and familiar, the application software needs to support emerging practices and procedures.

Specifically, several steps need to be taken by the implementation project management to succeed in co-existence with a reengineering effort:

1. Understand why the Business Reengineering project is taking place

     Why is the company spending time, money, and energy on reengineering while at the same time buying or developing new software?  Is the company losing profitability or market share, or is management being proactive and forward thinking?

     Does top management view the software project as a piece of the overall reengineering effort?  Or are processes being adjusted to take advantage of capabilities in the software?  If it's the former, the Conference Room Pilot should not be held until after the redesign piece of the reengineering project is complete, and the new processes are documented and understood.

     What is management's position on package software modifications?  Often, a formal statement will be issued at the outset of a project that business procedures will be adapted to fit the new system whenever possible, rather than making custom changes to the software.

2. Get the right people involved

The reengineering project likely has strong, visible support from the CEO, or another top management figure.  If so, the membership in the reengineering team contains some key decision makers from the departments which will be impacted.

Make sure the software project implementation team is represented on the reengineering team, and vice-versa.  Status meetings and Conference Room Pilots are good opportunities to involve reengineering team members.

Conversely, as redesigned business processes are charted, presented and discussed within the reengineering team, the implementation project team leaders should be present. 

There are two purposes for cross-representation on the project teams:

     The software project team needs to be aware of the general direction of the reengineering project, and of specific process as they are documented and reviewed.

     The reengineering team should be aware of the functionality and limitations of the application software being developed or implemented.  Although software functionality will not normally drive business process design, the two need to be coordinated in order to derive maximum benefit from the software at minimum cost.

3. Understand the organizational impact of reengineering

Fundamental changes in company organization and culture will likely accompany the reengineering effort.  A summary of conditions before and after a large-scale reengineering project should include the following:

Before Business Reengineering:

     The company is organized around functional departments (Order Entry, Cash Receipts, Accounts Payable, etc.)

     The company includes a sizable bureaucracy, made necessary by the need to manage a large number of very specific jobs and tasks.

     The company's workers spend their time following orders, and performing relatively simple tasks.

>     Management is multi-layered.

After Business Reengineering:

     The company is organized around processes and process teams.

     Several earlier job descriptions are now combined into one.

     The workers are now making day-to-day decisions, and doing multi-dimensional, more complex, work activities.

     The number of cross-checks, audit-controls, and reconciliations are reduced and/or automated.

     A flatter organization is in place, with fewer layers between the customer and top management.

A reengineering effort of narrower scope may focus on only one business process, and have a much smaller organizational impact.  On a less-ambitious scale, fine-tuning or streamlining operations within a functional department is sometimes also referred to as Business Reengineering.

4. Become familiar with reengineering tools and technologies

Tools: Paper-based or electronic methods and utilities which help communicate existing processes and proposed changes among the reengineering team, and to management.  Among these may be:

     Process Maps

     Flow Charts

     Entity Relationship Diagrams

     Data Flow Diagrams

Technologies:  Advances in hardware, software, or related equipment which make radical process redesign possible.  Among these technologies:

     Computer networks (local and remote)

     Wireless Communication

     Voice Mail and Interactive Voice Response Systems

     Data Collection, Bar Coding, and document scanners

     Imaging and Document Management Systems

     Multimedia

     E-mail and Automated Calendars

     Groupware

     Electronic Data Interchange

     CASE software development

     Expert Systems and Knowledge Bases

5. Understand and document schedule impacts

The reengineering work should take place before or during the software implementation.  If the reengineering project is complete before the software project gets to the Conference Room Pilot phase, the software will be set up and tested according to a freshly defined and documented set of business processes.  This is the ideal case, and there will be little schedule impact on the remaining phases.

More commonly, however, the reengineering team will go about its work in parallel with the software project.  This is true because the software features will enable process changes.

During the Project Definition phase of the software project, determine which activities and deliverables within the systems project are dependent on the concurrent reengineering work, and schedule accordingly. 

For example, it would not be appropriate to schedule the programming of custom modifications for just before the planned delivery of a set of redesigned business processes.  This would lead to extensive redesign, reprogramming, and retesting of the software modifications.