The OIT Project Management Framework is an important guideline to use when embarking on a software development project or implementing third-party solutions. It represents set of guidelines and steps to help you navigate through the project management life cycle in OIT to deliver a successful project outcome.
The guidelines described here is meant to adapt to any project by tailoring the steps, processes, and procedures to meet specific needs of a project. For more information, see Tailoring the SDLC. An overview diagram of the entire process can be downloaded in PDF or Microsoft Visio 2010 format.
| Process | What To Do | How To Do It |
|---|
| 1 | Initiate the Project | - If you are using a workflow-based project management tool (e.g., JIRA) then set up a document template to track approvals and completion of tasks.
- If you are not using a project management tool then use one of the following checklists as appropriate based on initial assumptions about the project:
- Project Sign-Off Sheet for Developed Applications
- Project Sign-Off Sheet for Third-Party Applications
|
| 3.5 | Identify Sponsor | - Identify a person who will take ownership of the project and:
- is in a position where he or she can organize resources from the functional side.
- has the skills and time to manage or help manage the project, including requirements analysis, tracking progress, setting up meetings, and organize user testing
- has the time and interest to develop the skills required to assist requirements analysis.
|
| 3 | Submit Project Proposal | - Prepare a Project Proposal request and submit the request as defined on the How to Submit a New Project page.
- To aid in determining what should be included in the Financial Impact section of the Project Proposal, download and use the Project Impact Analysis or High-Level Cost Benefit Analysis workbooks.
- If a third-party solution is an option to complete the project then prepare a Third-Party System Review for each of the third-party systems being considered.
- If you will be using JIRA to manage your project then you should submit a new JIRA Project Request as soon as possible after submitting the project proposal to the Project Review Team. If you are using some other tool to manage your project (e.g., MS Project, SmartSheets, ServiceNow) you should initialize the required project information there.
- Prepare Project Information Home and Project Decision Log wiki pages to publish information and updates about the project.
|
| 4 | Requirements Definition | - Consider candidates for the various roles on the Project Team. Assign as many of these as possible.
- Create the Project Charter for large, high risk applications.
- Prepare the Functional Requirements to document the basic functional requirements of the system.
- Use the results from the Third-Party System Reviews to help determine whether an application software solution should be developed internally or acquired from a third-party.
- The general guideline is that if a third-party solution providing at least 85% of the features and capabilities outlined in the Functional Requirements can be located, and it satisfies the technical criteria defined by OIT with respect to architecture, security, etc., then the third-party solution should be used.
- If multiple third-party solutions are being considered, a Third-Party System Review should be done for each one.
- Review the OIT Data Classifications to determine whether the project involves access to to sensitive, restricted, or personally identifiable information.
- If it does then contact the OIT Security Manager.
- Security reviews are best scheduled starting at the planning stages of a project and are required during the requirements definition process of any high risk project.
- Determine the level of risk involved with the project.
- Complete Sections I - X of the Security Risk Assessment Questionnaire (SRAQ) to calculate the project's risk level.
- A HIGH RISK application includes any application that uses, stores, or transmits:
- Password
- Social Security Number
- Home phone or address
- Credit card numbers
- Bank account numbers
- Driver license or other credential
- Nonpublic student or employee data
- FERPA-protected student data
- Patient information
- Or any other data deemed sensitive, restricted, or personally identifiable as defined in the OIT data classifications.
- If restricted information is stored or accessed:
- Encryption must be used in storage and transmission in all cases where such data occurs.
- The project is categorized as HIGH RISK and the UCI CIO and UCI Security Officer must be notified in writing or acknowledged email before any work effort begins.
- Contact the OIT Security Manager at the planning stages of high risk projects to review the SRAQ and security requirements of the project.
- Use the Audit Preparation Questionnaire to determine what information will be required if the project or system is audited.
- Schedule a requirements review and acceptance sign-off with functional and technical project teams to review the functional requirements.
- Prior to reviewing the requirements with the project team, it may be helpful to create a Development Environment Review Form.
|
| 5 | Prepare a Project Plan | - A Project Plan contains enough information about the project that all stakeholders can understand what will be done and have an idea when the work will be completed. This includes:
- Project Definition containing basic information about the project,
- Schedule showing project milestones and projected resource requirements and timeframes,
- Issues Log to keep track of potential and real problems encountered during the course of the project, and
- Organizational Information including key stakeholders, roles, and contact information.
|
| 6 | Create System Specification | - Especially for more complex systems, as you design your specifications, be sure to consider:
- Architecture Review
- Database Review
- GUI Review and consistency
- When creating diagrams (data flow, system architecture, system design, etc.) that show interaction between software components only use the tools defined in the Application Developer's Toolbox.
- At minimum separate development and production environments must be set up. You may also need a test, training, or staging environment.
- Create test data if any sensitive data will need to be tested.
- Schedule regular security reviews with the Security Team at the beginning of your project.
- System Architecture Diagrams in SRAQ Section XI should be completed and reviewed.
- Complete the Threat Anaylsis section of SRAQ based on technical details of design.
|
| 7 | Prepare a Test Plan | - A Test Plan consists of:
- Automated code testing in your development environment
- Cross-browser application certification using VMWare
- Steps to test major areas of functionality. Include screen shots for regression testing.
- Security tests as outlined in the SRAQ.
- Accessibility test (WCAG 2.0 as guideline)
- Parallel system test
- Test schedule
- User acceptance checklists
|
| 8 | Software Implementation | In House- Application development is an iterative process with regularly scheduled review stages and quality controls.
- Contact your systems development director about the preferred development platform, tools, and methods.
- For more information about OIT software development practices, see Systems Development Practices & Guidelines.
- The Application Developer's Toolbox provides useful information about OIT-supported tools for the developer.
- During implementation, the Section XII (Controls) of the SRAQ must be completed. (OIT recommendations)
- Schedule Application and Code Review.
- The /wiki/spaces/adcom/pages/68028495 should be followed during implementation.
- High risk code, such as authentication and authorization, must be reviewed in the early stages of implementation.
- Schedule Code Reviews with peer software engineers from the beginning of development.
Vendor- Vendor procured software involves software configuration activities rather than software coding.
- Vendor procured software are designed and developed to meet the needs across a broad client base. As such, current functionality and processes will need to be evaluated against the framework and confines of the vendor software.
- This will require mapping all critical processes to the software's functionality. If the critical process cannot be accommodated by the software, it may require UCI developed application to close any gaps for the mission critical process that cannot be met by the vendor procured software.
- Vendor should help guide the process during the implementation. As such, they should provide a project plan and a project schedule that outlines how the implementation will unfold. In the absence of a formal project plan by the vendor, you will need to collaborate with the vendor to prepare the project plan and the project schedule per Step 5 above.
- During implementation, the Section XII (Controls) of the SRAQ must be completed. (OIT recommendations)
- During the Project Execution Phase, all project tasks must be updated on a regular basis to determine risk and issues that prevent the project tasks from moving forward and communicated to appropriate parties.
- Once the vendor procured software has been implemented, validate the deliverables against contractual obligations.
|
| 9 | Quality Assurance | - QA is an iterative set of activities during development of a project and is normally based on a documented process and standard practices. These include:
- Code analysis with automated tools and peer code reviews. Example: Java Code Review Checklist.
- Unit, Functional, and browser compatibility testing by programmer and end user.
- Security review in the form of verification of SRAQ Controls Section XII and OIT Application Security Checklist.
- IT Accessibility testing completed
- Performance, load, and stress testing to simulate user load.
- Reporting and publishing of test results to determine progress and production readiness.
- See an example of Java Quality Assurance process.
- Reference links:
|
| 10 | User Acceptance Testing | - User Acceptance Test and Acceptance Sign-off is usually coordinated by a Functional Lead and indicates that users have:
- Tested functionality,
- Approved that an application meets original requirements, and
- Determined that it is ready to go into production from the business perspective.
|
| 11 | Production Rollout Planning | - Production Rollout Planning includes:
- SRAQ completed fully with any left over action items completed.
- Successful quality assurance testing, application vulnerability scanning, and security sign-off.
- Completed Project Sign-Off Sheet (Third-Party or Developed Application version as appropriate for the project) with approvals and dates.
- For some OIT functional units, issue tracking and Change Control Management must be worked out with the appropriate OIT support units prior to moving the system to production.
- Scheduled database and code backups.
- Appropriate contingency plan or roll-back plans.
- Announcement of the application's availability date to end users via appropriate communication channels.
- User Training.
- Help Desk training.
- Cross-train backup support.
- Adding the application into Help Desk Service Request Tracking System.
- Adding application to campus portals, if applicable.
|
| 12 | Launch Application | - Congratulate yourself on a job well done!
- Continue with change management and production support.
|
| 13 | Post-Implementation Review | - Perform project close-out including clean-up and lessons learned.
- Transition support from developers to OIT Help Desk.
- Prepare a Project Completion Report for review with end users.
- Meet with end users and project team to review Project Completion Report.
- Meet with Executive Sponsor to obtain sign-off of the Project Sign-Off Sheet.
- Email Project Sign-Off Sheet to the OIT Project Manager.
- Prepare system disposition plans.
- Monitor system to make sure it is performing as designed.
|
Waterfall vs Scrum
Both Waterfall and Scrum are widely used methodologies for different reasons. Although most projects adopt one methodology over the other, the non-traditional hybrid method of using parts of each methodology can also be effective in arriving at the desired project outcome. Table below provides some characteristics of both Waterfall and Scrum. Detailed information on each methodologies tailored for OIT can be found in the following links.
| | Waterfall | Scrum |
|---|
| Fundamental Assumptions | Systems are fully specifiable, predictable, and can be build through meticulous and extensive planning. | High-quality, adaptive software can be developed by small teams using principles of continuous design improvement and testing based on rapid feedback and change. |
| Control | Predictive: decisions are based on forecasts | Empirical: decisions are based on realities you observe in the actual project |
| Management Style | Command-and-control (amber organizations) | Leadership-and-collaboration (orange and green organizations) |
| Knowledge Management | Explicit | Tacit |
| Role Assignment | Individual - favors specialization | Self-organizing teams - encourages role interchangeability |
| Communication | Formal and documented | Frequent and facilitated |
| Customer's Role | Important | Critical |
| Organization of Work | Guided by architectural level and tasks (vertical slices by architectural level) | Guided by product features (horizontal slices through each architectural layer) |
| Development Model | Life cycle model | Evolutionary/Incremental delivery model |
| Desired Organizational Structure | Mechanistic (bureaucratic with high formalization) | Organic (flexible and participative, encouraging interpersonal interactions) |
When to Use Waterfall and When to Use Scrum
We recommend using Waterfall if:
- Customers know exactly what they want in advance and will not change their mind
- You know exactly what your customers want
- You know that users will have no concerns with your initial design
- Any feedback from users is either addressed in a subsequent project or not at all
- You’re working with fixed-price / fixed-bid contracts
- The project is very predictable or you’ve done similar projects many times before
- You’re working with fixed scope unchanging projects
- You anticipate only minor mistakes throughout the project
And you should use Scrum if:
- Your customer does not know exactly what they want at first or could change their mind
- You don't always know exactly what your customers want or they're needs aren't always communicated perfectly
- Your users provide feedback on your design and you'd like to act on it
- You prefer to address user feedback during the project instead of after
- The final product isn’t clearly defined at first or the definition may change
- You anticipate there will be changes in scope, requirements, opinions, priority, environment, people, or technology during the project
- Some part of the project is different or is of moderate complexity
- You want the option of closing a project early once sufficient value is created (avoiding "everything but the kitchen sink" pitfall)
When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.