Post on 19-Mar-2018
Information Technology Project Management – Fifth Edition
By Jack T. MarchewkaNorthern Illinois University
Copyright 2015 John Wiley & Sons, Inc.2-1
Introduction Project Methodology
A strategic-level plan for managing and controlling the project
Game plan for implementing project and product lifecycles Recommends 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 Points
Projects 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 deliverables Allows the organization to evaluate project performance and take
immediate action to correct errors or problems or not proceed to the next phase
Fast Tracking Starting the next phase of a project before approval is obtained for
the current phase Can be used to reduce the project schedule Can be risky and should only be done when the risk is acceptable
2-7 Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Define and Plan Define Project Goal
The project goal should be focused on providing business value to the organization Provides a clear focus and drives the other phases of the project Tells us how we will know if this project is successful given the
time, money, and resources invested Alternatives 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 Project
Project 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.
Resources Resources 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 Plan
Manage the project scope, schedule, budget, and people to ensure the project achieves its goal
Progress must be documented and compared to the baseline plan Project performance must be communicated to all of the stakeholders At the end of this phase, the team implements or delivers a completed
product, service, or information system to the organization. Close and Evaluate Project
Ensures that all of the work is completed as planned Final project report and presentation to the client Postmortem review Lessons 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 Areas1. Project integration management2. Project scope management3. Project time management4. Project cost management5. Project quality management6. Project human resource management7. Project communications management8. Project risk management9. Project procurement management10. Project stakeholder management
2-13 Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas
Integration Management Focuses on coordinating the project plan’s development,
execution, and control of changes. Scope Management
Provides 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 Management Important 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 Management Entails 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 Management Concerned with identifying and responding appropriately to
risks that can impact the project. Procurement Management
Projects often require resources (people, hardware, software, etc.) that are outside the organization. Procurement management makes certain that these resources are acquired properly.
Stakeholder Management Focuses 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.
The Five PMBOK® Project Management Process Groups
A 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 activities Project 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 phase2-19 Copyright 2015 John Wiley & Sons, Inc.
The Five PMBOK® Project Management Process Groups
1. Initiating processes Defining and authorizing a project or project phase
2. Planning processes Devising and maintaining a workable scheme to ensure that the project
addresses the organization’s needs3. Executing processes
Coordinating people and resources to carry out the various plans and produce the products, services or results of the project or phase
4. Monitoring and controlling processes Regularly measuring and monitoring progress to ensure that the project
objectives are met5. Closing processes
Formalizing acceptance of the project or phase, closing out contracts, documenting lessons learned
2-20 Copyright 2015 John Wiley & Sons, Inc.
PRINCE2® PRojects IN Controlled Environments
2-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.
The PRINCE2® – Seven (7) Processes
1. Start Project This is a relatively short process that is focused on developing a
project brief or document that provides business justification for the project.
2. Initiate Project Develop the project brief into a more detailed business case,
which is a key document that lays a foundation for all important project decisions.
3. Direct Project The 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
4. Control Stage During this process, the project manager’s day-to-day activities
are defined as well as how the project tasks will be controlled and monitored.
5. Manage Product Delivery This 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
6. Manage Stage Boundaries This 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.
7. Close Project This 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)
1. Business Case Although 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.
2. Organization The 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)
3. Risk All 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.
4. Quality The 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)
5. Planning The 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.
6. Change Often 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)
7. Progress Metrics 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)
1. Business Case Driven The 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.
2. Product Focus Projects 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)
3. Lessons Learned PRINCE2® 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.
4. Manage the Stage At 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)
5. Adapt to the Project The 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.
6. 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)
7. Accountability PRINCE2® 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.
36
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.
37
PRINCE2 vs PMBOK
Copyright 2010 John Wiley & Sons, Inc.
PRINCE2` PMBOK
A 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 tailorable Descriptive
Defines the roles of everyone involved in a project
Focuses on the project manager's role
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
Planning The 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) Analysis
The 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)
Design The 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 system Changes 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 Development Waterfall Method
Iterative Development Rapid Applications Development (RAD) Prototyping Spiral Development Extreme Programming
2-42 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
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 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
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 DevelopmentSmall 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 experts
Visit www.agilealliance.org for information
Agile Software Development
60
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
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 system
66
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 popular Characterizes many of today’s projects that exemplify speed, uncertainty,
changing requirements, and high risks Traditional project management often takes an orderly approach while,
XPM embraces the fact that projects are often chaotic and unpredictable XPM focuses on flexibility, adaptability, and innovation XPM takes a more holistic view of planning and managing projects
Expects requirement changes so planning is an iterative process Enables people to discover best solutions and self-correct themselves as needed
68