Construction Software Review .com

• Estimating Reviews
• Job Cost/Accounting Reviews
• Project Management & Scheduling Reviews

ADDITIONAL RESOURCES

Successful System Implementations

by Peter Luke of PMA Consultants

Virtually every enterprise would like to do more with less; and many construction software vendors promise improvements that can deliver on this wish. A myriad of possible automated management solution methodologies could address an organization's needs, with varying degrees of effectiveness. A wide range of construction management software solutions or tools are available in the market place. In PMA's experience, however, it is unlikely that any one commercial product will exactly match the needs of a specific enterprise or public entity. "Your" solution is probably not on someone's shelf. Risks involved with purchasing and implementing off-the-shelf solutions can include misunderstanding or misrepresentation of business rules key to the successful operation of your organization; wholesale changes in existing standard practices or operating procedures that can lead to confusion, errors, and significant resistance from users; and difficulties in reconciling prior planning, budget, and schedule data with that represented by the newly implemented system.

In our experience, the most successful implementations of new management systems occur when the new system functionally resembles as closely as possible the system extant at the beginning of the process. It is also important to include influential key representatives from various levels of the enterprise or public entity in the development process, so each level can contribute value and adopt "ownership of the resulting improvements.

Key Milestones

Successful system implementations evolve through a series of logically organized steps designed to ensure that the organization's best interests are represented throughout the process. Define the Problem "What is it that we're trying to fix, anyway?" Identify which components of the organization's business processes are failing to achieve satisfactory results, who says they're unsatisfactory, and how you will know when they're fixed. Clearly specify in general physical terms what improvements are desired; for example, pay bills faster, produce more widgets, reduce the cost of a process, complete work on time and within budget, etc. Avoid the temptation to solve the problem during this step.

"Who's in charge?" Process improvement typically requires some degree of change. The larger the enterprise, the more likely existing processes, procedures, and institutional red tape will hamper the change process. In our observation, many new system implementations fail because aspects of the evolving changes run contrary to established norms or even violate corporate procedures. To be successful, a process improvement must have a management champion at a level sufficient to overcome institutional inertia.

"Who are the players?" To ensure that all parties are adequately represented, it is beneficial to compose a team of knowledgeable representatives from each department or group that will be touched by the developing system. Assigning subject matter experts from each relevant faction will be of great value when identifying problems and finding solutions to minimize adverse changes, while keeping the goal in mind. The team should be lead by a knowledgeable member of the organization that will ultimately be responsible for the successful operation of the new system. Just because computers are involved, does not mean that Information Services should run the show.

"What are we doing now?" Clearly document each step of the existing business processes before attempting to construct a solution to the perceived problem. Occasionally, this procedure will highlight relatively small issues that can be fixed to avoid major changes. Each practice should be defined in terms of input (what data is received and from where), process (what actions or transformations are performed on the input data, and by whom), and output (what form the results will take, and who receives the end product). It is also useful to record how long each step normally takes and to identify the causes if significant variations are typically experienced.

"How will we know when we're done?" Define each expected product in measurable terms; for example, produce invoices within 5 days of the end of each month, issue project status reports within 2 days of each schedule update, reduce project overruns to 2%, etc. Verify that the desired results are reasonable and achievable within typical performance standards for your industry.

"How are we going to get there?" Determine the differences between your goal and your current position. Based on this "gap analysis," identify what new or changed procedures will achieve the desired results. If it is not apparent what steps are required, go back and refine the existing system documentation or desired results until a clear path is revealed. Define and document data requirements, entity relationships, and system components required to achieve the desired results. Provide relevant core team training if/as required. Break the required work into achievable steps and assign action to appropriate team members. Allow a reasonable time and sufficient resources for each step to be performed. It is helpful if participants clearly understand how and where their tasks fit into the big picture, so the entire team will understand the potential consequences of failure of any component of the work plan.

Enable each subcomponent of the new system to be developed independently by cognizant team members, but regularly review progress with the team as a whole. This avoids the team being bogged down in details, while ensuring that the overall data flow and processing remains faithful to the plan.  Frequently test the interfaces between system components to avoid surprises or delays.  Verify that each component is capable of addressing a realistic volume and range of production data.

"Does it work?" Train a pilot team to use the new system. Ensure that the pilot team fully understands the intentions of the new system. Load and exercise the system with live data representing a manageable subset of actual or realistic data. Perform tests of functionality, load sensitivity, and effectiveness of user interfaces. If possible, conduct pilot testing in parallel with the existing process and compare the results. If time permits, two or more business cycles should be tested. Make appropriate adjustments to the developed system until the desired results are consistently achieved.

After incorporating improvements suggested by the pilot, train all new users incorporating knowledge gained from the pilot team. Set up system hardware and software and load system with production data. Implement and exercise the new system. Again, if possible, conduct roll out in parallel with the existing process and compare the results.

"How did we do?" Formally compare the results produced from the new system with the initial expectations. Review the system's overall performance relative to the plan and provide recommendations for improvements or further enhancements. If necessary, document differences and develop a rationale for accepting the results or for additional development.