Traditional Project Management Vs. eXtreme Project Management

1. Traditional Project Management Vs. eXtreme Project Management

2. 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.

3. 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 ….

4. Basic project elements:

5. 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.

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

7. 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

8. The 8 phases of RAP 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.

9. 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.

10. 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 O3model • Quality agreements • Project or partnership agreements • Event/scenario/real-time planning

11. Success sliders 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.

12. 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.

13. 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.

14. 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.

15. 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.

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

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