Docstoc

Project Management Framework Lite - PDF

Document Sample
Project Management Framework Lite - PDF Powered By Docstoc
					Describing a Lightweight Framework to Support 
Project Delivery 
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 by­products of 
achieving the result around which the framework is orientated. A project 
management framework may successfully produce artifacts, that collectively point to 
a well­managed 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 
delivery. 
The purpose of this document is to:
     · Define artifact desirability based on stakeholder­centric orientation in pursuit 
         of project delivery.
     · Place the central emphasis on requirements elicitation, elaboration and 
         representation.
     · 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 
process­centric; rather it is focused around the stakeholders in a typical commercial 
software project.



                                                                                      1 
The stakeholders 
Any framework that advocates a stakeholder­centric 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

                                                                                       2 
Pre­funding 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. 
                                                                           1 
Artifacts that are not read, or read and not understood, have no value  . (If no one 
needs it, don’t do it.) 

1 
  A stakeholder may sign­off 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
                                                                                                                      3 
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. 
                               Business strategy 
                               Programme management 
                               Project outline 
                               Requirements engineering 
                               Solution design 
                               Project management 
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 ‘sign­off’ may not always be a guarantee of ‘buy in’.

                                                                                                                     4 
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 
inter­dependence 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’.


                                                                                             5 
In Price Lite, Requirement engineering artifacts are at the heart of the process 
binding the process of project delivery together in an end­to­end manner. 
Requirements are often referred to as being ‘high level’. In Figure 7, high level 
requirements are part of Project outline, mid­level 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. 
Mid­level requirements representation verify the high level requirements and support 
the decision to continue funding a project from inception to elaboration. Low level 
requirements elaborate mid­level requirements and provide the detail to solution 
designers allowing a logical solution to be transformed into a physical design suitable 
for programmers. 




  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

                                                                                        6 
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 
                                identified stakeholders 
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.




                                                                                       7 
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 
proposal. 
A logical strategy is a suggestion as to how the vision can be satisfied. The strategy 
is a statement of the end­to­end 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 
                                       be produced.




                                                                                       8 
Conclusion 
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 
over­riding 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 
been explored. 
Prince Lite is, like the ideas upon which it is based, a framework; albeit one designed 
to support project delivery by adopting a stakeholder­centric 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 ‘in­flight’. 
No artifact should be produced for the purpose of ‘ticking a box’. 

Future work 
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 
specification]. 
Interested readers are invited to visit www.princelite.co.uk 
Queries may be addressed to peterjmerrick@gmail.com




                                                                                       9 

				
DOCUMENT INFO
Description: Project Management Framework Lite document sample