Introducing 'PrinceLite'
PrinceLite is a framework for project delivery, not project management for its own sake. It may be called 'lite' but that is not meant to imply it is suitable only for small projects: it is suitable for any size project.
- On one level, PrinceLite is a dialect of Prince2; it informs which project artifacts are most important to project delivery.
- On another level, Princelite should really be termed PrincePlus, because it sets a particular project in the context of wider business change, programme and project definition.
What does PrinceLite offer that is new?
| Business change, project management and software engineering are considered together |
| Formalise the business and technical community |
| Factor in IT's political dimension |
| Ruthlessly focus on unambiguous business requirements representation |
| Define the minimum necessary to deliver |
| Formally define an unambiguous business requirement |
PrinceLite is designed to provide the practitioner with guidance regarding which artifacts should be produced to best support successful project delivery. Where other frameworks are centred around process that informs artifact definition, PrinceLite is centred around the artifacts that are most important to stakeholders.
PrinceLite adopts concepts from Prince2, PMBOK, RUP, Agile, DSDM, in fact from everywhere. For instance the RUP project lifecycle model of inception, elaboration, construction and transition is used and combined with a business project lifecycle that runs concurrently. This business project lifecycle for projects in the pre-funded or pilot funded stages is introduced in stakeholders. PrinceLite is primarily concerned with delivering IT projects. Unambiguous business requirements are at the heart of the framework. To achieve unambiguous business requirements, the Unified Modelling Language is used extensively.
Given that PrinceLite is an 'agile' framework, the working premise is that fewer higher quality, and shorter artifacts are preferable to more 'high level', longer and more 'wordy' examples. Documents that are not read, or read and not understood, have no value. (If no one needs it, don't do it.) There is a core of required process and artifacts. For projects with a greater need for 'governance', this is accommodated as extra to the core artifact set.