ECONOMIC FORECASTING REVIEW - Parsons Brinckerhoff

More documents

Recommendations

Info

Vol. 3 • Issue 2 Integrated Project Management Information Systems Accessibility • Ability to easily set security and permissions to project data • Web-based accessibility from anywhere in the world with an internet connection • Ease of access to multiple disparate applications • Single source access to all relevant project data iPMIS implementation phases The implementation of an iPMIS system on a project is improved by applying proven methodologies for delivery. Although each project is unique, the implementation process usually evolves through the following path: Project dashboard showing integration from schedule, cost, risk and other project management applications Project dashboard showing integration from schedule, cost, risk and other project management applications and other applications used to provide project information to decision makers. Properly configured, these tools provide the core software infrastructure backbone. As these systems are updated, the iPMIS system will provide a combined suite of applications with accurate information. iPMIS benefits Benefits of implementing an iPMIS solution can be summarized into three distinct areas: Cost • Fewer user licenses for applications are required • Reduced analytical labor costs in producing project reports • Standardization costs are greatly reduced • Reduced new software costs resulting from the leveraging of existing clientowned software • Leveraging existing client-owned software results in a reduction of new software purchases Efficiency • Dashboards present summarized project data, schedule, cost, and risk status on one screen • Customized user interfaces with specific views of project information • The ability to access many applications from one centralized location • Users can generate their own query information • The WBS provides an intuitive structure that organizes project data and information in a way that is easily understood by the user Phase I - project definition During project definition, iPMIS teams work to identify what software tools will be needed to manage the project, based on client and/or project requirements. It is not unusual for clients to specify particular software to be utilized based on their experience or existing project-related purchases. Phase II – consolidation Business processes are further defined, streamlined, and consolidated. The WBS is created in this phase. Value engineering from a software and systems integration perspective may also take place during consolidation. Phase III – integration Selected tools are integrated into the iPMIS while conforming to the WBS coding structure. The integration process is iterative in nature, with the first iterations typically being the delivery of the iPMIS web-based portal with at least two integrated applications. The iterative approach provides a method for quickly seeing progress on the development of the long-term solution while allowing future updates to be identified and incorporated in a modular fashion. 45
EFR Vol. 3 • Issue 2 Phase IV – implementation Implementation usually begins following the first iteration in Phase III. Beta testing, user training and the initial rollout is conducted in this phase. An effective implementation promotes early adoption, buy-in, and eventually sets up the overall success of an iPMIS system. Phase V – maintenance As project control experts feed and manage project control applications, iPMIS is brought to life and is set to begin to evolve through the project lifecycle. Updates to commercial software and general iPMIS maintenance activities continue to be performed to ensure system integrity and to adapt the project iPMIS to changing needs. “Agile” development of iPMIS Years ago, it was assumed that the way to prevent misunderstandings was to execute a “big requirements up front” (BRUF) process. With this approach, a business analyst would solicit long drawn out requirements in great detail and would document it all in a very large specification document, quite often hundreds of pages long. Unfortunately, documents of this size are not always read by most of the key players and often become obsolete as quickly as they are written. This leads to missed requirements and a development process which is misunderstood. Another drawback with a BRUF approach is that, based on documents provided, software developers go to work to produce software that exactly matches the specification, which is often already out of date when development begins. The unfortunate, but all too often encountered, result is that by the time that the newly completed software product is unveiled, the client finds that the system identified many months earlier no longer meets project requirements. The lack of solid and clear communications will usually lead to a failed project, which is why, historically, the majority of software projects worldwide exceed cost budgets and time allocations. An effective solution to avoid common pitfalls is to utilize a type of iterative or “agile” process, using Feature Driven Development (FDD) through an iteratively staged process. This has been widely embraced throughout the software development industry. Through experience, PB has learned that an iterative approach, somewhat agilistic in nature, provides major benefits over the antiquated BRUF methodology. Using the iterative approach, if a client receives a software deliverable which turns out to be something other than was expected, it usually stems from a communications issue, not a technical one. This is what an iterative approach aims to solve. It is a proven and capable methodology in systems integration and software delivery in all industries. The iterative process does not necessarily reduce the overall delivery schedule of an iPMIS system, but it does capture requirements and deliver them in bite-sized portions, providing a more effective development process. This also reduces cost in delivering solutions on target throughout the project lifecycle. Requirements are typically gathered using a variety of means, including workshops and personal interviews. Once captured, they are packaged into small iterations or scheduled releases. With this approach projects Initial Planning • Requirements • Planning • Evaluation • Two- to Four-Week Iterations • Analysis and Design • Testing • Implementation • Deployment Image depicting the iterative lifecycle through phases of an iPMIS project can often see the first iterations of an iPMIS deployed in as little as four weeks, allowing project teams to begin realizing value at the first release. Using an iterative approach, functionality is prioritized with each iteration so as client needs change, so can the iPMIS deliverable. Two main benefits to this type of agile approach include: 1. Decreasing project risk and allowing the initial budget for an iPMIS system to match only what it takes to get to the first release. 2. Encouraging buy-in to the iPMIS project, which is critical for project success. Buy-in is enhanced greatly since key decision makers can quickly see and comprehend the value of an iPMIS system within a few weeks of the start date. Additional iterations are often released in as little as two-week increments allowing project team members to see the changes and update requests made only days earlier. In summary, the FDD approach provides clients and project team members with the ability to make changes to an iPMIS master program at each step along the development path, providing a best fit for their project and ultimately for success. Proven iPMIS success PB has several active iPMIS projects in place. Functional and third-party software applications are typically included in these projects. The goal of PB’s iPMIS systems is to incorporate a Services Oriented Architecture (SOA), which is a service used in software delivery whereby web parts can be published and/or consumed by other applications. SOA provides the ability for reuse among many common iPMIS integrations. For example, a web part for integrating 46
Page 1 and 2: EFR ECONOMIC FORECASTING REVIEW Vol
Page 3 and 4: EFR Vol. 3 • Issue 2 EFR Team Con
Page 5 and 6: EFR Vol. 3 • Issue 2 crafting det
Page 7 and 8: EFR Vol. 3 • Issue 2 Thanks in pa
Page 9 and 10: EFR Vol. 3 • Issue 2 on the pace
Page 11 and 12: EFR Vol. 3 • Issue 2 1.7 percent
Page 13 and 14: EFR Vol. 3 • Issue 2 Each compone
Page 15 and 16: EFR Vol. 3 • Issue 2 250 Construc
Page 17 and 18: EFR Vol. 3 • Issue 2 Is the U.S.
Page 19 and 20: EFR Vol. 3 • Issue 2 10% 8% 6% 4%
Page 21 and 22: EFR Vol. 3 • Issue 2 Technology T
Page 23 and 24: EFR Vol. 3 • Issue 2 • Research
Page 25 and 26: EFR Vol. 3 • Issue 2 Complicating
Page 27 and 28: EFR Vol. 3 • Issue 2 Volpe Center
Page 29 and 30: EFR Vol. 3 • Issue 2 Both of thes
Page 31 and 32: EFR Vol. 3 • Issue 2 Fuel Prices
Page 33 and 34: EFR Vol. 3 • Issue 2 (AAR). In 20
Page 35 and 36: EFR Vol. 3 • Issue 2 PB Assists T
Page 37 and 38: EFR Vol. 3 • Issue 2 purchases in
Page 39 and 40: EFR Vol. 3 • Issue 2 An Innovativ
Page 41 and 42: EFR Vol. 3 • Issue 2 This data in
Page 43 and 44: EFR Vol. 3 • Issue 2 Estimating I
Page 45 and 46: EFR Vol. 3 • Issue 2 expenses, pa
Page 47: EFR Vol. 3 • Issue 2 Integrated P
Page 51 and 52: EFR Vol. 3 • Issue 2 Sustainable
Page 53 and 54: EFR Vol. 3 • Issue 2 PB was hired

ECONOMIC FORECASTING REVIEW - Parsons Brinckerhoff

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?