Describing a Lightweight Framework to Support
Dr. Peter Merrick
A framework can be thought of as a set of processes which result in the production of
artifacts on the road to software. Allegedly, these artifacts are byproducts of
achieving the result around which the framework is orientated. A project
management framework may successfully produce artifacts, that collectively point to
a wellmanaged project without the project necessarily producing what the business
wanted. A software engineering framework may equally suffer from the same
criticism. The production of artifacts should be more than a process of ‘going through
the motions’. Artifact production must be on the critical path to successful project
The purpose of this document is to:
· Define artifact desirability based on stakeholdercentric orientation in pursuit
of project delivery.
· Place the central emphasis on requirements elicitation, elaboration and
· Describe a pragmatic and lightweight framework
Figure 1: The objective of this document is to describe a lightweight process
framework for Project delivery.
Where existing frameworks such as Price II are project management centric, and
RUP is software engineering centric, what is actually required is a synthesis of these
two domains as illustrated in Figure 1. This synthesis results in a new framework for
project delivery. Sometimes a synthesis can result in something more than the sum
of its parts. The project delivery framework described in this document, is not
processcentric; rather it is focused around the stakeholders in a typical commercial
Any framework that advocates a stakeholdercentric philosophy must begin with an
identification of the stakeholders who commonly feature in a typical business
‘automation’ project. Stakeholders are divided into two ‘communities’; business and
delivery as illustrated in Figure 2.
Figure 2: Stakeholders in a typical business process automation project. The link
between the two communities is not well understood and suggests a root cause of
problems in project delivery.
The introduction of the concept of communities introduces a formalism into the
stakeholder landscape as it exists in most projects. Stakeholders have different
interests and different needs. Members of the business community focus around how
new software will support the vision they have for their organisation and the impact it
will have on working lives, whereas members of the delivery community focus on
constructing the software the business will use.
Typical stakeholder goals
· Senior manager: Interested in the big picture and in answers to the question
‘how much will it cost?’
· Middle manager: Runs projects. Acts as Senior Responsible Owner. Wants to
deliver good new to senior management.
· Users: Workers – business as usual.
· Project manager: Manage projects
· Technologist: Deliver projects
Prefunding Project Lifecycle
Typically when thoughts turn to project lifecycle states (phases, stages) one thinks of
the RUP model, or the waterfall model. Notions of inception, elaboration,
construction, and transition are valid, but only after the business has agreed to fund
the project. In order for the business to be convinced to pay for the project, it must be
shown the project will deliver some aspect of the corporate goal. This leads to the
assertion that there exists a whole project lifecycle state model that exists prior to
those described by the software engineering frameworks.
Figure 3: The notion of project state from the business perspective is entirely different
from the software engineering notion of project state. Before a project reaches the
first engineering state (e.g. inception) it must reach the ‘funded’ state.
Figure 3 introduces the notion of project state from the perspective of the business
community. This model reinforces the difference between a software engineering
perspective that may navigate project states (phases) such as inception, elaboration,
construction et al (RUP phases), with one from the business community that decides
whether a project should be funded. Once the business agrees the project should be
funded, the software engineering lifecycle model takes over.
Introducing the Lightweight Framework ‘Prince Lite’
Prince Lite is the name given to the stakeholder centric, simplified, project delivery
focused framework described here. It is designed to provide the practitioner with
guidance regarding which artifacts should be produced to best support successful
project delivery. Where the other frameworks are centred around process that
informs artifact definition, Prince Lite is centred around the artifacts that are most
important to stakeholders.
Artifacts that are not read, or read and not understood, have no value . (If no one
needs it, don’t do it.)
A stakeholder may signoff an artifact without actually understanding it. No one gives business project sponsors
training in how to carry out their responsibilities. It is a rare project sponsor indeed who will admit to not
The Prince Lite artifact taxonomy
Table 1: The artifact classifications defined in Prince Lite. All artifacts fit into these
classifications. The classifications map to the goals the stakeholder wish to satisfy.
Prince Lite artifacts fall into the categories defined in Table 1. In the main, these
classifications directly map onto stakeholder goals. ‘Project outline’ is introduced to
support the project lifecycle state prior to ‘funded’ (see: Figure 3), after which the
RUP project lifecycle states are used.
Figure 4: The classification of document type aimed at each identified stakeholder
group based on objectives.
understanding an artifact that is presented to them. All industries suffer from jargon. I.T. is one of the worst
offenders. This is then to suggest that ‘signoff’ may not always be a guarantee of ‘buy in’.
One of the risks to successful project delivery is the polarisation of the business and
delivery communities (Figure 2). There is an absence of formalisation around their
interdependence to the point where these silos of interest represent a significant
structural risk to project delivery. Figure 4 introduces a bridge between the
communities at the level of ‘Project outline’ and ‘Requirements engineering’. This
bridge is an innovation in Prince II that translates into there being a requirements
artifact that acts as the basis of the ‘contract’ between the business and delivery.
This artifact begins life in ‘Project outline’ and if the project is ‘funded’ it is elaborated
and falls under the classification of ‘Requirements engineering’.
Figure 5: Prince Lite artifacts change according to project lifecycle stage. An artifact
that begins life in ‘Project outline’ during ‘unfunded’ is transformed to ‘Requirements
engineering’ during funded/inception.
Figure 5 breaks out the technologist types into specialisations within the delivery
community [business analyst, architect/designer, programmer, tester]. In this model
there are artifact types directed at all stakeholder groups. Prior to a project being
accepted (funded) its artifacts belong to ‘Project Outline’ which itself is a component
of programme management.
After a project is accepted, the ‘Project outline’ requirements artifact informs ‘Project
management’ and transitions into ‘Requirements engineering’. Later when the project
moves from inception to elaboration, the requirements artifact is further elaborated
and transitions again into Solution design while at the same time informing ‘Testing’.
In Price Lite, Requirement engineering artifacts are at the heart of the process
binding the process of project delivery together in an endtoend manner.
Requirements are often referred to as being ‘high level’. In Figure 7, high level
requirements are part of Project outline, midlevel requirements are an elaboration of
high level requirements and so forth. This hierarchy of requirements elicitation can be
thought of as a relationship of specialisation. Each iteration is undertaken
successively in different states of the project lifecycle. High level requirements inform
scope and primarily satisfy senior managers regarding decisions to fund the project.
Midlevel requirements representation verify the high level requirements and support
the decision to continue funding a project from inception to elaboration. Low level
requirements elaborate midlevel requirements and provide the detail to solution
designers allowing a logical solution to be transformed into a physical design suitable
Figure 6: Requirements are represented at different levels of detail (abstraction) and
contained in artifacts that have owners. The high and mid level requirements are
owned by the Senior Responsible Owner (SRO). The PID may be of interest to the
CEO depending on the importance of the project. The solution team (architects and
designers) own the low level requirements. The business analyst owns the process
of transforming the requirements from one layer of abstraction to another.
As a lightweight framework, Prince Lite emphasises a minimal set of artifacts. Any
artifact that has a stakeholder is potentially valid, but the requirements artifact set,
illustrated in Figure 6 [PID, BRS, SRS] is mandatory. Figure 6 represents the
Business analyst owning the transformation from the BRS to the SRS. The SRS
representation may in fact be undertaken by a system analyst.
Figure 7: Populating the Prince Lite artifact taxonomy with specific artifacts aimed at
Figure 7 maps the minimal artifact set to the community model. It introduces the
Requirements engineering layer that now spans the two communities to
accommodate the requirements specification set elaboration introduced in Figure 6.
The PID is considered part of Project outline until a decision is taken to fund the
project at which point it becomes an input to the creation of the BRS.
Order in which artifacts are produced
The artifact architecture developed in Figure 7 does not tell us anything about the
order in which these artifacts are produced. No strictly top down or bottom up
approach is going to be sufficient. The process begins with an articulation of the
vision against which a logical strategy is produced. This candidate strategy must be
judged on its own merit and accepted, modified or rejected. There is no way of
knowing at the outset, how many projects will result from a single logical strategy
A logical strategy is a suggestion as to how the vision can be satisfied. The strategy
is a statement of the endtoend sessionless problem landscape that includes high
level requirements that define scope. Given the strategy is acceptable in principle, it
may be divided into projects for implementation reasons. This process of division
creates dependencies between projects.
If there are a great number of projects identified these may be grouped together into
different programmes for management convenience.
Figure 8: Activity diagram for initially populating the artifact plan to satisfy the
programme plan. The vision statement is satisfied by the strategy. The strategy is
satisfied by projects. Projects are grouped into programmes. Once the shape and
structure of the projects is known the remainder of the programme documentation can
It has been suggested that artifacts should only be produced that directly benefit a
known and named stakeholder who is prepared to own them and to sanction their
maintenance. A set of prototypical stakeholders has been identified, along with their
overriding concerns. A taxonomy has been suggested that addresses stakeholder
goals and the categories have been populated with candidate artifacts. The
relationship between artifacts has been expressed, most importantly with respect to
requirements representation. Lastly, the order in which artifacts are produced has
Prince Lite is, like the ideas upon which it is based, a framework; albeit one designed
to support project delivery by adopting a stakeholdercentric world view. The
objective of Prince Lite is to ensure the production of each artifact plays a
fundamental part in moving toward delivery success. Of course the artifacts may also
be used to support a decision not to continue (to cancel) a project that is ‘inflight’.
No artifact should be produced for the purpose of ‘ticking a box’.
This document is not sufficient to implement Prince Lite, instead it presents the
intellectual case for how the framework has been arrived at and then defines its
essential structure. It remains to provide annotated templates and standardised
examples. Initially this support material will be confined to the requirements
elaboration set [PID, Business requirements specification, Systems requirement
Interested readers are invited to visit www.princelite.co.uk
Queries may be addressed to email@example.com