//10 min
intive likes to collaborate closely with our customers. We communicate regularly. We use sprint reviews, prototypes and product demos to gather feedback. We use these to help us solve complex problems iteratively. However, many of our clients are in regulated industries where quality and budgetary obligations mean that strict phase-gates are required. But if the time, scope and cost of the “Iron Triangle” of project management is fixed, is it possible to develop in an Agile fashion? We believe it is and have experience in successful deliveries in this fashion.
This post discusses how we approach this problem using our response to a recent public tender. For confidentiality, we have redacted the clients’ name but it was a major international body working in a highly regulated industry. For the purpose of this document, we’ll call them “SHIELD”.
Planning a Project for SHIELD
The projects approved by SHIELD are run according to a tightly defined structure. SHIELD are providing the majority of funding for the project and want to ensure that it is being run effectively and with the appropriate level of oversight.
To ensure this, they mandate strict review stages at which the project team members led by the programme manager must present the progress to the SHIELD representatives along with certain deliverable documentation appropriate to that particular stage of the project's delivery. The project funding is released in stages after agreed milestone objectives are met. This directs the project planning from the start.
It must be planned in such a way that the necessary deliverables are prepared at each stage and are available for the next milestone review meeting with the SHIELD team, which will then gate the progress to the next stage.
The main milestone review stages are:
Negotiation Meeting (Kick-Off meeting) - All the final points relating to the proposal are closed off and the contract signed.
Baseline design review - This is the output of the systems analysis and requirements stage where the requirements document is presented to the SHIELD team. It gates the design stage.
Factory Acceptance Test (FAT) - Once the development, integration, and validation stages are completed, the SHIELD team visits the tenderer’s location and the functionality is demonstrated to them. The test plan is presented along with the results for the executed test cases. The SHIELD team selects a subset of these tests to be run in their presence.
On-Site Acceptance Test (SAT) - This is held when the system is deployed at the Pilot site and is very similar to the FAT, but with the system fully installed and ready for the pilot.
Customer Trial (Demo) - Run from this point for six months with designated users interacting with the system and recording results, verifying KPIs for compiling in monthly pilot reports to be presented to SHIELD.
Final Review - At the end of the pilot all the deliverables are collected and presented to the SHIELD team along with a final report.
Work Breakdown Structure (WBS)
The initial step in the project planning is to identify the necessary top-level blocks of work and break them into their individual implementation pieces or stages.
We need to bear in mind that the detailed architecture and design is carried out during the actual implementation stage and so the information is limited at this point. However, the technical proposal section of the final proposal should provide enough information to guide the work breakdown.
The WBS is created in a hierarchical fashion starting with the level one Work Packages (WPs) and breaking them into their main component pieces to create the level two WPs. These are, in turn, split into the individual tasks needed to realise them as level 3 WPs, and so on, as needed to allow a realistic set of effort estimates to be made The level arrived at is that level necessary to achieve reasonably accurate effort estimates, taking into account the sequencing of tasks and discovery of dependencies.
Once the WPs are defined they're estimated.
The WBS presented in the final proposal document is limited to the level one and two WPs to keep things concise, but the planning of the lower level WPs is necessary to allow the aggregation of the properly sequenced estimates from these lower-level tasks to provide overall lead-time estimates.
The WPs are detailed in WP description documents for each level 2 WP with the lower level details included as tasks and the inputs and outputs for each WP detailed. The intention is to assure the SHIELD approval body that sufficient thought has been put into the proposed design - that it's realistically thought through and sufficiently detailed at this stage.
Gannt Chart
A milestone chart or Gannt chart is created with the tasks added, resources applied and sequenced correctly to reflect the dependency between the tasks and the constraints due to the availability of resources. Once these tasks have been sequenced and resourced the timelines for the higher level WPs can be calculated and this is included in the Final Proposal as the top-level Project bar chart.
The Main Gannt chart shown below is the overall plan, with the higher level WPs shown and the lower level tasks all collapsed.
Looking at the top level Chart one can see the stages of the plan after the Kick-Off meeting with the Phase 1 system analysis leading to the BDR which gates the Phase1 Design stage. This is followed by the Phase 1 development and then the integration and validation stages, leading to the Demo setup and the FAT meeting. Next is the demo setup, the SAT meeting and the start of the Phase 1 pilot trial. The Phase 2 System analysis and the Phase 2 System design stages are started in parallel with the Phase 1 Development stage. The Phase 2 development stage, executed through a sequence of Agile Sprints, involves two separate deliveries with updates to the Demo system and two separate Demos. Pilot results are compiled into reports issued and presented to the SHIELD team during a set of monthly steering meetings. The final review with its set of deliverable reports concludes the project.
Organising the team
Here we see the chart showing the team organisation.
We have an overall Programme manager who will be responsible for interfacing with the SHIELD representatives and any other stakeholders such as officially designated users of the pilot system. The programme manager will provide the project management oversight and the reporting of status to SHIELD, organising and hosting the various milestone reviews and monthly steering meetings and helping organise all deliverable documentation, including the monthly reports.
Since the project will be run on agile lines the programme manager will also act as the Scrum Master for the team. The contractual manager helps to handle any contracts and negotiations with SHIELD, any partners, suppliers and other stakeholders. The Marketing Manager will be responsible for creating a project web-page, publicity brochures and any additional marketing activities during the lifetime of the project - which is something that will be reported on at the monthly steering meetings for all the interested stakeholders. The System Architects will carry out the systems analysis and design creating the requirements document and the system architecture document. One of the Architects will also act as the Product Owner - creating and managing the backlog of Epics and stories. The Developers will play a part in the requirements and design stages along with their main role in the implementation and pilot stages.
The System test engineer will, of course, be involved in creating the overall test-plan document and validating the system according to the traceable set of tests defined. They will play a large role in the FAT, SAT and pilot stages.
Conclusion and Recommendation
As this example shows it is possible to overlay an Agile way of working in a regulated, phased approach. It needs some experience and skill to develop a good work breakdown structure to map to an Agile backlog and to schedule sprints within the phases. If you need help in designing a similar solution for your project please contact us.