outset that there is no proscription against the iterative implementation of any particular phase (see Figure 2) or the constituent steps within it.
When defining our methodology, we needed to make sure that our processes were standards-based (PRINCE2 is a defensible choice) and could demonstrate the rigor expected of a publically accountable organisation. We also needed to support the Agile practices which are so well suited for handling an emergent project scope. This could not be achieved through the conventional model of a “spectrum” of software development methods, featuring as it does agility and adaptability at one end, and prescription and rigor at the other. We needed both, and not just the ability to throttle up and down the continuum. We could not accept the risk of falling between two stools, and of becoming either PINO (PRINCE2 In Name Only) or AINO (Agile In Name Only). Establishing a “balance” would be important, but it wouldn’t be enough. We needed to do both well.
We were certainly encouraged by improvements in scalability claimed by the new version of PRINCE2. This scalability allows for documentation sets to be subsumed or (rolled up) into terser artefacts, and without compromising the remit and purpose of each discrete management product. We therefore settled on a model where Agile practice is applied to an orthogonal framework of reporting arrangements and prescriptive checkpoints that support quality and project assurance.
The methodology would have to be generally applicable to all projects being run on our programme. It would also need to be customisable (or at least configurable) so as to accommodate any special cases. For example, some projects might involve significant hardware development. This indicated a need for tool support. It would not be enough just to document the methodology. It would need to be realised as a workflow management tool – ideally web based and configurable using XML – which would allow one project manager to oversee multiple projects, and which would guide stakeholders (including clients and suppliers) through the process.
The iterative portion of the project would come into play during Development when a Delivery Plan (with supporting architectural designs) is specified, and in Delivery itself when incremental releases are produced and evaluated. It would need to support discrete phases of project initiation and feasibility assessment spread over the first 2 D’s of Discovery and Definition.
We were also able to use DSDM Atern as a starting point. There was an apparent synergy between the “4 D’s” and the lifecycle phases as illustrated in the DSDM Atern Handbook. There was, of course, an impedance mismatch in the correspondences, since the “4 D’s” were notional and lacked the prescriptive detail of Atern. However, this was not a problem in so far as a rational mapping to DSDM would flesh out much needed structural detail. We settled on the following translations:
1. The Discovery Stage provides for a high level investigation of potential solutions, costs, and timeframes (including some early desk-based market research). This translates into the DSDM Atern Feasibility Phase.
2. The Definition Stage defines the project focus, in terms of how the technical solution should satisfy business needs. In-depth market research is used to underpin these decisions. As such this corresponds to the DSDM Atern Foundations Phase.
3. The Development Stage produces a candidate architecture from the high level requirements identified by market research, and produces a Delivery Plan. Suitable suppliers will be identified on the basis of this rubric. This translates into the DSDM Atern Exploration Phase.
4. The Delivery Stage engages suppliers who then produce the solution