10.15 Alternative Work Pattern Descriptions

---

The subsequent sections provide descriptions for each alternative work pattern, including tasks and activities, required deliverables, and reviews for each relevant phase. Deliverables for alternative work patterns are often created, revised, and finalized across multiple life cycle phases, as with the full sequential work pattern.

Reduced-Effort (Small Application Development) Work Pattern

A reduced-effort work pattern combines some phases, eliminates some of the deliverables otherwise required, and combines some of the reviews to reduce project formality in those situations where a conservative approach is not necessary.

Rapid Application Development (RAD) Work Pattern

In the RAD work pattern, the Initiation and Planning phases are conducted according to the full sequential work pattern. The Requirements Analysis and Design phases are iteratively conducted, using prototyping tools to rough out and incrementally improve the understanding of requirements through a series of design prototypes. The Functional Requirements Document and the System Design Document are started at the beginning of this activity, but are not completed until the end of the Design phase; these documents use, as much as is possible, the outputs of the prototyping tool to create this documentation. In the process, an initial set of requirements is used to create an initial version of the application, giving users visibility into the look, feel, and navigation capabilities of the application. User evaluation and feedback provide revisions to the statements of requirements, and the process is repeated—always involving the user.

Typically, three cycle iterations will result in a completely understood set of requirements, but the iteration process can continue until successive differences in requirements are so small as not to be noticeable. Following the completion of design prototyping, a full sequential work pattern is again engaged to accomplish the Development, Integration, Test, and Implementation phases. The only deviation is the possibility of using some of the generated code from the design prototype to start the development process.

Pilot Development Work Pattern

In a pilot development work pattern, either a full sequential work pattern or a RAD work pattern is used to go from the Initiation through the Development phases. Decisions regarding full deployment of the application are held until after field trials and evaluations have proven the concept because of the risk involved in the complexity, visibility, and uncertainty of the project. The field trials and evaluations accomplish portions of user acceptance testing and implementation; after they are complete, possibly requiring one or more years, the remainder of implementation is completed. This means that migration to the Support phase is possibly deferred for more than a year.

Managed Evolutionary Development (MED) Work Pattern

The U.S. Patent and Trademark Office developed and documented the MED methodology[16]. The MED approach is particularly suited to situations where existing business processes will be altered considerably and where the full set of detailed functional requirements cannot be reliably defined early in the development life cycle. The MED discipline supports iterative definition, development, and deployment of subsystems by defining system-level functional and data requirements and a modular system architecture, which allows for subsequent refinement, development, and deployment of subsystems that can evolve to meet future business needs. A particular release level containing partial, but incomplete, functionality is often referred to as a build. During the Planning and Requirements Analysis phases, an entire series of successive builds is planned, each of which gets designed, developed, tested, and implemented.

MED Incremental and Evolutionary Strategies. The MED-based development process combines an evolutionary development strategy with incremental delivery. System development using MED proceeds by defining a bounded vision of a future system and then iteratively refining the reengineered business processes, information system requirements, and technical architecture. The incremental delivery strategy within MED is used to encapsulate part of the overall system as a subsystem to be built and deployed. Subsystems are constructed when there is sufficient confidence that they will provide a cohesive, user-validated set of business functionalities. As usage experience is obtained, lessons learned are fed back into each subsystem, improving each in subsequent versions of the system.

MED Program Management. The Planning phase is where the Project Manager, with approval of the sponsor, determines that the functional requirements will best be fulfilled by assigning them to distinct, but functionally related, subsystems. The Requirements Analysis phase will be split into a Systems Requirements Analysis phase to define overall system requirements and architecture and a Subsystem Requirements Analysis phase for detailed definition of each subsystem. At the completion of the Requirements Analysis phase, each subsystem begins its own branch of the life cycle to define a target subsystem architecture, business process, and requirements.

Risk Management within the Context of MED. The order in which a MED-based work pattern proceeds is heavily influenced by risk. MED is designed to focus explicitly on the development decisions around risk derived from uncertainty about the target system in the areas of business process, system requirements, technical architecture, cost, and schedule. This risk management strategy addresses two fundamental time-related risks of uncertainty and dependence. Uncertainty is reduced by acting on gathered information, such as from prototypes, simulations, studies, or models; dependence is eliminated by structuring parts of the system to be independently deployed as subsystems. To accomplish this goal, the Project Manager must define the target system. This consists of determining the system boundaries, specifying the target characteristics, assessing system risks and defining and executing risk mitigation activities, and developing subsystems, which is done as a project within the overall program. Projects are initiated once system-level risk is reduced to an acceptable level as documented in the risk management plan.

Reviews and Approvals. When using the MED work pattern, there is an explicit milestone for the system-level requirements and a milestone for each subsystem requirement.

Operations and Maintenance (O&M) Small-Scale Enhancement Work Pattern

This work pattern is appropriate for small-scale revisions to existing applications. Each O&M enhancement must be initiated by the Project Initiation Form and submitted to the SPMO. Typically, multiple O&M enhancements will be bundled into a planned software release identified by a version number. The intent is to limit the use of this work pattern to simple, small-scale changes that will require no more than 160 (suggested) labor hours for the total effort, including any needed updates to product documentation and any required user training.

O&M Project Work Pattern

This work pattern is appropriate for ongoing maintenance of existing applications. Each project must be specifically organized and staffed to conduct corrective, adaptive, or perfective maintenance on installed applications, including conversions needed to support upgrades and/or changes to the hardware and software operating environment. User Help Desk support and other small enhancements may also be provided and delivered by the assigned project team. System revisions and conversions will be accomplished on an as-needed basis at a fixed level of support and within a corresponding fixed annual operating budget. The intent is to limit the use of this work pattern to ongoing support activities that typically do not fit within the definition of a systems development or enhancement project.

Procurement of Commercial Off-the-Shelf Products

This effort is designed for the purchase of COTS products to be used in SEP within the framework of existing or planned systems. These COTS products may be used at a single site, or they may be installed to operate across the organization or a significant portion thereof.

Additional Work Patterns

Project teams should endeavor to follow the full sequential work pattern or one of the alternatives described; however, from time to time, new project environments or system requirements into which these work patterns will not fit will evolve. In those cases, the Project Manager, working with the Core Team, should develop and document proposed new work patterns, submit them as updates to the SPMO to be documented, and use them as the basis of the future project management plans.

---