Five Phases of SemGov
From DocWiki
This Semantic Government offering, with its emphasis on Community Indicator Systems (CIS), is structured into five phases. (These are largely modeled on the 5 Phases of MIKE2.0 but also differ in substantial respects.)
In contrast to the traditional linear or waterfall approach to systems development, the SemGov phasing adopts an iterative approach called continuous implementation. This approach divides the development and rollout of the entire system into a series of implementation cycles, which identify and prioritize the portions of the system that can be constructed and rolled out before the entire system is complete. Each cycle also includes a feedback step to evaluate and set priorities for subsequent implementation cycles.
Thus, here are the phases to the SemGov methodology:
- Phase 1 - Assessment and Strategy Blueprint
- Phase 2 - Initial Standup and Proof-of-Concept
- Phase 3 - First Public Release
- Phase 4 - Next Activities Increment
- Phase 5 - Continuous Improvement
These phases are summarized below. They are presented in more detail (along with underlying activities in tasks) in the Overall Task List of the Overall Implementation Guide.
| Overall Content Model |
| Activity Relationship |
Strategy and Proof-test
The first two phases set out the overall development plan and stand-up a first proof-of-concept. This approach ensures the deployment is responsive and that comfort is first built before major commitments. This approach thus also helps minimize risk and to bound efforts within available budgets.
Phase 1 - Assessment
The Phase 1 assessment is often rather short in duration. If undertaken with a consultant or contractor, it is also the opportunity for all parties to understand needs and expectations.
The assessment relies heavily on the structure and content of this DocWiki, subject to close consultation and discussion with the owner. Expectations, technical requirements, functional requirements and desires, personnel, other stakeholders, and budgets and timelines are inspected and combined into an overall plan.
That plan may or may not conform exactly to the specific phasing herein. Also, depending on that assessment, new development and requirements might also emerge.
The net result of this assessment phase is to develop an overall plan and budget for subsequent phases. By necessity, the detail and precision is higher in earlier phases, less in later ones. In addition, multiple increments over later phases may also be defined.
Much of what is contained on this DocWiki provides a general outline and content for what such a plan might include. A key aspect of the implementation that begins in the next phase is to update and modify this DocWiki based on the specific plan at hand.
Phase 2 - Proof-of-Concept
Phase 2 is the first implementation phase. The result of Phase 2 is a stood up "proof-of-concept" with sufficient functionality and content scope to enable a decision to proceed with a full implementation and later phases to be made with confidence.
To lower risk and cost, items which are inherently low risk (such as large scope of content, etc.) are purposefully deferred from this phase. Rather, the emphasis is on demonstrated indicative functionality and scope sufficient for stakeholders to evaluate and make commitment decisions for full deployment. In essence, then, this phase acts to "put most of the major pieces into the box" without undue effort or expenditures not directly useful to go-no go decisions.
Major structural changes are also made to the DocWiki sufficient to explain to stakeholders pending next steps.
Continuous Implementation
The continuous, spiral development approach is captured by Phases 3 to 5. Phases 4 and 5 represent ongoing expansion or incremental change to the deployment, followed by testing and continuous improvement in systems and documentation. Each of these iterations may be undertaken multiple times, depending on the longevity and ultimate desired scope of the deployment.
This Continuous Implementation concept is central to the SemGov implementation approach. This concept provides an opportunity to divide the project team into groups organized by implementation activity, specializing on a specific implementation role. As the implementation process iterates through the implementation cycles, the processes and skills of each implementation activity team are refined, enabling the activity team to improve quality and reduce cycle time. Implementation activities also provide a mechanism for establishing a continuous system enhancement and feedback process for the client when the initial implementation team is no longer involved in the project.
If done properly, information management environments are never ’complete’. Each cycle also includes a feedback step to evaluate and prioritize the implementation results, strategy changes and improvement requests on the future implementation cycles.
Phase 3 - First Public Release
The first incremental release with generally complete functionality is Phase 3, the first public release. As such, the result of this phase should be sufficient for a public capability of some longevity, even should later increments not be undertaken.
Phase 3 can be generally understood to correspond to the "baseline" system, and should be defined as such. New or risky developments or changes should generally be considered as more appropriate to Phase 4.
Phase 4 - Next Activities Increment
Phase 4 is rather open-ended, since it represents one or more "next" increments of functionality and design. The actual development and deployment activity is included in this phase. Phase 4 may also consist of multiple increments over the deployment's lifetime, as new updates or revisions to the installation are deemed appropriate.
Often, none or only one Phase 4 increment might be included in initial budgeting. Subsequent Phase 4 increments may be decided upon and budgeted for at any time.
Generally, new developments beyond the "baseline" system are accommodated for in this phase.
Phase 5 - Continuous Improvement
Testing and ongoing improvements in operation, use and documentation occur in Phase 5. Phase 5 also represents the beginning of the feedback cycle, one which might trigger the initiation of a new increment (thus another Phase 4).
Any of variety of use and improvement factors might trigger the need for updates, revisions or new developments to the current installation. This is also the point at which methods and processes may be identified for revision and improvement.
At the end of the deployment's useful life project closeout also occurs. That activity also belongs to this phase, but is only undertaken upon the close of the last installation increment.
