Project Management Processes

Project Processes
 A process is a series of actions directed toward a

particular result/with a common, parent goal to create a
result
 All projects, from technology to architecture, are
composed of processes.
 processes are not the individual activities, but the control
of individual activities to complete a project phase.
 Project management process groups progress from
initiating activities to planning activities, executing
activities, monitoring and controlling activities, and
closing activities.
2
3
Project Management Process Groups
■ Initiating The project is defined and authorized.
■ Planning Project objectives are determined, as well as
how to reach those objectives with the given constraints.
■ Executing The project is executed utilizing acquired
resources.
■ Monitoring and controlling Project performance is
monitored and measured to ensure the project plan is being
implemented to design specifications and requirements.
■ Closing The project, its phases, and contracts are
brought to a formal end.
4
Process Groups
 process groups are not solo activities, groups are a collection of
activities that contribute to the control and implementation of
the project management life cycle.
 The output of one process group will act as input for another
process group. For example, one of the outputs of the initiating
process is the project charter. The charter is thus input for the
planning processes, being that it authorizes and sanctions the
project
 the project manager, and the resources required to complete the
project work.
 Not only will process groups overlap, but some process groups
may be repeated based on the activities within the project
5
Process groups may overlap other
process groups.
6
Initiating Process Group
 include defining and authorizing a project or project phase.
 Initiating process takes place during each phase of a project. Therefore, you
cannot equate process groups with project phases.
 there can be different project phases, but all projects will include all five
process groups. For example, project managers and teams should
reexamine the business need for the project during every phase of the
project life cycle to determine if the project is worth continuing. Initiating
processes are also required to end a project Someone must initiate activities
to ensure that the project team completes all the work. Documents lesson
learned, assigns project resources and that the customer accepts the work
 This process group launches the project process and allows the project
manager to have the authority to begin the project
 a level of authority is transferred from senior management to the project
manager to lead the organization to the desired future state.
7
Planning processes
 Includes devising & maintaining a workable scheme to ensure that
the project addresses the organization's need.
 There are several plans for projects, such as the scope
management plan, schedule management plan, cost management
plan. procurement management plan, and so on, defining each
knowledge area as it relates to the project at that point in time.
 E.g. a project team must develop a plan to define the work that
needs to be done for the project. To schedule activities related to
that work to estimate costs for performing the work, to decide
what resources to procure to accomplish the work, and so on, To
account for changing conditions on the project and in the
organization . projcet teams often revise plans during each phase
of the project life cycle
8
Executing processes
 include coordinating people and other resources
to carry out the various plans and produce the
products, services or results of the project or
phase.
 examples of executing processes include
acquiring and developing the project team.
performing quality assurance, distributing
information, managing stakeholder expectations,
and conducting procurements
9
Monitoring and controlling
processes
 include regularly measuring and monitoring
progress to ensure that the project team meets
the project objective. The project manager and
staff monitor and measure progress against the
plans and take corrective action when necessary.
 A common monitoring and controlling process is
reporting performance, where project
stakeholders can identify any necessary changes
that may be required to keep the project on track
10
Closing processes
 include formalizing acceptance of the project or
project phase and ending it efficiently.
 Administrative activities are often involved in this
process group, such as archiving project files,
closing out contracts, documenting lessons
learned and receiving formal acceptance of the
delivered work as part of the phase or project
11
12
Identifying Needs
 A project is generally called upon to provide a solution to a
problem or to take advantage of an opportunity
 The needs of the current state are then answered by the
deliverables of the proposed project which needs might have to
do with:
■ Reducing costs
■ Increasing revenues
■ Eliminating waste
■ Increasing productivity and efficiency
■ Solving a business or functional problem
■ Taking advantage of market opportunities
13
Creating a Feasibility Study
 A feasibility study is conducted to prove a
problem actually exists, document the
opportunities at hand, and then determine if a
project can be created to resolve the problem or
take advantage of the opportunity cited.
 A feasibility study may also look at the cost of the
solution in relation to the possible rewards gained
by its implementation.
14
Identifying the Business Needs
 The business needs will examine the problem,
opportunity, and solution to see how the
potential project and its expected outcome fits
within the realm of the business vision and goals.
 The business level of an organization asks, “Why
is this important?” The focus of the business level
is vision and strategy, so the results of the project
must support that level. Projects must align with
the strategy of the organization.
15
Creating a Product Description
 The initial product description will describe what
the expected outcome of the project is to be.
 This may be a service, a product, or even a
description of the desired future state.
 The initial product description does not have to be
an exact specification document of what the project
will create, though in some instances it may.
 Typically, the product description describes the
high-level solution or realized opportunity that the
project will accomplish
16
Creating a Project Charter
 The project charter authorizes the project, officially
naming the project manager and authorizing the project
work
 project manager and the project management team may
write the project charter, but the charter’s approval and
funding are above the project’s boundaries.
 the project charter should be approved and funded by an
individual within the organization that has the proper
authority to authorize the project manager, the needed
funds, and the resources that will be utilized within the
project work.
17
Analyzing Stakeholders
 Steps to Analyzing Stakeholders:
1. List all the individuals and groups that have any
stake in your project.
2. Specify the impact of project success for each.
3. Specify the impact of project failure for each.
4. Understand and leverage the contributions of
each individual or group that stands to benefit
from project success.
5. Understand and leverage the contributions of
each individual or group that stands to benefit
from project failure.
18
 List All the Stakeholders.
 List each stakeholder along with their stake in
the project.
 Stake holders consist of developers, customers,
managers, and other project support personnel.
 Not all stakeholders benefit from your project’s
success!
19
 Specify Successful-Project Impact on Each
Stakeholder.
 For each stakeholder, list what that individual or
group stands to gain by your project’s success.
 For a development team, this may be an
elevated stature in an organization. For rival
teams, this may mean fewer resources on the
next project.
20
 Specify Unsuccessful-Project Impact on Each
Stakeholder.
 For each stakeholder, list what that individual or
group stands to gain by your project’s failure.
 Other development teams within the
organization may stand to gain by your failure.
21
 Leverage the Input and Contributions of
Stakeholders.
 Stakeholders are most effective when they are
vested in the project.
 Use stakeholder input when making decisions,
but be careful not to allow management by
committee.
22
 Minimize the Impact of Stakeholders That Benefit
from Project-Failure.
 Don’t underestimate the impact of any
stakeholder.
 Keep communication lines open to allow you to
make informed decisions.
23
Balancing Project Needs
 Guidelines to Balancing Project Needs:
 Always remember the feature/resources/time
triangle.
 Recognize productivity versus quality tradeoffs in
the process and project
 Consider the cultural versus technical tradeoffs that
go with the project.
 Balance meeting time with individual work time.
 Always consider tradeoffs before making a decision.
24
 Remember the features/resources/time triangle.
 The triangle is best used to estimate the impact
of more features, or less time.
 Adding resources (especially people) without
increasing time, will not always create a feasible
triangle.
25
 Productivity vs. Quality Tradeoffs.
 Overdoing quality building activities, like code
reviews, can lead to decreased productivity.
 Making productivity a goal can harm quality.
 The development team should implement
everything that they can implement well.
26
 Cultural vs. Technical Tradeoffs in Project
Decisions.
 Making decisions based only on technical facts
may hurt the team culture.
 Very important in role and task changes.
(Changing team roles to compensate for slower
developers).
27
 Meeting Time vs. Individual Work Time.
 Meetings are important for communication.
 Too many meetings can lead to unproductive
drudgery.
 Too few meetings can mean the loss of
important arenas communication.
28
 Always Consider Tradeoffs Before Making a
Decision.
 Almost every decision made during a project
has ramifications to consider.
 Be sure to consider your product, process, and
project in mind when making decisions.
29
Assessing Project Risks
 Steps to Assessing Risk:
1. List all significant risks you think might
impact the project.
2. Rank the risks from most likely to least
likely.
3. Rank each risk from the most negative
impact to the least negative impact.
4. Form a combined list of the risks, ranking of
each based on the sum of its rank on the lists
formed in Steps 2 and 3.
5. Sort the combined list in ascending order.
30
 List the Risks.
 Identify a starting set of risks you feel pertain to
your project.
 Don’t limit yourself to the top five or ten.
 List all risks you think need to be considered.
31
 Rank the Risks by Likelihood.
 Rank the most likely 1, the second most likely
2, and so on until all risks are ranked.
 When ranking, focus on likelihood and ignore
any other considerations.
 The rankings should be in relation to each
other, not probability of occurrence.
32
 Rank the Risks by Impact.
 The risk with the highest impact should be
ranked 1, the second highest impact should be
ranked 2, and so on for each risk.
 Base this ranking solely on impact and ignore
likelihood.
33
 Combine the Risk Likelihood and Risk Impact
Lists.
 For each risk add together its ranking on each
list.
 Sort the new list in ascending order.
 Archive the lists to present to the team during
project launch to increase awareness of the
risks.
34
Specifying Project Payoffs
 Guidelines for specifying project payoffs.
 Organizational payoffs underlie all projects.
 Customers benefit greatly from you project.
 Your team will be seen as a strong team.
 The paradigm and technologies used by your team
make them more valuable professionals.
 Individual and group professional development will
result from this project.
 Process specification, software measurement, and
project assessment will be valuable to the
organization and the team.
35
 Organizational payoffs underlie all projects.
 Project success as seen by the organization’s “bean
counters”.
 This is often not a motivation for software
engineers as they usually see themselves at the
bottom of the organization and received very few
benefits from the top.
36
 Customers benefit greatly from your project.
 Software engineers want to see something that
they have built succeed.
 They will find satisfaction in seeing the product
in the user’s hands.
37
 The paradigm and technologies used by your
team make them more valuable.
 Using new tools and cutting-edge technologies
can bring acclaim to a team.
 Often overlooked as a payoff.
 Encourages applying new ideas rather than the
“same old, same old”.
38
 Individual and group professional development
will result from this project.
 Attention to this development should be part of
your vision of payoffs.
 The team should learn new technical,
managerial, project, process, and measurement
skills.
39
 Process specification, software measurement, and
project assessment will be valuable.
 Helps a project contribute to professional
growth.
 Helps the individual, the team, and the
organization overall.
40
Specifying and Communicating a
Project Vision
 Guidelines for specifying and communicating
your project vision:
 Consider the stakeholders, risks, needs, and
payoffs of the project.
 Include the entire project life cycle in your
vision.
 Make your vision know to the team repeatedly
and consistantly.
41
Project Vision
 Guidelines continued:
 Allow room for team members’ differing vision as
long as they don’t detract from the project success.
 Make “finding a way to succeed” a part of your
vision.
 When you revise your vision, make the new vision
known to the team.
 Document your project vision in a Software Project
Outline that will become a Software Document
42 Plan.
Project Vision
 Consider the stakeholders, risks, needs and
payoffs of the project.
 You should form and document your
vision that includes:
 All the stakeholders.
 All the risks.
 All project, process, and product needs.
 All the tradeoffs.
 All the payoffs.
43
Project Vision
 Include the entire project life cycle in your
vision.
 Your vision should consider the current status
as well as the transitions it will go through as
the project progresses.
 This vision is what, hopefully, your team
members will adopt as their vision. It will
influence motivation, how the team deals with
problems, and team perception.
44
Project Vision
 Make your vision known to the team.
 Your team can’t read your mind. Make your
project vision known.
 Use documents, graphs, charts, and any other
methods needed to communicate your vision to
your team.
45
Project Vision
 Allow room for your team members’ differing visions.
 Different visions may be formed based on differing views of risk
assessment, effort estimation, complexity evaluation, or team
skill set assessment.
 These differences should be viewed as strengths of the team,
leverage them.
46
Project Vision
 When you revise your vision, make the new vision know to
the team.
 Your vision may need to be revised to accommodate project,
process, social, and technical factors.
 Carefully reform your vision based on these new factors, and
convey that new vision to the team.
47
Project Vision
 Document your project vision.
 Create a Software Project Outline (SPO)
containing high-level descriptions of system
requirements, project length, and staffing.
 The SPO should answer the questions who,
what, where, when, how.
 Keep the SPO concise, direct, and easy to read
(usually 5-10 pages).
48
Chapter Key Points
 Carefully identify all stakeholders in your project. Both
supporters and detractors.
 Make certain you understand the needs of your project, and
the tradeoffs for each.
 Risk assessment must be continually considered during your
project.
 Project payoffs need to specified to maximize their positive
effect on the team.
 An accurate vision must be specified in a Software Project
Outline. The SPO needs to be communicated to the team.
49

Project Management Processes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management Processes

Uploaded by

Copyright:

Available Formats

Project Processes

 A process is a series of actions directed toward a

You might also like