Information Technology Project Management – Fifth Edition - PowerPoint Presentation

Information Technology Project Management – Fifth Edition By Jack T. MarchewkaNorthern Illinois University Copyright 2015 John Wiley & Sons, Inc. 2- 1

Project Methodologies and Processes Chapter 2 2-2 Copyright 2015 John Wiley & Sons, Inc.

Introduction Project MethodologyA strategic-level plan for managing and controlling the projectGame plan for implementing project and product lifecyclesRecommends phases, processes, tools, and techniques for supporting an IT project Must be flexible and include “best practices” learned from experiences over time.Can be Traditional (e.g., Waterfall)Agile (e.g., XPM, SCRUM) 2- 3 Copyright 2015 John Wiley & Sons, Inc.

Project Methodology The step-by-step activities, processes, tools, quality standards, controls, and deliverables that are defined for a project. Provides a systematic way to plan, manage, and execute the work to be completed by prescribing phases, processes, tools, and techniques to be followed. 2-4 Copyright 2015 John Wiley & Sons, Inc.

Advantages of using a methodology Provide the project team with a game plan for implementing the project and product life cycles Focus on the tasks at hand, instead of always worrying about what they are supposed to do next. Provides a common language that allows the project team, project sponsor, and others within the organization to communicate more effectively.Enables management to compare different projects more objectively so they can make better-informed and more objective decisions with respect to which projects get selected and whether funding should continue to support a particular project. 2- 5 Copyright 2015 John Wiley & Sons, Inc.

The Project Life Cycle Collection of logical stages or phases thatmaps the life of a projectfrom its beginning, through its middle, to its end, to define, build, and deliver the product. 2- 6 Copyright 2015 John Wiley & Sons, Inc.

Project Phases Phase Exits, Stage Gates, Kill PointsProjects should be broken up into phases to make the project more manageable and to reduce risk. Kill points are the phase-end review of key deliverablesAllows the organization to evaluate project performance and take immediate action to correct errors or problems or not proceed to the next phase Fast TrackingStarting the next phase of a project before approval is obtained for the current phaseCan be used to reduce the project scheduleCan be risky and should only be done when the risk is acceptable 2- 7 Copyright 2015 John Wiley & Sons, Inc.

Figure 2.1 – A Generic Project Life Cycle 2- 8 Copyright 2015 John Wiley & Sons, Inc.

Project Life Cycle – Define and Plan Define Project GoalThe project goal should be focused on providing business value to the organizationProvides a clear focus and drives the other phases of the projectTells us how we will know if this project is successful given the time, money, and resources investedAlternatives that would allow the organization to meet its goal are identified. The costs and benefits, as well as feasibility and risk, of each alternative are analyzed. A specific alternative is recommended for funding. The project’s goal and the analysis of alternatives that support the goal are summarized in a deliverable called the business case. 2- 9 Copyright 2015 John Wiley & Sons, Inc.

Project Life Cycle – Define and Plan Plan ProjectProject Objectives Include scope, schedule, budget, and quality. Define what work needs to be completed, when it needs to be completed, how much it will cost to complete, and whether the work is acceptable to specific stakeholders.ResourcesResources are needed to complete the project work and include such things as people, facilities, and technology.Controls A great deal of managing a project includes ensuring that the project goal and objectives are being met and resources are used efficiently and effectively. Risk, change, and communication among the project stakeholders must be proactively managed throughout the project.2- 10 Copyright 2015 John Wiley & Sons, Inc.

Project Life Cycle – Execute, Close, and Evaluate Execute Project PlanManage the project scope, schedule, budget, and people to ensure the project achieves its goalProgress must be documented and compared to the baseline planProject performance must be communicated to all of the stakeholdersAt the end of this phase, the team implements or delivers a completed product, service, or information system to the organization. Close and Evaluate ProjectEnsures that all of the work is completed as plannedFinal project report and presentation to the clientPostmortem reviewLessons learned and best practices documented and shared 2- 11 Copyright 2015 John Wiley & Sons, Inc.

Figure 2.2 – The PMBOK® Guide – The 10 Project Management Knowledge Areas 2- 12 Copyright 2015 John Wiley & Sons, Inc.

PMBOK® Guide – The 10 Project Management Knowledge Areas Project integration managementProject scope managementProject time managementProject cost management Project quality managementProject human resource managementProject communications managementProject risk managementProject procurement managementProject stakeholder management 2- 13 Copyright 2015 John Wiley & Sons, Inc.

The 10 Project Management Knowledge Areas Integration ManagementFocuses on coordinating the project plan’s development, execution, and control of changes.Scope ManagementProvides assurance that the project’s work is defined accurately and completely and that it is completed as planned. Includes ways to ensure that proper scope change procedures are in place.. 2-14 Copyright 2015 John Wiley & Sons, Inc.

The 10 Project Management Knowledge Areas Time ManagementImportant for developing, monitoring, and managing the project’s schedule. It includes identifying the project’s phases and activities and then estimating, sequencing, and assigning resources for each activity to ensure that the project’s scope and objectives are met.Cost Management Cost management assures that the project’s budget is developed and completed as approved. 2-15 Copyright 2015 John Wiley & Sons, Inc.

The 10 Project Management Knowledge Areas Quality Management Focuses on planning, developing, and managing a quality environment that allows the project to meet stakeholder needs or expectations.Human Resources Management?Focuses on creating and developing the project team as well as understanding and responding appropriately to the behavioral side of project management.Communications ManagementEntails communicating timely and accurate information about the project to the project’s stakeholders. 2-16 Copyright 2015 John Wiley & Sons, Inc.

The 10 Project Management Knowledge Areas Risk ManagementConcerned with identifying and responding appropriately to risks that can impact the project.Procurement ManagementProjects often require resources (people, hardware, software, etc.) that are outside the organization. Procurement management makes certain that these resources are acquired properly.Stakeholder ManagementFocuses on identifying project stakeholders to better understand their expectations or interests, and then developing appropriate strategies for communication and managing potential conflicts. 2-17 Copyright 2015 John Wiley & Sons, Inc.

Figure 2.3 – PMBOK® Project Management Process Groups 2- 18 Copyright 2015 John Wiley & Sons, Inc.

The Five PMBOK® Project Management Process GroupsA process is “a set of interrelated actions and activities performed to achieve a pre-specified product, result, or service”. In other words, a process is something you do to achieve a result.Processes are an integral component of projects They support all of the activities necessary to plan, create, and manage all of the projects activitiesProject management processes are different from the PLC phases because they are actions or tasks to initiate, plan, execute, monitor and control, and close a project as well as interact with the project management knowledge areas.PMBOK outlines five process groups The groups overlap within and between the phases of the project as the output of one process group within a phase becomes the input for a process group in the next phase 2- 19 Copyright 2015 John Wiley & Sons, Inc.

The Five PMBOK® Project Management Process GroupsInitiating processes Defining and authorizing a project or project phasePlanning processesDevising and maintaining a workable scheme to ensure that the project addresses the organization’s needs Executing processesCoordinating people and resources to carry out the various plans and produce the products, services or results of the project or phaseMonitoring and controlling processesRegularly measuring and monitoring progress to ensure that the project objectives are metClosing processesFormalizing acceptance of the project or phase, closing out contracts, documenting lessons learned 2- 20 Copyright 2015 John Wiley & Sons, Inc.

PRINCE2® PRojects IN Controlled E nvironments2- 21 Copyright 2015 John Wiley & Sons, Inc. Nonproprietary PM methodology developed for government projects in the UK Now used worldwide by 20,000 public and private organization Follows the PLC and provides stakeholders with a common language and approach to managing projects of all sizes and types Key features of PRINCE2 Focus on business justification Defined organization structure for the project management team Product-based planning approach Emphasis on dividing the project into manageable and controllable stages Flexibility that can be applied at a level appropriate to the project.

PRINCE2® 2- 22 Copyright 2015 John Wiley & Sons, Inc. Aim of PRINCE2®? Ensure that projects are well-thought out in the beginning, well-managed throughout, and organized until the end. Role of the Project Board A Project Board is created and is accountable and responsible for managing, monitoring, and controlling the project activities to ensure that the project achieves the value envisioned in the business case. It also makes important decisions such as change requests and whether the project should continue. The Project Board is accountable for the project’s success or failure.

PRINCE2® 2- 23 Copyright 2015 John Wiley & Sons, Inc. The Project Board may have up to eight people and includes three important roles: a customer, a senior user, and a senior supplier The customer can be a customer, client, or executive sponsor who represents the business interests of the organization. The senior user represents the interests of the users or stakeholders who will use the project’s product in order to bring the expected value or benefits to the organization. The senior supplier represents the suppliers or specialists who provide the skills or resources needed to deliver the project’s product.

PRINCE2® – The Seven Processes 2- 24 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Seven (7) Processes Start ProjectThis is a relatively short process that is focused on developing a project brief or document that provides business justification for the project.Initiate ProjectDevelop the project brief into a more detailed business case, which is a key document that lays a foundation for all important project decisions. Direct ProjectThe Project Board’s overall activities are defined so that it can direct the project successfully throughout each stage up through the project’s closure. 2- 25 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Seven (7) Processes Control StageDuring this process, the project manager’s day-to-day activities are defined as well as how the project tasks will be controlled and monitored.Manage Product DeliveryThis process ensures that the work packages are developed, delivered, and approved as planned. 2-26 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Seven (7) Processes Manage Stage BoundariesThis includes the information or reporting mechanisms the project manager will give to the Project Board in order to review the status of the project and to determine whether continued business justification for the project exists.Close ProjectThis ensures that the project is completed in a controlled manner if the project work is completed as planned or if it is no longer viable. More specifically, activities are defined for the acceptance of the project, as well as for the project manager to archive documents and release project resources. 2- 27 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Themes (guidelines to aid project goal achievement)Business CaseAlthough the business case is an important PRINCE2® process, its importance is also underscored as a theme that asks the questions, “Why should this project be funded?” and “Why should this project continue to be funded?” It is a key document that not only justifies the initiation of a project, but also ensures that the project can deliver its intended value. OrganizationThe organization theme attempts to answer the question, “Who is involved with the project?” Under this theme, roles, responsibilities, and accountabilities are defined. 2- 28 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Themes (guidelines to aid project goal achievement)RiskAll projects entail elements of risk, and the risk theme attempts to manage uncertainty by answering the question, “What if . . . .?” The approach to managing risk under PRINCE2® includes identifying, assessing, and managing risk systematically and proactively. QualityThe quality theme attempts to ensure that the project is not only completed on time and within budget, but that it also is completed within standards so that the product fits its intended use or purpose 2- 29 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Themes (guidelines to aid project goal achievement)PlanningThe planning theme provides clear communication by attempting to answer the questions, “Who does what?” and “When will it get done?” Plans also provide control for the delivery of the project’s product and to determine whether the cost, time, quality, risk, work performance targets are achievable by providing a reference point to measure progress against. ChangeOften changes are required to the project’s plans and target objectives. Requests for changes can come from any of the project stakeholders, so a systematic way to document, manage, and decide whether proposed changes are necessary is warranted. Subsequently, the change theme attempts to manage and control changes to the project as they occur. 2- 30

The PRINCE2® – Themes (guidelines to aid project goal achievement)ProgressMetrics provide a means to measure a project’s achievement and forecast whether the project’s progress is going according to the approved plan. The progress theme attempts to answer the questions, “Where is the project now?” and “Where will it end up?” 2-31

The PRINCE2® – Principles (Universal guidance for all projects)Business Case DrivenThe business case is a key document that is developed at the beginning of the project and must be continually justified throughout. Therefore, it is a key driver for starting the project and for continued funding of the project. Product FocusProjects are not just a series of activities or tasks, but rather are undertaken to produce a product. PRINCE2® projects emphasize the design and delivery of a quality product. 2- 32 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Principles (Universal guidance for all projects)Lessons LearnedPRINCE2® is based on proven best practices. Therefore, documented experiences in terms of lessons learned are an important component for the PRINCE2® methodology that are sought throughout the life of the project. Manage the StageAt each stage of the project, the Project Board reviews the project’s progress in comparison to the business case. Each stage is planned, monitored, and controlled. 2- 33 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Principles (Universal guidance for all projects)Adapt to the ProjectThe PRINCE2® methodology can be tailored to projects large or small. The methodology can be scaled to the size of the project and should be flexible in terms of the risks and environment unique to the project.Manage by Exception Tolerances are defined and used to empower project stakeholders by allowing them to make decisions without having to ask for approval from the next higher level of authority. 2- 34 Copyright 2015 John Wiley & Sons, Inc.

The PRINCE2® – Principles (Universal guidance for all projects)AccountabilityPRINCE2® projects should have clear roles and responsibilities. Stakeholders need to know their role as well as everyone else’s. The Project Board includes executive sponsorship that defines the project’s objectives and ensures that the project remains viable. Internal or external suppliers provide resources, skills, or the knowledge to deliver the project’s products, while users represent those stakeholders who will benefit from the delivery of the final product. 2- 35 Copyright 2015 John Wiley & Sons, Inc.

PMBOK vs PRINCE2 PRINCE2 and PMBOK are not conflicting or competitive or mutually exclusive.  PMBOK’s strength is in teaching the knowledge base of the project management profession PRINCE2’s strength is in setting out a standard approach to running a project.  Both PRINCE2 and PMBOK fall short of doing both of these to the same degree. In this sense they are complementary and should and can be used as such; PRINCE2 as a supplement to the body of knowledge \PMBOK as a knowledge base upon which to implement PRINCE2 There should be a continuous tailoring of your approach based on the size, type and complexity of the project, and any existing organizational project management methodology.Copyright 2010 John Wiley & Sons, Inc. 36

PRINCE2 vs PMBOK Copyright 2010 John Wiley & Sons, Inc.37PRINCE2`PMBOKA process based project management methodology A knowledge based approach to project management A series of management processes defining what must be done, when and how it must be done and by whom over the life of a project Describes core practices and a wider range of techniques that can be applied to manage a project Prescriptive, but tailorableDescriptiveDefines the roles of everyone involved in a project Focuses on the project manager's role

Figure 2.5 The Systems Development Life Cycle 2- 38 Copyright 2015 John Wiley & Sons, Inc.

Systems Development Life Cycle (SDLC) Although projects follow a project life cycle, information systems development follows a product life cycle. The most common product life cycle in IT is the systems development life cycle, which represents the sequential phases or stages an information system follows throughout its useful life. The SDLC establishes a logical order or sequence in which the system development activities occur and indicates whether to proceed from one system development activity to the next PlanningThe planning stage involves identifying and responding to a problem or opportunity and incorporates the project management and system development processes and activities. A formal planning process ensures that the goal, scope, budget, schedule, technology, and system development processes, methods, and tools are in place. 39

Systems Development Life Cycle (SDLC) AnalysisThe analysis phase attempts to delve into the problem or opportunity more fully. For example, the project team may document the current system to develop an "as is" model to understand the system currently in place. ,Systems analysts will meet with various stakeholders (users, managers, customers, etc.) to learn more about the problem or opportunity. This work is done to identify and document any problems or bottlenecks associated with the current system.The "as is" analysis is followed by a requirements analysis where the specific needs and requirements for the new system are identified and documented. Requirements can be developed through a number of means—interviewing, joint applications development (JAD), conducting surveys, observing work processes, and reading company reports. Using modeling techniques, the current system, user requirements, and logical design of the future system called the "to be" system are represented and documented 40

Systems Development Life Cycle (SDLC) DesignThe project team uses the requirements and "to be" logical models as input for designing the architecture to support the new information system. This architecture includes designing the network, hardware configuration, databases, user interface, and application programs. Implementation Includes the development or construction of the system, testing, and installation. In addition, training, support, and documentation must be in place.Maintenance and Support Once the system has been implemented, it is said to be in production and becomes a legacy systemChanges to the system, in the form of maintenance and enhancements, are often requested to fix any discovered errors (i.e., bugs) within the system, to add any features that were not incorporated into the original design, or to adjust to a changing business environment. 41

Implementing the SDLC Defines all of the subphases and deliverables associated with the Execute and Control Project Management Life Cycle phase.Structured Approach to Systems DevelopmentWaterfall MethodIterative DevelopmentRapid Applications Development (RAD)Prototyping Spiral DevelopmentExtreme Programming2- 42 Copyright 2015 John Wiley & Sons, Inc.

Figure 2.7 – The Waterfall Model 2- 43 Copyright 2015 John Wiley & Sons, Inc.

Waterfall Method A structured approach to systems development has been around since the 1960s and 1970s, when large mainframe applications were developed. The waterfall model illustrated was developed as a simple and disciplined method that follows the SDLC closely in a very sequential and structured way. The idea of a waterfall is a metaphor for a cascading of activities from one phase to the next where one phase is completed before the next phase is started.44

Waterfall Method The waterfall model stresses a sequential and logical flow of software development activities. Design activities or tasks begin only after the requirements are defined completely. The building or coding activities will not start until the design phase is complete. Although there is some iteration where the developers can go back to a previous stage, it is not always easy or desirable. One characteristic of the waterfall model is that a great deal of time and effort is spent in the early phases getting the requirements and design right because it is more expensive to fix a bug or add a missing requirement in the later phases of the project. 45

Waterfall Method - Disadvantages Critics of the structured approach to systems development argue that it takes too long to develop systems and that this approach does not embrace the idea that changing requirements are inevitable.Inexperienced developers often have the false belief that if they ask the users what they want, they will be rewarded with a set of clear, accurate, and complete requirements. In truth, most users do not know or are unable to articulate their needs early on in the project. And if they do, those requirements will most likely change later on. 46

Waterfall Method - Advantages An advantage of the waterfall model is that it allows us to plan each phase in detail so that the project schedule and budget can be computed by summing the time and cost estimates for all the tasks defined in each phase. Provides a solid structure that can minimize wasted effort, the Waterfall model may work well when the project team is inexperienced or less technically competent.This approach is still used today, especially for large government systems and by companies that develop shrink wrap or commercial software packages.A structured approach is suitable when developing large, more complex systems where one assumes, or at least hopes, that the requirements defined in the early phases do not change very much over the remainder of the project. 47

Waterfall Method - Disadvantages Users tend to be involved at three main points during a Waterfall project: 1) when they are needed to define the requirements (i.e., features and functionality) of the software, 2) when users ask for changes to the requirements, and 3) at the end of the project when the software is delivered. Many times this has resulted in strained relationships between users and developers. Users may not have articulated everything they want, and developers become resistant to making any changes later on. 48

Waterfall Method - Disadvantages Adding new requirements or changing software that has already been written adds to the schedule and cost of the project. As a result, a new system may be delivered that does not meet the users’ needs.Another issue is that the potential value of the project can only be attained at the end of the project when the system with all its defined requirements is delivered. For many projects, this could be months or years.49

Iterative Systems Development Critics of the structured approach to systems development argue that it takes too long to develop systems and that it does not embrace the idea that changing requirements are inevitable. Inexperienced developers often have the false belief that if they ask the users what they want, they will be rewarded with a set of clear, accurate, and complete requirements. In truth, most users do not know or are unable to articulate their needs early on in the project. If they do, those requirements will most likely change later on. The main idea behind iterative systems development is shortening the SDLC and embracing the idea that requirements are difficult to define and will change. 50

Iterative Systems Development Rapid applications development (RAD ) was proposed by James Martin in the early 1990s as a less formal way to expedite the SDLC. RAD attempts to compress the analysis, design, build, and test activities of the SDLC into a series of short iterations or development cycles. For example, a small team of users and developers would work closely together to develop a set of system requirements during a workshop. Using tools such as computer- aided software engineering (e. g., CASE) or visual development environments (e. g., .NET), the developers would then work with the users to develop a functional or usable version of the system that might include only 25 per- cent of the total requirements. The development cycle would continue with a second usable version that would include the next 25 percent of the requirements. Subsequent iterations would continue until all of the requirements are included in the system. 51

RAD 52

Iterative Systems Development Prototyping, similar to RAD, is an iterative approach to systems development where the user and developer work closely together to develop a partially or fully functional system as soon as possible. Often, however, a prototype may be developed to discover or refine system requirement specifications that can be used as a model for developing a real system. A team may develop a nonfunctional user interface on a personal computer as a model to define the look, feel, and features of a large, multi-user system.53

Iterative Systems Development 54

Iterative Systems Development Spiral development approach first proposed by Barry Boehm (1988), breaks up a software project into a number of mini-projects that address one or more major risks until all the risks have been addressed. A risk, could be a poorly understood requirement or a potential technical problem or system performance issue. The basic idea is to begin development of a system on a small scale where risks can be identified. Once identified, the development team then develops a plan for addressing these risks and evaluates various alternatives. Next, deliverables for the iteration are identified, developed, and verified before planning and committing to the next iteration.As a result, the completion of each iteration brings the project closer to a fully functional system. 55

Spiral Development 56

Iterative Systems Development Agile systems development methods are becoming an increasingly popular approach to systems development and include various methodologies such as SCRUM, dynamic systems development method (DSDM), and adaptive software development (ASD). One of the most commonly known agile methodologies is eXtreme programming (XP), which was introduced by Kent Beck in the mid-1990s. Under XP, the system is transferred to the users in a series of versions called releases. 57

Iterative Systems Development A release may be developed using several iterations that are developed and tested within a few weeks or months. Each release is a working system that includes only one or several functions that are part of the full system specifications. XP includes a number of activities where the user requirements are first documented as a user story. The user stories are then documented using an object-oriented model called a class diagram. A set of acceptance tests is then developed for each user story. Releases that pass the acceptance tests are then considered complete. 58

Iterative Systems Development Small teams of developers often work in a common room where workstations are positioned in the middle and a workspace for each team member is provided around the perimeter. XP often incorporates team programming, where two programmers work together on the same workstation. Developers often are prohibited from working more than 40 hours a week in order to avoid burnout and the mistakes that often occur because of fatigue 59

The term Agile today is an umbrella term that includes a number of approaches, methods, or ways to develop products or systems. Agile approaches focus on speed and flexibility rather than a rigid development structure. Agile software development has become popular to describe new approaches that focus on close collaboration between programming teams and business expertsVisit www.agilealliance.org for informationAgile Software Development60

Agile Software Development 61

The Agile Manifesto 2- 62 Copyright 2015 John Wiley & Sons, Inc.

Agile System Development 63

SCRUM breaks a software development into a series of iterations or sprints. Each sprint lasts at most 30 days. During each sprint, a set of features are incrementally added to the product under development and a potential release of software is created. The requirements for the product to be developed are held in a product backlog. At the start of a sprint, a sprint planning meeting is held. During the meeting, a set of requirements from the backlog are picked for implementation in the next sprint. The development team decides which requirements they can commit to developing during the next sprint. At the end of a sprint, a sprint retrospective meeting is held to discuss which elements of the process could be improved.Further sprints are then performed until the product backlog of requirements is empty.SCRUM Software Development 64

SCRUM Software Development 65

The Relationship Between the PLC & SDLC The project life cycle (PLC) focuses on the phases, processes, tools, knowledge and skills for managing a project The system development life cycle (SDLC) focuses on creating and implementing the project’s product—the information system.The SDLC is really part of the PLC because many of the development activities occur during the execution phase of the PLC. The last two phases of the PLC, close project and evaluate project, occur after the implementation of the system66

Figure 2.6 – The Project Life Cycle (PLC) and the Systems Development Life Cycle (SDLC) 2- 67 Copyright 2015 John Wiley & Sons, Inc.

Extreme Project Management (XPM) A new approach & philosophy to project management that is becoming increasingly popularCharacterizes many of today’s projects that exemplify speed, uncertainty, changing requirements, and high risksTraditional project management often takes an orderly approach while, XPM embraces the fact that projects are often chaotic and unpredictableXPM focuses on flexibility, adaptability, and innovationXPM takes a more holistic view of planning and managing projectsExpects requirement changes so planning is an iterative processEnables people to discover best solutions and self-correct themselves as needed 68

Extreme Project Management (XPM) A visual comparison between the traditional project management approach and the extreme project management.In the traditional approach, the project phases look like belowIn the extreme approach, a project will take the following form69

Extreme Project Management (XPM) In extreme project management methodology, there are no fixed project phases and fixed set of guidelines on how to execute the project activities.Rather, extreme methodology adapts to the situation and executes the project activity the best way possible.By nature, extreme project management methodology does not have lengthy deadlines or delivery dates. The delivery cycles are shorter and usually they are 2 weeks.Therefore, the entire project team is focused on delivering the scope of the delivery in short term. This allows the team to welcome any scope or requirement changes for the next delivery cycle. 70

Extreme Project Management (XPM) One way to compare traditional project management and extreme project management is through a comparison between classical music and jazz. Extreme project management is like jazz music.The team members are given a lot of freedom to add their variety to the project team. Whenever a team member feels making a decision that will add value to the overall project, it is allowed by the project management.In addition, each individual of the project team is responsible for the management of their own assignment and the quality of the same.In contrast, the traditional approach is much more streamlined, well-defined approach where the project manager guides the entire team towards project goals.In extreme project management approach, team members collectively share the project management responsibilities. 71

Extreme Project Management (XPM) Mindset is the most critical factor when it comes to extreme project management. In extreme approach, things are done totally a different way, when compared to tradition approaches. Therefore, changing the mindset of the project team is one of the main requirements and responsibilities of the management team. The team should undergo a comprehensive training on extreme approach in order to understand the basics and core principles of the approach.In this training, the individuals also get to gauge themselves and see whether they are a fit or not. 72

Extreme Project Management (XPM) When it comes to changing the mindset, consider the following rules as the ground rules for extreme approach for project management.Requirements and project activities being chaotic is normalUncertainty is the most certain characteristic of an extreme projectThis type of projects are not fully controllableChange is the king and you need to welcome it every possible wayThe feeling of security is increased by relaxing the project controls73

Extreme Project Management (XPM) Self-management is one of the key aspects of extreme project management.There is no central project management authority in such projects. The project manager is just a facilitator and a mentor.Therefore, the project management responsibilities are distributed among the project team members. Each member of the project should execute their management responsibilities and indirectly contribute to the management function of the project. 74