Project Definition

The Project Manager is responsible for defining the scope and objectives of the project in direct communication with the Business Process Owner and the project team. The requirements of the project are documented and stakeholders are identified. Once resources are identified and a general schedule is determined the project planning can begin.

Project Kickoff Meeting

Once a project has been assigned to a development Project Team, they will schedule a meeting with the other teams that will be impacted by the project to discuss the high-level requirements of the project, timeframe and any details that might be available at the time. Typically, these are short meetings to ensure that the resources can and will be made available to the project team or to arrange a better timeframe for the project if it is determined that teams are not available due to other previously scheduled projects or priority. Project Managers and delegated staff can make the new project a Priority by using this site (Projects->Status->Project Details). Each Project Manager can set the priority of all of their projects. Likewise, each AD can set the priority of all the projects being run under their teams. Finally, the EAS Director can set the overall project priority from the entire EAS perspective. If DBA tasks are expected for a new EAS project, then a new project-name is added to the HDRTi Request Types at this time.

Project Planning

The Project Manager will create and maintain the overall Project Plan where milestones are defined and resource names are identified for deliverables. The Plan ensures that all business requirements are met. Regularly scheduled Project status meetings are held by the Project Manager to keep the entire team updated on progress and any adjustments that are needed to the plan. Action items and issue logs are commonly maintained during these meetings.

Proposed Database Changes (IMS and Oracle)

After the development team has had a chance to scrutinize the new requirements for the project, they will schedule a meeting with DBA to discuss any proposed changes to the existing data-model (if any). During this meeting, DBA will likely ask several questions about the design of the application, the data-flow, sizing, data-retention, etc. The project teams complete a worksheet (new/changed table proposal document) which helps to answer typical questions that the DBA needs to determine to prepare for any physical object creation. The DBA will review the proposed modifications and provide input as well as a timeframe of when the changes could be implemented into the Tier-III (Development) environment. DBA will file all changes associated with this project into their project deployment documents. If subsequent changes are proposed during the project, the development team will use the project's "Request Type" within HDRTi to communicate to DBA that the changes being requested are part of an ongoing project. This keeps all of the DBA-related artifacts together to ensure a smooth deployment to the next tier. The Project Manager will be keep the team updated by holding regular status meetings where changes to the plan are discussed. Since production target dates can slide a bit from their original date, it is important to keep all teams that are required for implementation updated since other projects may already be scheduled for the new target date desired.

Impact Analysis

Once it has been determined that there will be changes to an existing data-model, an impact analysis needs to be performed by the Development Project Team. In this analysis, any existing data-elements that are changing are scanned within the source-code to determine where it is used. These scans take place within Librarian for Mainframe applications and CVS for java/plsql applications. If the data-elements span both IMS and Oracle environments, then the data-elements need to be searched for within both source code repositories. This analysis is crucial to the success of the project in order to determine where and how a given data-element is currently being used prior to it being changed for the new project. If the application team fails to perform this work, it will not have a good handle on what systems and modules need to be changed and tested. It is very likely that other programs and/or processes will also require a change in order to satisfy new changes for the new project. The impact analysis results will be used to compile a listing of all of the programs and processes that may require a change and/or will be required to be tested before changes can be deployment to the next Tier.

Code/Process modifications & testing

After an impact analysis has been completed, coding changes can begin for newly introduced functionality and/or process modifications. Complete unit-testing must be performed for all new functionality which would include all the data-scenarios that development can determine as useful to include. Any code that was determined to be "impacted" (output of the Impact Analysis) must be regression tested as part of the project. Test results and data-scenarios must be executed and documented so that they can be repeated and amended as production failures occur so that they are included in future test-plans. Test results are to be shared with Project Managers and BPO's so that all are comfortable with the new system functionality and test results before promoting any changes to the next Tier.

Project Status Meetings

Regular project status meetings will be conducted by the Application PM to ensure that all tasks are being performed according to the plan. If there are issues with specific tasks on the project plan, new dates will be proposed and discussed. Any tasks that are being blocked by prerequisite tasks will also need to be re-evaluated and new plans proposed to the entire and resource needs discussed. It is not always essential for all groups (network, unix, dba, etc.) to attend every Application Project Status meeting, however, if project dates are being changed from the original plan, the dependent teams will be updated with the new dates or other relevant information to ensure there are no conflicts. Agreement on a production deployment date are discussed as early as possible, especially if the deployment is targeted for a weekend.

Pre-Production Deployment Meetings

To ensure a smooth production deployment, a Pre-Production Deployment meeting is crucial. These meetings are typically held one week prior to the actual production release deployment is scheduled. While the teams that are required to assist in the production deployment should already be aware of the production release date (through regular Project Status Meetings), the Pre-Production Deployment meeting is important for the entire team to review WHAT will occur WHEN and by WHOM. Communication during the production deployment can vary depending on the critical nature of the application being deployed. At times a bridge-line is used and at other times email communications is sufficient. To prepare for expected issues, it is typical for all members to exchange contact information during this meeting. The details of the changes begin implemented are also reviewed so that no item is forgotten or lost. The experiences of deploying the objects/changes to Tier-2 are to be discussed to remind everyone about any unusual issues or problems when the changes were deployed to that Tier. If all of the above steps are followed for each project, it will greatly reduce the chance that there will be production problems after the changes are deployed to the production environment.