Unique Cbbs Project Management Considerations

This section describes specific approaches to address unique characteristics of CBBS and their associated risks.

4.1. Project Charter

Project and IT governance are the responsibility of the sponsoring organization. Good governance processes make the following decisions at the organizational level: how much money should we spend on projects, and on which projects should we spend the money; which projects should we adopt organization-wide; how good does the IT product resulting from the project need to be; what security and privacy risks can we accept; and who we should blame if the project fails (Ross and Weill, 2002; Ross et al., 2002). Uniquely relevant to CBBS are the answers to questions of "how comprehensive does the product need to be," and "what security and privacy risk is acceptable." Answers to these questions will guide project scope, data cleansing efforts, and the design of security. "Who to blame if the project fails" is also interesting, because most CBBS cannot succeed without data from outside the organization. The organization therefore must be willing to commit senior resources to establish relationships with data providers to secure their commitment, which is pivotal to project success.

In not-for-profit organizations, questions of "how much to spend" and "which project to spend the money on" introduce the difficult problem of determining public value. Measuring the performance and value of an IT project is "more of an art than a science," because financial measures, such as return on investment, do not completely apply (Weill and Ross, 2004). Weill and Ross (2004) and Moore (1995) provide frameworks for addressing public value and project and IT governance for not-for-profit organizations.

Project managers should push organizational sponsors to answer these key questions and document the answers in a formal "project charter."

4.2. Project Stakeholders

Stakeholders in a CBBS include more than just the system users and developers:

• Organization data privacy and compliance officers

• Data acquisition team (including the attorneys negotiating the usage agreements)

• Data providers

• IT infrastructure providers

Project teams need to consider the needs of these critical stakeholders during the project initiation phase, because overall project success may depend on their participation and acceptance of the solution.

4.3. IT Infrastructure

Changes to IT infrastructure to support CBBS can be costly and time-consuming. In addition to including the providers of IT infrastructure among the project's stakeholders, project teams should perform a high level assessment of the current IT environment early in the project to determine what infrastructure is in place to support the CBBS. If infrastructure upgrades are required to support the CBBS, determine funding responsibility and include the upgrades in the project schedule and project management plan.

4.4. Consider Solution Alternatives

CBBS can be custom developed, built from open source or COTS software, or provided as a service from an ASP. A single CBBS may integrate components of all these types. Defining requirements in implementation-neutral terms supports

1 Adelman and Moss comprehensively cover the project management issues of data warehouses in the referenced work, Database Warehouse Project Management.

consideration of all three alternatives. Requirements should address "what" the solution must do. Evaluate the capability of alternative solution approaches (COTS, open source, ASP, combination) to meet the requirements.

Project teams should add detail only after selecting a solution approach, because the required level of detail varies by solution approach:

• Custom development requires detailed definitions on exactly "how" the system will meet the requirements. We call this detail is called "system specifications."

• Customers have less control over how a COTS/open source and ASP solution meets their requirements. The details required for COTS/open source and ASP solutions is "configuration specifications"—how the existing systems will be configured to meet the requirements

Preparing system specifications describing how a system implements a requirement is a wasted activity if COTS or ASP solutions are to provide the functionality. In general, there is limited control over how COTS and ASP solutions implement a functional requirement.

Teams must design their projects to perform "data discovery" activities for each potential data source as early in the CBBS project as possible to determine data quality. It is necessary to analyze a sample of the real data to estimate quantities of data expected, data structure, and data quality and completeness. The project team will also want to create sample data sets from the retrospective data to be used during system development and testing to simulate prospective data feeds.

4.6. Solution-Specific Development Phases

Prepare detailed development and implementation plans considering the selected solution type: custom software, integrated open source/COTS systems, ASP, or combinations of these. Design development and implementation phases by considering project risks and addressing the highest risk elements first. Consider including tests demonstrating all the data processing steps on process sample data sets as soon as possible in the plan (end-to-end tests). Then add additional functionality to the proven end-to-end framework.

For solutions integrating open source or COTS, development will include procurement activities covering request for proposal (RFP) preparation, proposal evaluation, vendor demonstrations, negotiations, and contracting. The durations of the negotiation and contracting phases are difficult to estimate and normally outside the direct control of the project team.

Consider basing the development phases for these solution types on the vendor's standard implementation approach.

The project team should determine detailed development activities based on the selected vendor's standard implementation processes. Why? Because, the vendor develops these processes to best suit its products/services, and these processes are well understood by the vendor's team. Even if using the vendor's process, do not forget the early demonstration of capabilities by using the data sets developed in the data discovery phase.

The development activities for an ASP solution, such as the RODS implementation for the 2002 Winter Olympic Games described later in this chapter, should be similar to those for open source/COTS solutions. The procurement activities for ASP solutions need to consider the required level of service, and the final contract must include a service level agreement (SLA) defining system availability and recourse if the SLA is not met.

4.7. System Support

CBBS-specific considerations when planning the closing phase include addressing methods and responsibility for notifications by data providers of changes to the data provided.

Was this article helpful?

0 0

Post a comment