Case Study: Develop Performance Review System

Overall Project Mission

The overall project mission was to develop an application to facilitate the Principal review process.

Prior to the development of the Microsoft Access application, much of the effort to maintain Principal review data, view data during review meetings, and generate reports was cumbersome and labor intensive.

  1. Principal data was difficult to maintain & data integrity was poor due to the storage of data in multiple spreadsheets.
  2. During the review meetings, Principal review data was manually captured on paper while hard copies of supplemental documents were distributed to evaluators.
  3. Administrators were required to manually develop ad hoc reports using data from the various spreadsheets.By creating an application with a relational database and a user interface, the Principal review process was streamlined and partially automated.The application consisted of three major functional components:
  1.  A central, relational database for storing Principal review data
  2. A user interface to maintain/view Principal data and access supplemental documentation online
  3. Standardized, automated reports using real-time data

The Rapid Application Development (RAD) Challenge

The team had only 2.5 months to design, develop and implement an application that addressed the essential business requirements. Since the review meeting for the current cycle could not be rescheduled, there was no flexibility in the project timeline. The project plan had to be properly structured to ensure that the application could be developed by the target date while still delivering a quality product with the required functionality.

The Rapid Application Development Process

Several elements were critical in ensuring the success of the RAD process as described below:

Well-defined project scope

Functional requirements were clearly defined in a statement of work and agreed upon by both parties. The statement of work provided boundaries, which prevented scope creep and assisted in the creation of a precise project plan thus ensuring the timely delivery of the application.

Clear definition of roles and responsibilities

Roles and responsibilities were determined before the initiation of the project. This prevented confusion as to who was the “decision-maker”, functional expert, developer, project manager, etc.

Small and empowered core project team

Because the core project team was limited to a developer/analyst and functional expert (client), minimal effort was expended on defining business needs and resolving issues. In addition, the functional expert was empowered to make all final decisions which further expedited the decision making process.

Simple application architecture

Because the client did not have a clear vision of how the application would be leveraged in the future, the initial application was created as a working prototype from which additional requirements could be determined. Consequently, the selection of a simple application architecture ensured that the data captured within the Microsoft Access database could easily be transferred to a larger scaled, more permanent solution.

Efficient development

The project plan was designed so that the application was developed in overlapping phases by functional component. This compressed development approach minimized lag time between tasks for a given project team member. The overlapping of phases also facilitated the development process by allowing continuous progress of the project in at least one phase even if there was a bottleneck in another and by providing some flexibility in timeline if certain tasks required more hours than originally estimated.