Introduction
This article describes a standard process to implement CPMS-NextGen features.
Bypassing the process might lead to more work for everyone involved. For example, if the design phase is skipped, the developer might misunderstand the user’s needs and develop the wrong features. If the testing phase is skipped, a low quality feature might be delivered to users and the maintenance might become very difficult.
Note: This article does not outline the prioritizing features in the NextGen’s backlog.
Release Types
Due to the varying types of releases, not all releases will go through the same implementation cycle. Below is a list of definitions that will be used to identify the steps needed in each phase.
Major Release – Any new or improved feature that requires input from multiple stakeholders and extensive beta testing including user training. (ex. bid packager builder implementation, budget tab refractory)
Minor Release – Any improvement that only requires CPMS NextGen team input and an email to update users of change. (ex. addition of a button linking RPM, removal of a drop-down)
Implementation Phases
Notes: In Phase 1~5, the steps which are highlighted with * are optional for Minor Release.
| | |
|---|
Phase 1 | Requirement Analysis | This phase focuses on determining the requirements for the new/altered features. It might include the following steps. * Gather background information about the users and the existing features. May be helpful to understand the reason for the original implementation. If this is a development for new features, need to analyze the similar processes which currently take place. * Identify user needs by interviewing subject matter experts (SMEs) and other stakeholders. Especially need to understand the scenarios how the new/altered features will be used in the future - i.e. use cases. Make sure to evaluate the entire workflow and users involved and how any changes would work in practice. * Evaluate, refine and prioritize user feedback within the NextGen team. * Might need several iterations for Step 2 and 3. Document the requirements specification in JIRA (can include Confluence, SharePoint or Smartsheet attachments when necessary). The documentation shall include function mappings between user needs and NexGen features, prioritization, visualization mock-up.
|
Phase 2 | Design & Wireframing | This phase designs all the interface elements along with the entire process workflow in concept. * Select the technologies for implementation. Need to test the feasibility of using the selected technologies. * Create a workflow diagram describing the user communications and data flow. * Create a wireframe which demonstrates how the interface elements will look and work. Review the wireframe with SMEs or other necessary users. Only involve as few people as sufficiently needed. * Might need several iterations for Step 2 and 3. * Obtain the sign-off on the design.
|
Phase 3 | Development | The actual development starts from this phase. During the development phase, the NextGen team might raise additional questions and improvements - which need some discussions with other non-NexGen team members. Develop features Raise questions/issues and discuss solutions Test features Need a lot of iterations for Step 1, 2 and 3 Release an Alpha version after the features are accepted by the NextGen team
|
Phase 4 | Testing | The testing activities are involved in all the phases of the entire implementation cycle. This phase refers to the testing stage after an Alpha version is deployed to the development environment (e.g. dev box, testing workspace). Review and test the Alpha version by the NextGen team Fix minor issues or repeat Phase 3 as needed Release a Beta version Review and test the Beta version by SMEs or other necessary users Fix minor issues or repeat Phase 3 as needed Obtain the feature acceptance from testing users * Plan and schedule post-deployment tasks 1 Sprint before Phase 4 completion Coordinate with T&D to schedule a CPMS training. (Goal is to have a training within 48 hours of deployment) Notification sent to target audience to introduce the upcoming implementation and highlight key features.
|
Phase 5 | Deployment | The goal of this phase is to deploy the new/altered features to the production environment so all the users can start using the features. Throughout this phase, more questions might be raised. Sometimes it can be really frustrating for the NextGen team - since users will not know what they really want until they start using the features for their daily work. Release the accepted features to production * Complete and publish help guide Send out notification to target audience to confirm deployment
|
Phase 6 | Post-Deployment | Major Release Conduct Training If this is a replacement feature, disconnect the old feature to force adoption of the new one (Only disconnect once a training has been conducted) Direct users to provide feedback using the feedback form Evaluate and prioritize feedback based on the validity and timing needed to implement prioritized feedback
Follow up with identified SMEs and any other necessary users 30-60 days following deployment to make sure that feature is working properly and being adopted
Minor Release Direct users to provide feedback using the feedback form Evaluate and prioritize feedback based on the validity and timing needed to implement prioritized feedback Follow up with identified SMEs 30-60 days following deployment to make sure that feature is working properly and being adopted
|
SOP Diagram