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 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 sliders  The O 3 model  Quality agreements  Project or partnership agreements  Event/scenario/real-time planning

Seven related factors of expectations from a business expert view are considered here. 1) Achieving stakeholder satisfaction 2) Meeting objectives/functional requirements 3) Meeting budget 4) Meeting deadlines 5) Adding value/ROI 6) Meeting quality requirements 7) 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

O 3 Model The O 3 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 agreement The 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 Risks Planning and resource risks Requirements risks Relationship risks Commercial risksSubcontract risks No or poor business case More than one customer Inappropriate contract type Penalties for non- performance Ill-defined scope Unclear payment schedule Payments not linked to deliverables Unclear customer structure Poor access to stakeholders Internal customer politics Multiple stakeholders Users not committed to project Unwillingness to change Management and users disagree Requirements not agreed Requirements incomplete Requirements not detailed Ambiguity in requirements No single document of requirements Stringent non- functional requirements Acceptance criteria not agreed Project manager not involved in initial planning Project very large with quick build-up Estimates not based on metrics Excessive reliance on key staff Developers lack key skills Inexperience in business area Inexperience of technology Environment new to developers Development and live environments differ Restricted access to environment Unfamiliar system software Lack of technical support Unfamiliar tools/ methods/standards New/unproven technology used No/little experience of suppliers Suppliers in poor financial state Difficult to stage tests of items No choice of supplier Use of proprietary products Subcontracts not “back-to-back” with main contract

Meeting expectations Achieving stakeholder satisfaction Meeting objectives/functional requirements Meeting budget Meeting deadlines Adding value/ROI Meeting quality requirements Achieving team satisfaction P 19