AWWA/WEF Information Management & Technology Conference, March 4-7, 2007, Austin, TX

Transcription

1 Management and Control Technology for Water/Waste Water Utility Programs Burcin Becerik 1, Gustavo Soto-Rosa 2 Abstract This paper discusses the implementation and use of management and control solutions for water/waste water utility control programs to streamline workflow and enhance project results. Topics include what solutions are applicable for project management and collaboration, how to evaluate what solution to implement, what the implementation steps are, how solutions differ for different stages of projects, and what lessons were learnt for Managers and Owners. The paper discusses these topics through two actual development and implementation examples of management and control technology. 1 Introduction Public agencies under federal consent decrees are committing to take corrective actions to clean their waterways. These decrees are usually addressed by a series of construction projects to eliminate water quality violations and improve the reliability of sewer lines and systems. As these decrees result in large and long-term programs, public agencies often must also make major organizational, procedural, and operational changes. Organizations fundamentally have to rethink their approach for doing business, including the creation of new roles, responsibilities, and business processes to meet aggressive deadlines. Management and control of numerous construction projects requires effective communication, budget, cost, contract, and scheduling management. Depending on various parameters (i.e., project stage, deliverables, and team size), the project controls and management team selects the most appropriate solution(s) to implement. The following sections of this paper discuss lessons learned during management and control technology (MCT) evaluation, implementation and use. 2 Management and Control Technology Development & Implementation This section outlines the considerations for MCT implementation. Two examples: program management dashboard and eroom deliverable control system, are used for discussion purposes. Following is the brief description of these solutions. Program Management Dashboard for Management/Client Access: This dashboard has been developed for deployment at various capital long-term control programs that CDM manages. The dashboard provides on-line access to monthly progress reports, which provide information on status, progress (earned value, permits status, funding status), schedule, cost, and compliance (EH&S, MBE/WBE, affirmative action gals, QA/QC issues). This web-based solution is password protected and accessible 7/24. 1 Dr. Burcin Becerik works for CDM as a management systems specialist. She has degrees in architecture, civil and environmental engineering, and project management. Last year, she completed her doctoral degree at Harvard University in the area of online collaboration, program management technology implementation. She works with clients in identifying and implementing management systems to facilitate control and monitoring of programs, and to foster communication and collaboration among internal and external project team members. 2 Gustavo Soto-Rosa works for CDM as a senior program/project controls specialist. Mr. Soto-Rosa has a Masters of Engineering degree from the University of California at Berkeley, with a concentration in Construction and Engineering Management and an architectural degree from Universidad Simon Bolivar, Venezuela. He specializes in the management of large-scale infrastructure and environmental projects and has worked on the Boston Harbor Cleanup Project, Hartford s Clean Water Program, USACOE s Baltimore Total Environmental Remediation Contract, New York s Water Dependability Strategy Project, New York s 2 nd Ave Subway, and the Boston Convention and Exhibition Center.

2 Figure 1: Info page of the dashboard summarizing project description, news, team contact information, and overview eroom Deliverable Control System: The deliverable control system was developed to provide a collaboration space to develop conceptual designs for 11 projects that are part of the conceptual design for the CSO component of a major capital program. The conceptual design was executed by geographically dispersed design teams. The deliverable control system captured progress information on the technical design memoranda that composed each conceptual design project giving management real-time data on the status of each project. The tool was also designed using a workflow engine in an eroom, allowing automatic notifications to project participants as the technical memos advanced through the workflow.

3 Figure 2: The deliverable control system summary page showing number of entries in different stages of the project The following sections discuss lessons learned during development and implementation of these systems. Steps include planning and design of the system, training, user acceptance tests, documentation, and continuous support and maintenance of the system. 2.1 Needs Assessment for Finding the Right Solution There are numerous commercial and custom-built technology solutions implemented and used in the industry. The first step to implementation is selecting the most appropriate solution for the project, which requires understanding the needs of the management and team members. Depending on the scope, schedule and budget, projects and/or stage of projects might require different solutions. It is crucial to understand the needs of the team members and map these needs to the capabilities of the different solutions being evaluated. For the dashboard, the implementation team interviewed several program managers to understand their requirements and needs. The team also investigated the information that clients would like to access. It was evident that the managers were in search of a solution that will integrate information from the different applications required to manage their program. Managers wanted a dashboard to access critical project management information, including schedule, cost, and compliance information from any computer with an Internet connection. Ideally, this tool would pull information from several applications such as scheduling, cost, and document management solutions and visualize information in couple weeks. As many of these projects are publicly funded projects, there was also a need to communicate the progress and changes to the public and stakeholders. Managers wanted to have a solution that will facilitate information sharing with the public and client stakeholders. The goal was to have job site pictures, daily logs, progress updates, and projects; locations in this dashboard. Making this information accessible via the dashboard, allows the public and operations groups to monitor job progress without having to contact the project personnel. In addition, some end users raised their preference of accessing information through a map interface.

4 Figure 3: Sub-program level home page summarizing projects performance, schedule and cost status For the Deliverable Control System, the implementation team began the process by mapping the conceptual design workflow process through discovery sessions with the design manager. A work breakdown structure was established where each conceptual design was broken down into a series of technical memoranda applicable to each project. The design manager established the key milestones dates that he wanted to track to evaluate the progress of the design. The discovery sessions also included meetings with the QA/QC manager to consider his needs in following the company s QA/QC procedures. An organization breakdown structure was also established mapping different users to different roles and assigned by projects. Each step of the workflow designed during the discovery phase was assigned an earned value upon completion to normalize the evaluation of progress across the different design project managers. For example, technical memos could not be declared more than 75% complete until they had been reviewed by the QA/QC manager. The requirements for the deliverable control system included establishing a summary dashboard that would give management a quick overview of the status of the conceptual design, highlighting deliverables that were falling behind or that needed more attention. The system had to allow for access control to restrict users from opening and/or editing individual files depending on their roles and their assigned projects. Security was a paramount consideration as the system had to provide an audit trail of changes to the documents while allowing different users to collaborate on editing the files. Figure 4: Deliverable status in a snapshot 2.2 System Selection After analyzing and documenting the needs of the team members and projects, the second step was choosing the solution. In the case of the dashboard, the team has evaluated several solutions and analyzed pros and cons of these solutions. The goal was to choose a platform that requires minimum investment and that is commonly used in the industry. The team looked at several portal

5 technologies and decided to use Microsoft SharePoint 3 as a dashboard and collaboration platform. The reasons for choosing this technology were: Minimum application development requirements in terms of web-parts and web-controls Wide use of this technology in the industry Availability and affordability of the technology Most of the technology platforms had integration with this technology Clients owned and used the technology In the case of the deliverable control system, the workflow engine of eroom 4 was selected primarily because of the following reasons: It met all the functional requirements established during the discovery phase. It has a very friendly user interface. erooms are extensively used in the corporation, allowing us to leverage the added functionality at no cost. Part of the objectives of the implementation was to test if the software could be used for deliverable management. 2.3 System Design Stepped approach for systems development was followed by the implementation team in both cases. In case of the dashboard, the steps were: Working with PowerPoint mock-ups to refine the requirements: This has helped the managers evaluate each screen of the system. The team has decided to have eight main tabs at the project level: o Home tab - visualizing the location and providing an overview of the project on a Google map interface o Info tab - providing general information about the projects such as project descriptions, news, overviews and team members o Progress tab - visualizing physical progress, permits status and funding status with charts, tables and text o Cost tab - providing information about project budget, actuals, change orders o Schedule tab - visualizing schedule, milestones and deliverables o Compliance tab - showing MBE/WBE, EH&S and QA/QC compliance At the sub-program level; the team decided to have key performance indicators and gauges summarizing performance, schedule, and cost information of all projects under the sub-program in one screen for executive management. After coming to an agreement on the design and information that will be visualized in the dashboard, the team has started working with the first prototype. The team had several design sessions to get feedback from the end users, and revised the system based on this user feedback. Presented the tool to the client and got their feedback and revised the system based on their input. Carried the system to production to DMZ 5 so that external parties can have access to the system. Provided access to internal and external users A DMZ is a computer network that is accessible from two other computer networks that have no direct contact with each other. Often, one of these networks is the Internet and the other is a local, internal network. There is no direct connection between the Internet and the local network, but both of them can access an intermediate network, a demilitarized zone.

6 Figure 5: PowerPoint mock-ups for the project progress tab Figure 6: The dashboard s project progress tab

7 Figure 7: Cost tab summarizing project cost to date, change orders and expenditures vs. budget In the case of the deliverable control system, the designs of the workflow and the summary screens were presented to the design manager and the quality control manager for evaluation and conformance to the company s quality control procedures. Each technical memo was assigned a record in the database and the file for the technical memorandum and associated supported files were attachments to the database record. Additional fields were added to track: Start Date Initial Draft Completion QA/QC Review Final Draft Completion Editing and Spinning Completion Design Manager Review Client Review Incorporate Comments Final Design Manager Review Finish Date Project Manager Percent Complete Progress Report

8 Figure 8: Earned value curve showing the progress of a conceptual design deliverable Figure 9: Snapshot of deliverable status with key performance indicators Engagement of End Users It is extremely important that the solution is designed with end users contributions. Systems exclusively designed by the IT staff or management staffs are usually rejected by the end users. It is important that end users are included in the design sessions so they become partners in the implementation and supporters of the new system. For example, an initial pilot project was selected to evaluate the deliverable control system and obtain user feedback before it was deployed to the entire team. During this piloting period, the implementation team worked closely

9 with the assigned project manager to evaluate the system s performance and process user feedback to correct minor details before we rolled out the tool to users. Process/Data Requirements Systems should follow the business processes. Unfortunately, some of the more rigid technology solutions mandate that end users and organizations change their processes to adopt the solution s processes. Although technology implementation is an opportunity to re-engineer and improve business processes, it needs to be done very carefully and the goal should be business process improvements - not technology implementation. 2.4 Training/Testing/Documentation Every system needs to be tested after being designed and configured. End users should be the part of user acceptance tests. Proper documentation and training must be provided to the end users. Many of the software implementations fail due to the lack of training. The research shows the average training provided to end users for implementation of a typical online collaboration tool is about 2-3 hours which is not adequate for successful use. (Becerik and Pollalis, 2006) The training should be based on roles but not less than 3-4 days per person. Necessary changes need to be done after getting the user feedback during the user acceptance tests. Training sessions were held with each design team during the implementation of the deliverable control system. The training materials were made available online as part of the tool where users could access them at will. Instructions on the designed procedure and workflow were embedded inside of the entry screens to assist users while working on the system. A copy of the real database was placed in a sandbox area to allow users to play with the system and get acquainted with the functionality without worrying about the consequences of mistakes but using the same real data so it would be meaningful to the user. 2.5 Success Factors Vision/Commitment Development and implementation of these two examples have been successful because the vision was supported by the needs of the company and the programs. The team was committed to the success from top to bottom. The decisions were given on a timely basis to avoid any delays. Management Support Technology is as good as the information it is presenting. A challenging part of these implementations was the data collection. Unfortunately, in our industry it is common that there are back pockets even in the most sophisticated companies. Also, the dashboard concept makes the information accessible and visible when there is a potential problem/roadblock and that makes end users reluctant to share information. Tie to a Project; A Real Life Example It is essential that the technology implementation is tied to a real life example. By doing so, you can use the project to set up your system, define requirements and detail the use. You can also get the commitment of the end users and managers. You can test your system, get users feedback and enhance it. If the system is designed for a mock-up project, it is more likely that it will be deferred for other projects. Resource Planning Implementation of a technology solution requires extensive planning and resources. Even today s off-the-shelf tools require certain level of design, configuration and maintenance. Staff Technology implementation requires hiring implementation staff with required skills and knowledge. Depending on the size and scope of the implementation project; the number of resources you will need will change however common

10 roles needed are as follows; business analysts, IT engineers, subject matter experts, and a project manager. Time After the selection of the system, implementation (including installations, design, documentation, training and deployment) of a commercial program management system can take 9 to 12 months with appropriate resources. Cost The cost can be broken into several categories such as license fees, maintenance and support fees, and implementation costs. The larger part of the Solution costs are hidden in implementation of the system, training, maintenance and support. The ratio of license fees to implementation costs is usually 1 to Use of the System The team started using the dashboard in January As of February 2007, there are 47 users, 2 consultants, 12 client staff, 6 project controls staff, 2 application developers, 10 project managers, 11 executive managers, 4 specialists. Implementation team is gathering feedback from the end users and getting prepared to make revisions. Members of the Dashboard are increasing daily. The Conceptual Design Team began using the Deliverable Control System in January 2006 and has continued to use the system for additional projects added to the initial scope. The image below shows the use of the system 1/1/2006 through 3/22/2006. Total of 45 users logged into the system for 1,818 times. 611 MB of files were posted/worked on, which adds up to over 5500 items. As you can observe from the report below, the used of the system peaked in March 2006 as the deadline for first drafts was April 1, Figure 10: eroom usage report showing the usage - January 2006 through March Lessons Learned for Implementation Teams As in every project, there are several lessons learned in these projects. Some are listed below:

11 Set expectations right and communicate them across teams; don t start with a prototype idea that becomes a production tool. Work with proven technology; the team experienced difficulties while working with the beta version of SharePoint Additional hindrances to the project included the lack of documentation and available help as the technology was brand new. Automate and streamline your processes as much as you can; try to determine what it would take for end users to use and maintain the system. Make sure the message is communicated from top to bottom and there is a mandate from management to the end users to use the system. Set roles and responsibilities right; administrators, end users, technology support, programmers, etc. 3 Lessons Learned for Owners 3.1 Data Transfer Consultant s engagement might or might not be continuous during the life of the program. It is recommended that the owner includes the terms of data transfer in the consultant s contract if they choose to use consultant s solution. Data gathered and generated during the engagement should be transferred to the owner in a format that can be maintained or used. 3.2 Commercial vs. Proprietary If the owner decides to use a consultant s system, it is important that the system is not the consultant s proprietary system. It is recommended that the system be an off-the-shelf commercial product so that the owner can purchase the same software or require the next consultant to use the same software if they choose to. This will eliminate the time, cost and resources to implement and learn a new system. 3.3 Integration Is it needed? The system should have a technical architecture to pull from and/or push to the owner s legacy systems such as GIS, the ERP system and document management solution. It should have the ability to integrate with the owner s enterprise project execution applications as may be appropriate in the future. Integration costs can be significant and it is recommended that integration to legacy systems be phased in alignment with information technology upgrade plans. 3.4 Flexible Tools with Workflows The system should have the ability to build the program s processes and automate workflow to route and track processes through logs. These logs should have the ability to track, compile, distribute and archive reports. System should support: production workflow uses predefined sequences to guide and control processes as well as ad-hoc workflow in which the user determines the process sequence/users on the fly. It should internally and externally (via ) notify users of new workflow tasks and it should have ability to send notifications (internal and external) when workflow tasks are late. 3.5 Technology Misuse It is common that the technology is not usually used to its full extent or for what it has been designed for. This happens due unfamiliarity with the f technology solution s capabilities and also lack of understanding of the business needs. 4 Conclusion Technology use is an important part of management and control of long-term control programs that have significant environmental and regulatory challenges to meet within aggressive time frames. However, the success of these programs is related less to the sophistication of the management technology deployed and more to implementation, human, and organizational factors. It is not uncommon to find organizations embarking on technology implementations well

12 ahead of addressing organizational limitations, including lack of proper standard procedures. Your management and control technology supports your organization and business processes, not the other way around. It is strongly recommended that organizations clearly map out, document, evaluate, and agree on their business processes in anticipation of a technology implementation. To maximize the use of the system and gain successful results engagement of the end users during systems development is crucial. Systems should focus on the needs of end users and try to follow their workflows with enhancements rather than forcing technology related workflows on end users. Crucial success factors include: Understanding business needs by thoroughly investigating and documenting end users needs and functional requirements, Obtaining early senior management buy-in and support, Involving end users during system design, Providing adequate training and support materials, and Performing continuous QA/QC and performance monitoring including on-going maintenance of the system. Successful technology implementation and use require some level of change management, and change is always painful. Therefore, change management should be planned at all levels of the organization. References Computer Aided Collaboration for Managing Construction Projects, (with S.N. Pollalis). Design and Technology Report Series, No , Harvard Design School, Cambridge, MA. (160 pages). ISBN ), April 2006.