Contrasting Prince2™/RUP™/Waterfall
Prince2
Prince2 is project management centric; a framework unconcerned with the type of project being managed (IT, construction et al). Prince2 defines many individual artefacts. In turn, these documents are grouped into a number of artefact types.
Table: The artefact taxonomy defined in Prince2.
| Strategy/Strategic direction |
| Programme management |
| Benefits realisation |
| Business case and success criteria |
| Requirements |
| Implementation |
| Project management |
On first inspection the taxonomy in the table above appears to be a good classification fit to the primary concerns of stakeholders. To test this premise it is necessary to investigate the constituent artefacts that are to be found in each category.
Table: The artefacts in Prince2, their taxonomic association, and a summary of their purpose. There are a great many artefacts identified; not all of which are immediately obviously useful from a PrinceLite perspective.
| Name | Category | Description |
|---|---|---|
| Business strategy | Strategy/Strategic direction | To describe the business direction for the future in terms of a vision, strategic themes and a portfolio of planned changes to which every programme contributes. |
| Quality management | Strategy/Strategic direction | To define overall "quality" |
| Blueprint | Programme mgt | A detailed description of what the organisation will look like in terms of business processes, people, information systems, facilities and data |
| Vision statement | Programme management | Describes the outcome of the programme in terms of new or extended capability. Delivery of this capability is the end-goal of the programme. |
| Communications strategy | Programme management | Who sees what and when |
| Project portfolio | Programme management | List the projects that comprise the programme |
| Programme plan | Programme management | Provides the basis for tracking the impact of project dependencies |
| Stakeholder map | Programme management | Identifies interested parties. |
| Benefits management | Benefits realisation | Various benefits documents such as Realisation and Profile can be combined. |
| Business case | Business case and success criteria | Used to obtain management commitment. |
| Success criteria | Business case and success criteria | A definition in measurable terms |
| Contingency reversion plan | Implementation | If things go wrong, this plan describes how the project state can be rolled back to a stable state. |
| Deficiency in delivery | Implementation | Measures agreed to address deficiencies in the level of service between supplier and customer |
| Supplier implementation | Implementation | Part of procurement to state which parties have the responsibility to perform what tasks |
| Test management | Implementation | Devise a test strategy that is efficient, effective and economic. |
| Project plan | Project management | A statement of how and when a project's objectives are to be achieved. |
| Project brief | Project management | Forms the 'contract' between the project team and corporate or programme management |
| Initiation document | Project management | To ensure that the project has a complete and sound basis before there is any major commitment |
| Quality plan | Project management | Define how the supplier intends to deliver products that meet the customer's quality expectations. |
| Communications strategy | Project management | Define who will receive what communications and how. |
| Issue log | Project management | Summarise project issues, their analysis and status. |
| End project report | Project management | Report on how well the project has performed. |
| Lessons learned | Project management | Collate lessons learned. |
| Business requirements – high level | Requirements | Within a procurement, focus on achievement of the organisation's strategic goals. |
| Expected outputs | Requirements | Provide a description of the requirements in output terms. What will it do. |
| Physical/technical environment | Requirements | Describe workspace environment, the IT and technical infrastructure. |
Utility of an artefact, introduced in the table above, is a function of the value the artefact serves in satisfying a stakeholder goal. Only those artefacts that will be of significant value should be produced. This is to avoid the phenomena where artefacts are produced that are quickly filed or put in a drawer and never referred to again (artefacts that are not maintained).
No 'lightweight' framework could contemplate producing so many artefacts without proof that they were all indispensable in leading to project delivery. Some of the artefacts appear trivial in nature. For instance it is difficult to envisage the content of the 'Quality plan'; it would, one assumes, suggest that quality was important. The question remains as to whether an entire plan is necessary to say so.
Click here to see diagram at full size
Figure: A picture of how Prince2 artefacts map to stakeholders primary goals. Here it is evident that Prince2 may define many artefacts, howeve they are not targeted at members of the delivery community. This leads us to conclude that Prince2 is not specialised for IT project delivery.
RUP
Like Prince2, RUP is not a single proscriptive process but rather it is an adaptable process framework. Where Prince2 is project management centric, RUP is software engineering centric. There is no barrier to customising the process and its artefacts, as RUP is not useful 'out of the box'.
According to RUP it is in the elaboration phase that the project starts to fully take shape. In this phase much effort is expended in the problem domain analysis. RUP extends the definition of artefacts to include documents, models and prototypes; in fact anything that isa tangible by-product of project delivery.
Table: The artefact classifications defined in RUP.
| Project management |
| Business modelling |
| Requirements |
| Analysis and design |
| Implementation |
| Configuration and change management |
| Deployment |
| Environment |
| Test |
The taxonomy in the table above can be mapped to the identified stakeholders primary concerns illustrated in the figure below. This can be compared with the same mapping done for Prince2.
Click here to see diagram at full size
Figure: Stakeholder objectives mapped to the RUP artefact taxonomy. This figure suggests that RUP has a good map to the needs of Technologists and no visibility regarding the needs of business stakeholders. RUP targets its artefacts at the delivery community but has very little to offer in terms of project management/governance. PrinceLite seeks to present a set of unified artefacts that serve both the business and the delivery communities.
Waterfall
'Waterfall' is a term that has come to encompass an approach pioneered by the U.S. military. They themselves do not refer to the approach as 'waterfall' but rather capture its essential features in the standards MIL-STD-498 and IEEE 12207.0 . To a certain degree the term 'waterfall' has taken on a pejorative sense. In common understanding it is a process that epitomises a process where one activity is undertaken, completed, and packaged into an overall output to a successor process which receives it as an input. Once an activity is completed it is not intended to be revisited regardless of problems that may be discovered later in the project. Issues that need revisiting are handled via the mechanism of 'change requests'. Military software projects are notoriously prone to ballooning costs. The waterfall approach has a bad reputation due to the frustration of practitioners. [references]
The predecessor standards to MIL-498 were criticised for being based on the artefacts themselves rather than focussing on 'real work'. These artefacts were compulsory and had a mandatory structure. Originally highly prescriptive the latest incarnation of waterfall has abandoned its rigid pre-occupation with standardised artefacts in favour of a model that accepts evidence in different forms, such as that captured in CASE tools. In this view 'developers' must 'define and record' rather than 'prepare a given document'.
In the older incarnations of waterfall, specific documents were defined, and fell into categories including 'requirements' and 'design'. However the process defines artefacts for the purpose of supporting the procurer (the buyer). The implication is that waterfall is designed to support 3rd party commercial contracts where the customer (e.g. the U.S.A.F) buys software from big military contractors.
Table: Previously artefacts referred to as Data Item Descriptions (DIDs) included:
| Name | Abbreviation | Purpose |
|---|---|---|
| System specification | SSS | List the requirements to be met by the system. |
| Software requirements specification | SRS | Define the requirements to be met by a CSCI[1]. |
| Software design description | SDD | Describe the design of a CSCI |
These technical artefacts are documents intended for use by the 'business community', but in the original model, the 'business' is the military and thus considerably more technical than might normally be expected.
[1] CSCI: Computer software configuration item which are decomposed into computer software components (CSCs) which are themselves decomposed into other CSCs which are finally decomposed into computer software units (CSU). A rather confusing hierarchical top-down approach that suggests functional decomposition which itself has been discredited.