Traditional Project Management Vs. eXtreme Project Management

• In the 60’s: The project management issues were left entirely to the computing group. Clients simply had to wait for the completion of the IT project.

• In the 70’s: The project management were based on engineering models and these models excluded any meaningful client participation regarding estimation, scheduling, selection of strategy, cost, effort, quality, priorities and so on. Clients got involved with the initial system analysis, system testing and documentation.

• In the 80’s: Organisations was forced to evaluate their methods. The managing and planning processes were examined by the senior managers. They became focused on how technology and systems were aligned to the business area. ROI (Return of Investment), techniques of risk assessment and risk management was taken more seriously. Problems between the IT professionals and the business professionals became reality.

• In the 90’s: Partnership relations merged to the surface. They became aware of each others working area, and that is where the driving force for a new project management paradigm like XPM lies.

Driving Force Change

• A Power shift– Dark age - Tokenism, Payback, Partnership

• The Free Agent Army– Job for life - loyalty, security ….

• The Global e-conomy– Speed, Networked world, borders ….

Basic project elements:

eXtreme Project Management (XPM)

Originally developed for eXtreme Programming, but can be used with other “light”methodologies.

The forces in XPM are not technical issues, but “business” side of project management

Project management and technical management are not the same;

- Project management deals with stakeholders, stakeholders, related projects, risk, benefits, cots, schedules, estimates and policies.

- Technical management deals with concerns data, function, object requirements, design, menu hierarchy, file design, module specifications, test plans and documentation.

XPM involves daily planning and re-planning as part of the normal team and stakeholder process. It is important to remember that changes to the context, external or internal changes, risks, scope, objectives, cost, benefit and so on is identified, valuated and reported to the stakeholders.

In XPM stakeholders are important. It is therefore important to spend a lot of time with the them. Different stakeholders see different part of the project, so they have to be brought together in order to understand the wholeness of the project - in RAP sessions.

The aim of RAP sessions are identifying the requirements and other important issues needed for the project. RAP provides the mechanism where the conflict between stakeholders can be recognised and resolved before the project continues.

The stakeholders and the team members are part of building the projects vision, and therefore the key is that all issues must be shared among the involved parties of the project.

RAP consists of 8 phases, and begins with focus on the expectations each participant has regarding reaching success in the project. It gives a broader picture for the participants.

RApid Planning (RAP)The project manager identifies key stakeholders in her project, invites them to a RAP session, and progresses through a series of steps that involve planning the project in an intensive and participative process with the project stakeholders

• Define success

• Define scope, objectives, stakeholders, and related projects

• Analyze and model project benefits

• Analyze and model project quality

• Analyze project strategy/scenarios

• Analyze project risk and develop risk management plans

• Develop project task lists

• Estimate tasks/project

• Develop project schedules

1. Define scope, objectives, stakeholders and related projects: This analyses the scope and objective. The participant’s identifies the scope or boundaries in business and technical terms. What business requirement must the project meet? Objectives are m modelled at a number of levels; Strategic, businesses, projects and technical. Services, resources and deliverables, required from the stakeholders and managers of related projects are also identified. Assumptions and constraints are documented.

2. Analyse and model project benefits: Using the business objectives of the project, participants and the project manager must analyse the business and related benefits expected for the product.

3. Analyse and model project quality: The expectations from the stakeholders concerning the quality are analysed.

4. Analyse project strategy and scenarios: Followed by the agreement on scope and objectives, the relevant strategies and scenarios needs to be analysed. Also the selection of appropriate development strategies is involved.

The 8 phases of RAP

5. Analyse project risk and develop risk management plans: Analysis of the factors that may cause the project to fail. Stability of project requirements, team experience and complexity of the business area are considered. The higher risk, the higher probability of change and failure.

6. Develop project task lists: A list of tasks which are required for completion of the project is developed. Details are dealt with in phase 8.

7. Estimate tasks/project: Risk analysis, quality expectations, algorithmic and judgement techniques, and a detailed understanding of the team skills and competence's. The correctness of the estimates impacts the schedules of development, but also derivation of costs and benefits. As many people as possible must be involved.

8. Develop project schedules: Interrelationships between tasks and resources are analysed. Also alternative schedules, resources and relationships should be driven by as many people as possible. This step is a complex business, but it brings outputs from many previous steps together.

The five tools in XPM

During the RAP process, XPM embodies five tools. This brings openness and ownership for the stakeholders. A RAP process must have full participation by stakeholders.

The five tools are;

Success slidersThe O3 modelQuality agreementsProject or partnership agreementsEvent/scenario/real-time planning

Seven related factors of expectations from a business expert view are considered here.

1) Achieving stakeholder satisfaction2) Meeting objectives/functional requirements3) Meeting budget4) Meeting deadlines5) Adding value/ROI6) Meeting quality requirements7) Achieving team satisfaction

These factors are simply measured graphically after importance like this:

The success sliders, is a tool used for negotiating the expectations for a project. Here the project sponsor has an important role, since it is unlikely that all of the stakeholders will agree on what constitutes success for the project.

Success sliders

O3 Model

The O3 model is a tool for modelling and realising the benefits for the project. The model is based on three elements: Objective, Output and Outcome. These three O’s create the project value chain, which can be followed horizontally and vertically. The project goal must support the organisation strategic goal. The same with the result of the outcome must support the organisations strategic outcome, so that the benefits of the project will support the strategic benefits.

Quality agreementThe quality of the software is a combination of the following attributes. It is important to define, in order to achieve the desired output. The attributes can both be positive or negative.

Project or partnership agreements

A common failure in a project, are stakeholders lack of awareness of their role. The project manager must develop specific communication strategies for all of the stakeholders.

Event/scenario/real-time planning

The event and scenario planning is identified by the involved people in the RAP session. The assumption is that the project is impacted constantly by both external and internal changes. It is important to define and identify events and scenarios that could be involved in delivering the product.

Traditional Risk Management

Risk can be many things. An example is shown below.

Project Risks

Technical RisksPlanning andresource risks

Requirementsrisks

Relationship risks

Commercial risks Subcontract risks

No or poor business case

More than one customer

Inappropriatecontract type

Penalties for non-performance

Ill-defined scope

Unclear paymentschedule

Payments not linkedto deliverables

Unclear customerstructure

Poor access tostakeholders

Internal customerpolitics

Multiple stakeholdersUsers notcommitted to project

Unwillingness tochange

Management andusers disagree

Requirementsnot agreedRequirementsincompleteRequirements not detailedAmbiguity inrequirementsNo single document ofrequirementsStringent non-functional requirementsAcceptance criteria not agreed

Project manager not involved in initial planningProject very large with quick build-upEstimates not basedon metricsExcessive relianceon key staffDevelopers lack keyskillsInexperience inbusiness area

Inexperience oftechnology

Environment newto developers

Development and live environments differRestricted access toenvironmentUnfamiliar systemsoftware

Lack of technicalsupport

Unfamiliar tools/methods/standardsNew/unproventechnology used

No/little experienceof suppliersSuppliers in poorfinancial state

Difficult to stage testsof itemsNo choice of supplierUse of proprietaryproductsSubcontracts not“back-to-back” withmain contract

Meeting expectations

• Achieving stakeholder satisfaction

• Meeting objectives/functional requirements

• Meeting budget

• Meeting deadlines

• Adding value/ROI

• Meeting quality requirements

• Achieving team satisfactionP 19