1. The Project Management Discipline
Chapter 7
The Project Management Discipline

2. Purposes of Project Management Discipline
The project management discipline has the following three purposes:
To provide a framework for managing projects
To provide practical guidelines for planning, staffing, executing, and monitoring projects
To provide a framework for managing risk
But it does not cover following issues:
Managing people: hiring, training, coaching
Managing budgets: defining, allocating
Managing contracts with suppliers and customers

3. Discipline Focuses It focuses on: Planning an iterative project
Risk management
Monitoring progress of an iterative project and metrics

4. Planning an Iterative Project
The objectives of project planning are the following:
To allocate tasks and responsibilities to a team of people over time
To monitor progress relative to the plan

5. Two Levels of Plan The development is based on two kinds of plans:
A coarse-grained plan: the phase plan
A series of fine-grained plans: the iteration plans

6. The Phase Plan (Project Plan)
There is only one per development project and it captures:
Dates of the major milestones:
Lifecycle objective (end of inception, project well scoped and funded)
Lifecycle architecture (end of elaborations, architecture complete)
Initial operational capability (end of construction, first beta)
Product release (end of transition and of the cycle)
Staffing profile: which resources are required over time
Dates of the minor milestones: end of each iteration and its primary objective, if it is known

7. The Phase Plan It is produced very early in the inception phase.
It is updated as often as necessary.
It does not require more than one or two pages.
It refers to the vision document to define the scope and assumptions of the project.

8. The Iteration Plan There is one per iteration.
Project usually has two iteration plans “active” at one time:
The current iteration plan
It is used to track progress
The next iteration plan
Built toward second half of current iteration
Ready at the end of the current iteration

9. The Iteration Plan (cont.)
It is built using traditional planning techniques and tools (Gantt Charts, etc.)
It defines the tasks and their allocation to individuals and teams.
The plan contains important dates, such as
major builds,
arrival of components from other organizations,
and major reviews.

10. Project Plan and Iteration Plan
Fine-Grained Plan: Iteration Plan
The iterative process is dynamic.
Thus, the detailed plans (Iteration plans) focus mostly on the current planning horizon.

11. The Concept of Risk
A risk is defined as a variable that can take a value that endangers or eliminates success for a project.
In plain terms, a risk is whatever may stand in our way to success and is currently unknown or uncertain.
We can qualify risks further as direct or indirect:
Direct risk: The project has a large degree of control
Indirect risk: The project has little or no control

12. Risk Attributes We can also add two important attributes:
The probability of occurrence
The impact on the project (severity)
These two attributes can be combined in a single risk magnitude indicator, and five discrete values are sufficient:
High,
Significant,
Moderate,
Minor,
Low.

13. How to Cope with Risks Three main routes are possible: Risk avoidance:
Reorganize project so that it cannot be affected by the risk.
Risk transfer:
Reorganize project so that someone or something else bears the risk (the customer, vendor, bank, or another element).
Risk acceptance:
Decide to live with the risk.
Monitor its symptoms and determine what to do if it materializes.

14. Types of Risks Risks that can be avoided or worked around
Risks that cannot be avoided
“What if the project leader in this 15-person team leaves the company?”
Retire this by preparing a backup person.
From: Software Engineering
An Object-Oriented Perspective
By: Eric J. Braude

15. A Way to Compute Risk Priorities
Likelihood
1 to 10
Impact
Retirement
Cost
Priority Computation
Resulting priority
(1=least likely)
(1=least impact)
(1=lowest cost)
(Lowest number handled first)
Highest Risk 10 1
(11-10) x (11-10) x 1
Lowest Risk
(11-1) x (11-1) x 10
1000
From: Software Engineering
An Object-Oriented Perspective
By: Eric J. Braude

16. From Software Engineering R7 By Sommerville
Risk Management
From Software Engineering R7 By
Sommerville

17. Risk Management Process
Risk identification
Possible project, product and business risks are identified.
Risk analysis
The likelihood and consequences of these risks are assessed.
Risk planning
Plans to address the risk either by avoiding it or minimizing its effects.
Risk monitoring
The risk is constantly assessed an plans for risk mitigation are revised as more information about the risk becomes available.

18. Risks and Risk Types (Risk Identification)
Possible Risks
Technology
Database used cannot process as many transactions per second as expected.
Reused SW components contain defects which limit their functionality.
People
It is impossible to recruit staff with skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organizational
Organization is restructured so that different managements are possible for the project.
Organizational financial problems force reductions in project budget.
Tools
The code generated by CASE tolls is inefficient.
CASE tools cannot be integrated.
Requirements
Changes to requirements which require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation
The time required to developed SW is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

19. Risks Analysis Risk Probability Effects
Financial problems force reductions in project budget.
Low
Catastrophic
It is impossible to recruit staff with skills required for the project.
High
Key staff are ill at critical times in the project
Moderate
Serious
Customers fail to understand the impact of requirements changes.
Tolerable
The code generated by CASE tools is inefficient.
Insignificant

20. Risks Management Strategies
Strategy
Organizational financial problem
Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of business.
Recruitment problems
Alert customer of potential difficulties an possibility of delays, investigate buying-in components
Staff illness
Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs
Requirements changes
Derive traceability information to assess requirements change impact, maximize information hiding in the design.
Database performance
Investigate the possibility of buying a higher-performance database.

21. Risk Factors Risk Type Potential indicators Technology People
Late delivery of hardware of support SW, many reported technology problems.
People
Poor staff morale, poor relationships amongst team members, job availability.
Organizational
Organizational gossip, lack of action by senior management.
Tools
Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations.
Requirements
Many requirements change requests, customer complaints.
Estimation
Failure to meet agreed schedule, failure to clear reported defects.

22. The Concept of Measurement
Why do we measure?
To gain control of a project and therefore to manage it.
To evaluate where we are from the plan’s objectives in terms of completion, quality, and compliance with requirements.
To plan better a new project’s effort, cost, and quality based on experience.
To evaluate the effects of changes and assess how we have improved over time on key aspects of the process’s performance.

23. Examples of Goals
Examples of goals that might be set in a software development effort:
Monitor progress relative to the plan.
Improve customer satisfaction
Improve productivity.
Improve predictability.
Increase reuse
We must translate them into subgoals (or action goals), which identify the actions that project members must take to achieve the goal.

24. Subgoals (Action Goals)
The goal “Improve customer satisfaction” would break down into the following action goals:
Define customer satisfaction.
Measure customer satisfaction over several releases.
Verify that satisfaction improves.

25. Subgoals
Some subgoals (but not all) would require that we collect measurements.
i.e., “ Measure customer satisfaction” can be derived from
A customer survey (customers give marks for different support aspects)
The number and severity of calls to a customer-support hotline

26. What is a Measurement? There are two kinds of measurement (metric):
A measure is a concrete numeric attribute of an entity (e.g., a number, a percentage, a ratio).
i.e., project effort in person-month is a measure of project’s size.
To calculate this metric you would need to sum all the timesheet bookings for the project.
A primitive measure is an item of raw data that is used to calculate a measure.
In the preceding example, the timesheet bookings are the primitive measures.

27. Roles and Artifacts
Not shown here is the Project Reviewer, who is responsible for evaluating project planning artifacts and project assessment artifacts at major review points in the project lifecycle.

28. Key Artifacts of Prj Management Discipline
The software development plan (SDP), which contains several artifacts:
Product acceptance plan
Risk management plan (and risk list)
Problem resolution plan
Measurement plan
The business case
The iteration plans (one per iteration)
The iteration assessment
The (periodic) status assessment
The work order
The project measurements database

29. Workflow in Project Management
End Iteration

30. Conceive New Project
This workflow detail is composed of the activities
identify and assess risks, develop business case, and initiate project,
performed by the project manager
project approval review
performed by the project reviewer.
The purpose of this workflow detail is:
to bring a project from an idea to a point at which a reasoned decision can be made to continue or abandon the project.

31. Evaluate Project Scope and Risk
This workflow detail is composed of the activities
identify and assess risks and develop business case, performed by project manager.
The purpose is:
to estimate the project’s capabilities and characteristics, and the risks associated with achieving them.

32. Develop Software Development Plan
This workflow detail is composed of the activities:
Develop measurement plan
Develop risk management plan
Develop product acceptance plan
Develop problem resolution plan
Define project organization and staffing
Define monitoring and control processes
Plan phases and iterations
Compile software development plan
The purpose is:
to develop the components and enclosures of SDP and then have them formally reviewed for feasibility and acceptability to stakeholders and as the basis for fine-grained plan for the next iteration (the iteration plan)

33. Plan for Next Iteration
This workflow detail is composed of the activities:
Develop iteration plan, develop business case, and the workflow detail develop SDP, performed by project manager
the iteration plan review, performed by project reviewer.
The purpose is:
to create an iteration plan, a fine-grained plan, to guide the next iteration.
After creating the plan, adjustments may be needed to the SDP and the business case.

34. Monitor and Control Project
Composed of the activities:
Schedule and Assign Work,
Monitor Project Status,
Handle Exceptions, Problems, and Report Status,
Project Review Authority (PRA) Review, performed by Project Reviewer.
It captures daily, continuing work of Project Manager and covers:
Dealing with change requests
Monitoring project in terms of active risks and objective measurements of progress and quality
reporting project status to the project review authority
Dealing with issues and problems according to the problem resolution plan
Performed by:
Project Manager

35. Manage Iteration Composed of the activities
acquire staff,
initiate iteration,
and assess iteration, all performed by project manager
iteration evaluation criteria review and the iteration acceptance review, both performed by project reviewer.
contains the activities that
begin, end, and review an iteration.
The purpose is to:
acquire necessary resources to perform the iteration
allocate the work to be done
assess the results of the iteration.

36. Close-Out Phase Composed of the activities:
prepare for phase close-out, performed by project manager
milestone review, performed by project reviewer.
Project manager brings a phase to closure by ensuring the following:
All major issues from the previous iteration are resolved.
State of all artifacts is known.
Required artifacts have been distributed to stakeholders.
Any deployment (e.g., installation, transition, training) problems are addressed.
The project’s finances are settled, if the current contract is ending (with the intent to recontract for the next phase)

37. Close-Out Project Composed of the activities:
prepare for project close-out,
performed by project manager,
project acceptance review,
performed by project reviewer.
Final assessment is prepared for project acceptance review
It marks the point at which customer formally accepts ownership of the software product.

38. Building a Phase Plan (Project Plan)
We need a rough estimate of the “size of the project.”
We must consider:
How high is total effort?
When do we need to finish (date of final release)?
We then work backward from the end date to "plant" tentative dates for the major milestones.

39. Staff/Schedule/Scope Trade-off
Cannot trade staff for schedule
"If it takes nine months for a woman to make a baby, why can't we have nine women produce one in a month?“
As Fred Brooks wrote, "Adding manpower to a late software project makes it later."
Use a cost model, i.e., COCOMO (Constructive Cost Model)
To reach a reasonable ratio in product’s first generation,
we usually must trade off features,
or we must increase reuse

40. The Rubber Profile
We must shape effort profile and refine dates of milestones.
To do this we can start from a typical profile.
Resources
Time
Inception Elaboration Construction Translation
The profile shows the relative duration and effort per phase.

41. The Rubber Profile (cont.)
It is suitable for a project with:
Moderate size and effort
In an initial development cycle
No preexisting architecture
Small number of risks and unknowns
Phase Schedule Effort
Inception % %
Elaboration % %
Construction % %
Transition % %
Relative Weight of the Phases of Schedule and Effort for a Typical Project

42. Adjusting the Rubber Profile
Stretch the inception phase if we
need a long time to scope the project,
find the funding,
conduct market research,
or build an initial proof-of-concept prototype,
Lengthen the elaboration phase, if we
have no architecture in place,
Use new and unknown technology,
and/or have severe performance constraints, a number of technical risks, and a lot of new staff,

43. Adjusting the Rubber Profile (cont)
Shrink the inception and elaboration phases, if
This is the second generation of a product
and we will make no major changes to the architecture,
Shorten the construction phase and lengthen the transition phase if:
we must hit market quickly and plan to finish the product gradually
Stretch the transition phase if:
we have a complex deployment, i.e., replacing an old system without interruption of service

44. Duration of an Iteration
An iteration starts with planning and requirements
and ends with a release, either internal or external.
An iteration should span from two to six weeks, but this varies from project to project.
How quickly we can iterate depends primarily on
the size of the development organization
stability and maturity of the organization
level of automation used by the team to manage code
distribute information
perform testing

45. Number of Iterations (inception)
There will be no real iteration;
no software is produced, and there are only planning and marketing activities.
We will have an iteration for the following:
Building a prototype to convince stakeholders that this idea is a good one
Building a prototype to mitigate a major technical risk such as trying out a new technology or a new algorithm or verifying that a performance objective is attainable
Getting our organization up to speed with tools and process
So that's zero or one iteration.

46. Number of Iterations (Elaboration)
We should plan at least one iteration.
If we have no architecture and deal with new factors: new people, tools, technology, platform, or programming language, then we should plan two or three iterations.
We may need to show a prototype to customer or end users to help them define the requirements better (remember the IKIWISI effect).
We will need an iteration to correct the early mistakes on the architecture.
So this gives us one to three iterations.

47. Number of Iterations (Construction)
We should plan at least one iteration.
Two is more reasonable if we want to allow a better job of integration and testing.
For more ambitious projects, three or more are even better if the organization can support the stress and if there is a sufficient level of automation and process maturity.
So that's one to three iterations.

48. Number of Iterations (Transition)
Plan at least one iteration, i.e., final release after beta.
The realities of the market or the (poor) quality of the initial release will force us to do more iterations.
That's one to two iterations.

49. Number of Iterations (I, E, C, T)
Over the entire development cycle [I, E, C, T], we have three levels:
Low: three iterations [0, 1, 1, 1]
Typical: six iterations [1, 2, 2, 1]
High: nine iterations [1, 3, 3, 2]
We can summarize by saying that "normal" projects have 6 ± 3 iterations.
We call this "six plus or minus three" rule of thumb.

50. Building an Iteration Plan
Follow these four steps:
Determine the iteration scope
What we want to accomplish in the iteration.
Define iteration evaluation criteria
How to evaluate the accomplishments at the end of the iteration;
And specify which artifacts will be worked on.
Define iteration activities
Establish what needs to be done and on which artifacts.
Assign responsibilities
Allocate resources to execute the activities.

51. Iteration in the Elaboration Phase
There are three main drivers for defining the objectives of an iteration in the elaboration phase.
Risk
Mitigate or retire risks as early as you can
Coverage
Address all aspects of the software to be developed
Criticality
Make sure that critical functions or services of system are covered

52. Iteration in the Construction Phase
Risks remain a key driver, especially as new and unsuspected risks are uncovered.
The completeness of use cases also becomes a driver.
We can plan the iterations feature by feature, trying to complete some of the more critical ones early so that they can be tested thoroughly in more than one iteration.
Toward the end of the construction phase, the main goal will be to ensure coverage of full use cases.

53. Iteration in the Transition Phase
The main goal is to finish this generation of the product.
Objectives for an iteration:
Which bugs are fixed and which improvements in performance or usability are included.
If we had to disable features to get to the end of the construction phase on time,
we can now complete them or turn them on if they won’t put system in danger.

54. Detail the Work in the Iteration
After the scenarios or full-scale use cases to be developed have been selected and briefly sketched, we must determine the artifacts that will be affected.
Which classes are to be revisited?
Which subsystems are affected or created?
Which interfaces probably need to be modified?
Which documents must be updated?

55. Summary
The project management workflow of the RUP is useful for balancing competing objectives, managing risk, and overcoming constraints to deliver a product that meets the needs of the customers and the end users.
In an iterative process, the development should be based on a phase plan and a series of iteration plans.
Risk is a driver for planning.
Measurement is a key technique used to control projects.
In building a phase plan, we must assess trade-offs between staff, schedule, and project scope.