Attachment_5_Development_Project_Management_best_practices.pdf

Attachment 5: Development Project Management best practices

The intent of this section is to lay out the framework for the agile project management best practices.

These best practices will help ensure the proper planning of resources and time, to ensure the accurate deployment of planned and approved requirements, in a cost effective and timely manner, while ensuring the quality of all deliverables. It is understood that different IT providers may manage projects differently.

The following are illustrative and can be negotiated at the start of the contract. It should be noted, though, that once agreed to, project management requirements will be followed. Any deviations will need to be approved by the System Owner, as described below.

Processes:

The Contractor will adopt a Waterfall/Agile hybrid methodology to managing the ERP contract. Through this hybridization, the Contractor will ensure a dynamic and flexible approach to managing this project, ensuring quick, incremental releases, and allowing for flexibility in requirements, while providing the appropriate degree to structure to ensure proper planning and accountability. The proposed approach is as follows:

Figure 1Waterfall-Agile Hybrid

It is highly recommended that an Agile/Scrum master be identified to manage the Agile Team. This leader should have the following minimum requirements:

1. 3-5 years of Agile/Scrum master experience, with demonstrable experience managing a Scrum/Agile environment, using Agile methodologies and tools, and working as a “servant leader”

2. Agile/Scrum Master certification in any well-known certifying bodies (PMI-ACP, APMG, Scrum Alliance, etc.)

3. 3-5 years’ experience working on an IT/software development team.

This role can be a distinct role or a role wrapped into another, already defined, role, such as a software developer, team lead, etc.

The scrum master will lead the overall ERP development project, in accordance to the requirements discussed throughout the statement of work. These deliverables will be discussed below, and are in addition to the above discussed waterfall requirements. The ERP software development/configuration process will follow the following outline:

1. Section C describes the various requirements for the waterfall section of this outline. This section will focus on how the development of the ERP project will be managed.

2. After the completion of the Design Phase, the project will move into an Agile management process.

The Functional Requirements documentation, in coordination of the Product Owner, Project Manager, and key stakeholders, will be used to develop the Product Backlog. The Product Backlog will be prioritized and groomed as necessary. The overall framework for the Agile Process is as follows:

a. Sprint Planning Meeting - This meeting will be held at the start of each Sprint. This meeting will determine the length of the Sprint (2-4 weeks, on average). The Product Backlog is developed and groomed, according to value and priority. This backlog will come from the FRD and prioritized, based on the Product Owner (and their key stakeholders). Any additional changes to requirements will be updated here. This will be conducted with the Agile team, the Product Owner, and representatives from NMS/USAID and should be planned for 3-4 hours, but no more than 8 hours.

b. During each Sprint, Daily Scrum meetings will be held. This meeting will be used to identify what was completed on the last work day and what will be completed on the current workday, as well as identifying any impediments to work. This meeting will be held with the Development Team and Product Owner. These meetings should be no longer that 15-30 minutes.

c. At the end of every Sprint, a Sprint Review will be held. The Sprint Review will include the Product Owner, the Development Team, and all identified key stakeholders (USAID and NMS). The Sprint Review will be used to provide stakeholders with a live demonstration of what was completed in the previous Sprint. This will be a live demo of completed tasks. This meeting will also be used to gain formal acceptance of completed tasks. Any issues, bugs, incomplete work, unaccepted work, etc. will be added back to the Product Backlog for future work. This should be time boxed for about 4 hours.

d. After the Sprint Review, but before the next Sprint Planning Meeting, will be the Sprint Retrospective. This will be held by the Product Owner and the Project Team. This will be time boxed to about 3 hours and will be used to review the current process and discuss what worked and what did not work. Improvements are then used to update the current Sprint process.

4. Maintenance is the final phase in this process. This phase focuses on the ongoing maintenance, updates, security and management of the completed project. This is discussed in Section C.

Roles:

1. Project Manager – This will be a member of the Contractor’s team. His/her primary responsibility is to ensure proper documentation of the project, keep track of project progress, and ensure project management best practices. This is further defined in Section F.6 Key Personnel.

2. Scrum Master – This is the Scrum Expert and will ensure the proper use of Scrum methodology, Artifacts, etc. They will be responsible for removing impediments hampering the Development Team. This role will also be provided by the Contractor and may be combined with the Project Manager role.

3. Product Owner (Contracting Officer’s Representative)– This will be a USAID appointed role.

The Product owner is responsible for managing, prioritizing, and grooming the Product Backlog.

He/she will also be responsible for approving changes to the scope of the project. He/she is also responsible for formally determining the completeness of tasks and signing off on deliverables.

Development Team – This is the development team required to complete tasks. This will be determined and provided by the Contractor. Deliverables:

1) Agile Management Phase

a) Product Backlog – a prioritized list of User Stories. Each User Story will track, at a minimum, the description of the task, who is responsible for completing the task, start/end date/time of working on the task, testing start/end date/time, person responsible for testing, person signing off on completeness of test, result of test, date/time of integration.

b) Updated Sprint Backlog – these are the User Stories being worked on, on the current Sprint.

c) Updated daily Sprint board/Kanban board

d) Burn down/Burn up charts

e) Online, internet accessible, information radiators. These shall be included in the Agile management tool selected for use. These information radiators shall be readily available visualizations, reports, charts, etc. that provide a clear, concise, and updated status report of the current sprint, and the overall project.

Support Systems:

All Agile artifacts (User Stories, Backlog, Burn Down/Up Charts, etc.) will be managed in an online web Agile Tool. This tool will track all requirements online and will be made fully available to the Product Owner and their USAID/NMS designees. This tool will be internet based, allow for the tracking of all user stories, backlogs, charts, etc. The selected tool should integrate with the selected source control product, to track and document committed changes, as well as the selected Help Desk solution.