|
| |
PRINCE2
Prince2 Project Management Methodology
|
|
| Diagram showing PRINCE2 processes. The arrows represent flows
of information. |
PRINCE2 is a process-driven project management method. PRINCE2 is suited to
product focussed projects in regulators and large enterprises. PRINCE2 defines
45 separate sub-processes and organizes these into eight processes as follows:
- Starting Up a Project (SU)
- Planning (PL)
- Initiating a Project (IP)
- Directing a Project (DP)
- Controlling a Stage (CS)
- Managing Product Delivery (MP)
- Managing Stage Boundaries (SB)
- Closing a Project (CP)
ITIL
Information Technology Infrastructure Library
ITIL is a customizable framework of best practices that promote
quality services. ITIL addresses the organizational structure and skill
requirements by presenting a comprehensive set of management procedures with
which an organization can manage its IT operations.
The processes identified and described within ITIL are supplier independent.
The upcoming ITIL v3 will consist of:
The Practices of Agile Project Management
Much of the PM literature today is focused on “enterprise” project
management, “portfolio” management, multiple project management, and the
corporate standards approach to project management. These are not domains that
“agile” lays a claim to. Agile PM is focused on the activities found in a
project with a single purpose, a definable set of outcomes, users or stakeholder
that can be clearly identified, spoken to face–to–face. These other domains are
interesting and may be appropriate for program management.
Some Agile PM practices are:
Assume Simplicity
- It is the users who define requirements. Writing elaborate functional and
system specifications to support these requirements is not an agile activity.
Asking the users and stakeholders what they want in a face–to–face manner is
agile. If a picture is worth a 1,000 words, a working piece of software, even
in the form of a prototype is worth a 1,000 pictures.
- Separation of concerns is a critical success factor for both product and
project activities. Base the separations on the business architecture of the
system, and then apply the technical architecture. Manage activities within
the context of these separations. This creates a collection of small,
interrelated projects, not one mega–project.
- Start with the simplest PM processes; verify that these processes can be
deployed against the business needs. Progress to more difficult processes but
always search for the simplest solutions.
Embrace Change
- Change is part of any modern ICT project. If change is not taking place,
then something is wrong, you’re not talking to the right people.
- An agile project sees changes as an advantage. Attempts to control change
give away this advantage. This is frightening to many organizations, since
they see change as “chaos.” This is not the case in agile PM. Change drives
innovation, creates new understandings of the success factors, and forces all
participants to ask: “do I really need this step or process?” “Where can I see
the bookable benefits of doing it this way?”
- Continuous delivery using working software enables change. Focus on
vertical versus horizontal delivery (making the disk move on the first
instance and every instance after that).
Enable the Next Effort
- Use a “Battle Planning” paradigm for the daily project activities – it’s
chaos at the low level and big picture strategy at the high level.
- Focus on values for today, keeping the generation of value in the future
in mind.
- Continuously evaluate the future opportunity costs.
Incremental Change
- Plan globally, implement locally, guided by architecture.
- Avoid the “solve global hunger” solution; focus on real tangible PM
methods that deliver value to the project.
- Rapid planning in depth is not an oxymoron.
Maximize Value
- Put working software in the hands of the users maximizes value. Discover
what features have to be delivered to the people who have to do the work. Ask
them face–to–face “what do you need next?”
- Provide features in a rapid, efficient, and beneficial manner, with the
minimum of resources and disruptions to the ongoing operation.
- The stakeholders define the dimensions of value, ask them what they want,
when they want it, and how much they’re willing to pay for it. Ask them how
they will know when it works properly.
TOP
Manage with a Purpose
- Close all feedback loops. Measure stakeholder value and project progress
continuously in real–time.
- Don’t perform any PM function that can’t be traced to this project’s
benefits. Booking “further” benefits for an expense today is not part of Agile
PM
- Question every action – “why are we doing this?” “Is there value is this
deliverable or activity?” “What would happen if we didn’t perform this step?”
- Always define the outcome of an action: who benefits? How can this benefit
be recognized? What is the cost of obtaining this benefit?
- Never confuse effort with results! In the end the stakeholders only what
bookable results.
Multiple Views
- The business process can be used to define the highest-level boundaries of
the PM activities. Managing the interfaces between these processes becomes the
prime role for the PM
- Interface exchange definitions are critical for maintaining separation of
concerns for the PM artefacts as well as the deliverables.
- Inversion of control – the identification and management of the interface
control points is a critical success factor. Determining “who’s really in
charge” is a full time job for the PM.
Rapid Feedback
- Continuous engagement with the stakeholders is the primary source of
feedback. Without continuous feedback, agility will fail to deliver on its
promise
- A “situation room” mentality must be created in which the participants are
fighting the system not each other.
- Continuous delivery of value as defined by the stakeholders is the primary
behaviour of an agile project.
Working Software
- In the end, an agile project is focused on delivering software, not the
participating in the ceremonies of PM. Value is measured in how well this
delivered system meets the needs of the stakeholders. The Stakeholders are the
ones that get define value, not a mechanism that measures abstract progress.
Save that kind of stuff for projects with frozen requirements, risk adverse
stakeholders, and high–ceremony management styles.
- Continuous delivery is enhanced by using standard products with the
minimum of customization.
Travel Light
- Use technology to reduce the white space in the process and organization.
- Move fast and light. Use experience based behaviours and high–level
specifications to guide the solution. Low–level specifications add little
sustaining value in an agile project. Working code is a measurable value to
the stakeholders. It not only provides business value it is the source of
feedback on what to do next.
- Working software is also the final specification. Use written
specifications to capture knowledge that will be needed independent from the
working software, usually the non–functional requirements.
|
