System Life Cycle Stewardship

A Simple, Scalable Approach to (IT) System Management

Introduction

The VP of Sales has a mandate to revamp the sales strategy and the existing CRM just won’t handle the new business processes. The office phone system is a decade old, out of warranty, and replacement parts are hard to find. The adoption of e-signatures has finally reached a critical mass where it now seems possible to retire the fax gateway and the whole fleet of stand-alone fax machines.

All of those scenarios call out for system changes: Either new, enhanced, replaced, or retired systems. Whether it be driven by top-down changing organizational needs driving business process modification driving service definition changes, or by bottom-up forces like wear and tear degrading existing systems that support current services or the availability of new technologies that threaten to obsolete current systems and disrupt the services and business processes that developed around their capabilities, system changes are inevitable.

Effective execution of that change depends on many factors. System Life cycle Stewardship is a simple framework for system design & implementation to produce sound, sustainable systems that can be scaled to degree of change contemplated.

Overview

The system life cycle consists of the following seven phases, six of which constitute the primary loop (Concept-Concept), with the seventh phase (Review) providing a meta-level opportunity for improving the framework itself:

• Concept [New]
• Assessment
• Design
• Development
• Deployment
• Operation
• Concept [Enhancement | Replacement | Retirement]
• Review

The following sections describe each of these phases in turn. While they are presented as discrete, sequential steps—like the phases of the similar, classic “waterfall” system development life cycle—this is an idealization. The reality of their execution almost always entails a much more agile approach that allows passing forward and back between partially-completed stages iteratively to successively refine the deliverables described at each stage. These sub-loops are called out by the dotted line from Development back to Design in the diagram above. While an iterative sub-loop between Development and Design is very common, it is not the only one possible. As with the many paths between the looser modes of the design thinking process, dotted line relationships may exist between nearly any of these lifecycle phases, allowing for learning from one partially-completed phase to inform the further elaboration or redefinition of the work of a previous partially-completed phase within a single primary system life cycle.

Concept

Description

The concept phase is typically the least structured in most contexts, especially for new ideas. Some unmet need is identified or some new solution spied. A fuzzy definition of the problem or opportunity is advanced within the organization. This is followed by informal conversations, brainstorming, informal identification of alternatives until some level of consensus on the value and feasibility of moving ahead is reached and an actor in the organization with authority or initiative takes the decision to proceed to a more formal assessment.

Tasks

• Need identified
• Fuzzy definition of problem
• Informal conversations
• Informal alternatives
• Prima facie feasibility
• Decision to assess

Assessment

Description

Assessment, or feasibility, is the go/no go decision phase, with the ideal deliverable being a written Assessment document commensurate with the complexity of the issue being addressed. Such an Assessment includes background context and history for the issue being addressed with the proposed system. Under the guidance of student and staff stakeholders, the assessment establishes a shared definition of a problem/opportunity for the application of technology and develops a shared vision of the specific, measurable outcome from a solution as well as a shared understanding of the broad functional requirements of a solution to the problem/opportunity.

The assessment outlines brainstormed solutions to the problem/opportunity and presents a critical analysis of and comparison matrices for these potential solutions based on the specified requirements and objectives. As necessary, a cost/benefit analysis, feature comparison, sustainability analysis, and risk assessment are included, culminating in the recommendation of the best-fit solution.

System Life Cycle Stewardship: Assessment 

Finally, the Assessment includes a management plan outlining the top-level tasks and key participants for the project plan, defines shared standards for project implementation and reporting and summarizes the selection decision made by stakeholders. A fully articulated Assessment table of contents might include:

1. Summary
2. Opportunity
   1. Background
   2. Stakeholders
   3. Identified Needs
3. Outcome
4. Objective
5. Process
6. Objectives
7. Alternatives
8. Analysis
9. Recommendation
10. Management Plan
11. Document Control

Tasks

1. Research Issues
   1. Conduct Background Research
   2. Identify Stakeholders
   3. Seek Input From stakeholders
   4. Identify Alternatives
   5. …
2. Conduct Assessment
   1. Write Assessment Document
   2. Revise Assessment Document
3. Approval

Design

Description

The Design phase takes the problem/opportunity and recommended alternative from the Assessment phase and generates a detailed design. The ideal deliverable is a Design document which reviews the problem statement, objectives, and functional requirements developed during the Assessment phase and extends them with the detailed technical specifications for implementing new system.

The Design document may also includes supplementary sections including: a documentation plan outlining the documentation needed for development, installation, operation, maintenance, and disaster recovery of system; an integration plan outlining changes required in existing systems, policies, and procedures with a plan for migration, training, and service cut-over; a test plan with criteria for testing system and interfaces; a training plan detailing orientation, training, and support classes and resources needed for users of system; and operation & maintenance plan which assigns, and schedules recurring system performance monitoring and maintenance duties, outlining regular reporting and assessment intervals and system performance benchmarks; a lifespan plan which projects the lifespan of the system, potential enhancements, and potential replacement timeframe, and of course an overall implementation project plan for scheduling development, testing, implementation, and integration. The Design document table of contents might include:

1. Opportunity Statement
2. Outcome
3. Requirements
4. Detailed Design
5. Development Plan
6. Documentation Plan
7. Test Plan
8. Integration & Training Plan
9. Maintenance Plan
10. Lifespan Plan

When the design is clear, stakeholders and management then commit to the system design and project management standards and begin Development.

Tasks

1. Generate Design
2. Write Design Document or RFP
3. Revise Design Document or RFP
4. Acceptance by Approval Authority

Development

Description

Development implements the Design. Resources are allocated—personnel are assigned and equipment purchased as needed—so that the specifications from design phase get carried out. All documentation is written and training designed. Testing occurs and stakeholders accept the system as meeting the requirements they set out.

Tasks

1. Development Plan Tasks
2. Documentation Plan Tasks
3. Test Plan Tasks
4. Acceptance by Approval Authority

Deployment

Description

Deployment brings the new system to its users. With stakeholders and management, training and installation tasks of migration and cut-over are scheduled, and the system moves into production. Final production environment tests run and users are trained on system operation, policy and procedure changes.

Tasks

1. Integration & Training Plan Tasks
2. Post-Installation Testing

Review

Description

Review closes out the start-up/implementation phase of the system, allowing the project team to close-out business and assess the success of the project, making methodology enhancements for the next project.

Tasks

1. Assess Project with Stakeholders
2. Revise Methodology as Necessary
3. Celebrate!

Operation

Description

This phase includes normal administration of system along with the regular maintenance tasks as outlined in Maintenance Plan. Maintenance staff monitors system performance, maintenance, and repairs, as outlined in Maintenance Plan, preparing regular reports and conducting regular assessments so that the system can continue to serve the needs of its users. Support staff respond to user needs, providing troubleshooting, assistance, and training, as needed, while tracking and reporting incidents on a regular basis. Finally, in case of disaster, the system must be recovered, so the Maintenance Plan should include regular regular recovery tests.

Concept

The completion of the Operation phase for a given system gives rise to another cycle through the entire process (though perhaps with less detail, depending on the new context) through one of the following paths: Enhancement, Replacement, or Retirement.

Enhancement

All systems evolve as their environment changes. During the life of a system, follow a process of continuous improvement. Track all requests for system modification and conduct a cost/benefit/risk analysis commensurate with degree of change to determine whether to implement requested modification. Recapitulate the system life cycle to a level of rigor required to produce a design of modifications to system then make and test modifications to system. Finally, put the changes in place, testing in production environment.

Replacement

System replacement can be required either when the existing system has reached the end of its reliable and performant lifespan or when the organization’s needs have changed dramatically enough for incremental enhancement of the existing systems to be infeasible. In these cases, begin the cycle over again, taking the existing system as the context for integration and cut-over.

Retirement

Sometimes the organization’s business processes change so dramatically that that existing systems are simply no longer needed, even without direct replacement. In these cases, recapitulate the system life cycle to a level of rigor required to plan how to phase-out the existing system cleanly. Celebrate the simplification!

What frameworks and practices have you found useful in managing your system lifecycle?
Tag TaskTrain on LinkedIn, Facebook, Instagram, or Twitter to let us know!