1. Risk Analysis & Success Driven Project Management

2. Why risk analysis
Our experience of project planning shows that the probability of successful implementation of deterministic project schedules and budgets is very low. Therefore project and portfolio planning technology should always include risk simulation to produce reliable results.

3. Risk Simulation
Risk simulation may be based on Monte Carlo simulation or use three scenarios approach that will be described further.

4. Risk Simulation – three scenarios approach
A project planner obtains three estimates (optimistic, most probable and pessimistic) for all initial project data (duration, volumes, productivity, calendars, costs, etc.).
Risk events are selected and ranked using the usual approach to risk qualitative analysis. Usually we recommend to include risk events with the probability exceeding 90% in the optimistic scenario, exceeding 50% in the most probable scenario, and all selected risks in the pessimistic scenario.

5. Risk Simulation – three scenarios approach
The most probable and pessimistic project scenarios may contain additional activities and costs due to corresponding risk events and may employ additional resources and different calendars than the optimistic project scenario. As the result project planner obtains three expected finish dates, costs and material consumptions for all major milestones.

6. Desired Parameters
They are used to rebuild probability curves for the dates, costs and material requirements.
Defining desired probabilities of meeting project targets a project planner obtains desired finish dates, costs and material requirements for any project deliverable.

7. Success Probabilities
If the targets were approved then it is necessary to calculate the probabilities of meeting required project targets. If they are reasonable then they may be accepted.
Probabilities to meet approved project targets we call Success Probabilities. These targets may include all project parameters that will be controlled (profit, expenses, duration, material consumption).

8. Baseline
Target dates do not belong to any schedule. Usually they are between most probable and pessimistic dates. A set of target dates and costs (analogue of milestone schedule) is the real project baseline.
But baseline schedule does not exist!

9. Buffers
We recommend to use optimistic schedule for setting tasks for project implementers and manage project reserves.
Project planner obtains not only the set of target dates but also a critical schedule – a project schedule calculated backward from target dates. The difference between current and critical dates shows current schedule contingency reserves (buffers).

10. Sample Critical Schedule
There are time, cost and material buffers that show contingency reserves not only for a project as a whole (analogue of Critical Chain project buffer) but also for any activity in the optimistic project schedule.

11. Success Probability Trends
The best way to measure project performance is to estimate what is going on with the project success probabilities. If they raise it means that contingency reserves are spent slower than expected, if they drop it means that project performance is not as good as it was planned and corrective actions are needed.

12. Success Probability Trends
Success probabilities may change due to:
Performance results
Scope changes
Cost changes
Risk changes
Resource changes

13. Success Probability Trends
Thus success probability trends reflect not only project performance results but also what is going on around the project.
We consider success probability trends as the really integrated project performance measurement tool.

14. Success Probability Trends
Success probability trends may be used as the only information about project performance at the top management level because this information is sufficient for performance estimation and decision making.

15. Success Driven Project Management
We call the described methodology Success Driven Project Management.

16. Success Driven Project Management
If project performance is estimated by success probability trends then project managers are encouraged to resolve uncertainties ASAP. This can increase success probabilities even with activity finish delays & cost overruns.
Postponing problem activities leads to negative trends in success probabilities.

17. Success Driven Project Management
This attribute of success probability trends is especially useful in new product development project management.
On the corporate level it is very useful to know trends and current probabilities of meeting targets for all portfolio projects.

18. Laws of Project Management
Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever.
When things are going well, something will go wrong. When things just can’t get worse, they will. When things appear to be going better, you have overlooked something.
If project content is allowed to change freely, the rate of change will exceed the rate of progress.
Project teams detest progress reporting because it manifests their lack of progress.
The 90% syndrom is a problem that is particularly symptomatic for the linear waterfall lifecycle
Another variant of Murphy's law
Free change problem must be dealt with even in an iterative and incremental software lifecycle: time-boxed prototyping
Introducing new bugs: This is a significant problem in old systems that did not use encapsulation: Global variables, etc
Problem with hierarchical project management

19. Project Agreement Document written for a client that defines:
the scope, duration, cost and deliverables for the project.
the exact items, quantities, delivery dates, delivery location.
Can be a contract, a statement of work, a business plan, or a project charter.
Client: Individual or organization that specifies the requirements and accepts the project deliverables.
Deliverables (= Work Products that will be delivered to the client):
Documents
Demonstrations of function
Demonstration of nonfunctional requirements
Demonstrations of subsystems

20. Project Management Activities (continued on next slide)
Initiation
Project kickoff
Team formation
Communication
infrastructure setup
Problem statement
definition
Initial milestones
planning
Initial top-level
design

21. Installation
Steady state
Termination
Client acceptance test
Postmortem
Project agreement
Project replanning
Status monitoring
Risk management
Project kickoff

22. Tasks Smallest unit of management accountability
Atomic unit of planning and tracking
Finite duration, need resources, produce tangible result (documents, code)
Specification of a task: Work package
Name, description of work to be done
Preconditions for starting, duration, required resources
Work product to be produced, acceptance criteria for it
Risk involved
Completion criteria
Includes the acceptance criteria for the work products (deliverables) produced by the task.

23. Task Sizes Finding the appropriate task size is problematic
Todo lists from previous projects
During initial planning a task is necessarily large
You may not know how to decompose the problem into tasks at first
Each software development activity identifies more tasks and modifies existing ones
Tasks must be decomposed into sizes that allow monitoring
Work package usually corresponds to well defined work assignment for one worker for a week or a month.
Depends on nature of work and how well task is understood.

24. Action Item
Definition: A task assigned to a person that has to be done within a week or less
Action items
Appear on the agenda in the Status Section (See lecture on communication)
Cover: What?, Who?, When?
Example of action items:
Florian unit tests class “Foo” by next week
Marcus develops a project plan before the next meeting
Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon.
The VIP team develops the project plan by Sep 18