Risk Management

Risk Management consists of planning, organizing, leading, controlling, and ensuring quality in such a way to minimize the risks associated with a project. The project plan should identify potential risks and outline activities to be undertaken to avoid the risks. It should also specify what actions to be taken if a risk happens.

The following four step approach can be used:

1) Identify potential risks

Revise task list and schedule
Keep an eye on task where the team has limited expertise
Check for aggressive estimates
Keep an eye on tasks along the critical path
Keep an eye on overloaded resources
Keep an eye on activities with several preceding activities
Keep an eye on activities of lengthy duration
Other projects can give you indications


2) Quantify the risks
For each of the listed risks:
Determine acceptable variations
Associate a probability value to each risk
Associate a cost value to each risk
Assign a priority for each risk


3) Plan
For each of the listed risks:
Identify risk indicators, warning signs
Action Plans to avoid or mitigate risks
Contingencies if the risk happens

4) Monitor and manage risks

Status Reports (section on risks)
Meetings to discuss potential risks
Monitor closely the progress of the project

It is a good idea to start with a brainstorming session to create the initial list. All risks should be kept on the list.

Example.
Risk: Project Manager resigns in the middle of the project
Odds: 20% (Project Manager's change organizations often)
Loss if he quits: $50,000
Probable loss: $10,000

You should insure yourself against a $10,000 lost.

How will we avoid or reduce the risk:
Have contract specifying that the project manager cannot leave.
Have a performance incentive to make the salary more attractive.
Give the project manager sufficient authority and support. Don't make his job more difficult than what it has to be.

Contingency:
If the project manager resigns we have a backup. Jim will be part of the project. He has enough experience to take over if the project manager resigns. This will give us time to get organized.


A student asked a very good question today. As we quantify the risks we will end up with a list of probable losses. Should the anticipated losses be added to the other
costs of the project.

A percentage of the anticipated loss should be added to the other project costs.
The probable cost is actually reduced if you put in place mechanisms to detect the risk, to avoid, to reduce and also contingency plans. This reduces the probability of the risk happening. The new probability value would be used to calculate the probable cost after managing risks.

gb

IT Project Management: my definition

PMI defines a project as: "a temporary endeavour undertaken to create a unique product or service".


I define IT Project Management as "a conscious effort to apply management processes to an IT Project".

My definition of management is simple. You manage when you plan, organize,lead,control,evaluate and ensure quality.

To manage an IT project you must plan, organize, lead, control,evaluate and ensure quality, otherwise you are not managing the project.


--------------------------------------------------------------------------------

Planning

    Defining objectives
    Using standard models and selecting life cycles
    Establishing breakpoints
    Defining deliverables
    Estimates, defining tasks, scedules and budgets
    Gant/ Pert-CPM


Organizing

    Infrastructure related activities
    Hiring personnel
    Sub-contracting
    Team building
    Mandates, roles , responsibilities
    Define resource requirements
    Schedules

Control

    Establishing control mecanisms
    Specifications
    Compare estimates against plans
    Formal sign-offs
    Reports
    Audit and accounting
    


Lead

    Communicate the objectives
    Establish performance levels
    Assign responsibilities
    Motivate
    Direct team work
    Manage meetings
    Manage conflicts
    Manage communications


Evaluate

    Estimates
    Financial evaluation and decision to invest
    Cost accounting
    Project financing
    Project revision


Ensure quality

    Standards
    The Quality System
    Documentation
    Quality Management
    Change Management
    Configuration Management
    Quality Assurance and control

Project Charter BabelTalk

PMBOK states "A project charter is a document that formally authorizes a project." It also adds "It provides the project manager with the authority to apply organizational resources to project activities.".

The Project Charter acknowledges that the project should begin. It announces that the project has received approval and has been endorsed by Senior Management. The project charter identifies a project manager and describes the authority and resources he has in carrying out the project. And more importantly of all it is a statement that ALL the stakeholders agree to abide by.

This announcement that a project exists is very important and so is the clarification of the authority. As you already suspect, many projects lack this important process.

Based on the above definition, the Project Charter can take the form of a memo, a letter, e-mail. It announces the new project and the new project manager.

When working for a external client the contract often acts as the project charter document.


Sounds pretty simple. So where is the problem?

Do a search on "Project Charter" and compare the various definitions you get.

The problems come from the fact that the term Project Charter is often used to describe more widely scoped documents such as the Statement of Work, the Responsibility Matrix, the Communication Plan or even the Project Plan or Contract.
The term is very "loosely used". If someone asks you to prepare a project charter we strongly recommend that you ask what he means or provide a suggested table of contents for approval before starting.

From experience it is not a good idea to bundle too many functionalities under one document. I have seen project charters that detail the work to be done but do not address the issue of project manager's authority.

As a project manager, if you start feeling you are begging the line managers to get things done, it is probably a sign that the "Chartering Process" was not done properly. As a project manager you must be able to negociate but there must also be the organizational structures in place to occasionally exercise authority.

This brings us back to "Process Thinking". There must be a process by which we come to an agreement on a projects goals, the must be a process by which we designate a project manager, the must be a process by which we give the project manager the proper authority.


For the fun of it do a search on "Project Charter" and you will quickly see how there is not a consensus on the purpose, signoffs, management or content required.


GB

Estimates and Precision

The following example is very interesting because it show how overall precision
increases as activites are broken up in tasks.

A project is made up of 4 task. We estimate the time for each of these tasks to be 100 hours, 200 hours, 400 hours and 300 hours respectively. We are pretty sure (99% certain) that our estimates have a precision of plus or minus 30 pourcent.



Total Duration = ______________ ?
Range + ou - = _________________________?

1) What is the estimate for the activities? (X plus or minus Z)
2) What is the precision for the sum of the activities?
3) Note how precision increases with the number of tasks.

Statistical Solution




To cover most cases, we can assume 6 stand.dev = Max - Min.

A 100 hour task varying by 30% represents a minimum of 70 and a maximum of 130.
6 stand.dev = 130-70 = 60 --> stand.dev = 10




Variance = (stand.dev)x(stand.dev)
Variance of a sum is the sum of the variances = 3000





Total Stand.Dev = Square Root of 3000 = 54.7726

We are 99% certain that the total duration will be a value between 1000 - (3*stand.dev) and 1000+(3*stand.dev).

We are 99% certain that the total duration will be a value between 1000 - 164.32 et 1000 + 164.32.


To anwer the initial questions!

1) What is the estimate for the activities? (X plus or minus Z)

1000 plus ou moins 164.32

2) What is the precision for the sum of the activities?
The precision now is 16.4 pourcent.


3) Note how precision increases with the number of tasks.
Starting with a 30% precision on the individual activities we end up with a 16.4 aggregate value.


Although statistics and the real world don't always agree the above method does represent the best unbiased way of determining the increase in precision.

The morale of the story is don't spend too much $+time on individual tasks estimates. The total precision is much higher than the precision of the parts.

----------------------------------

Fully Qualifying estimates is very important. A fully qualified estimate is a central value, a precision and a level of certainty.

I weigh 147 pour + or minus 5 lbs. How sure am I of my estimate. Well, not too sure,
because I haven't been on a scale for 15 years.

John: How long will it take to setup those machines
Jim: 40 hours
John: Exactly 40 hours
Jim: Between 20 and 60
John: Are you sure.
Jim: Hell no! I am just trying to get rid of you. Paul might not even be here tomorrow. So I guess it could take 80 hours or more.

John knows how to qualify estimates. He comes out of the discussion with more info than he would had he taken the 40 hour estimate as granted.


____________________________________

Estimates (basic principles)
 If we want to meet requirements, deliver on time within budgets, we need realistic estimates.
 GIGO (Garbage In Garbage Out)
 A estimate is a prediction that has as many chances of being to high as of being to low. It is a centered value.
 Each phase requires an estimate for the next phase and one for the total project.
 The people doing the work are not the best to consult for an estimate
 use a range rather than a fixed number
 Use the technique appropriate to the phase
 Use several techniques.
 Revise the estimates as the project unfolds
 Gather and analyse data
 Use common sense
 Add amounts for contingencies (Other costs > 20% is reasonable)
 Qualify your estimates fully by specifying the central value, the range of error and the level of certitude.
Items below Not required for Exam....
 You will often see formulas such as below:
New estimate = (Min + 4*PlusProbable + Max)/6
 Range = (Max-Min)
 3 standard deviations = (Max - Min)/2 certain at 99%


Back to work...
Gilbert

What is ISO90003?

What is ISO90003?

The one sentence answer is that "ISO90003 is the guide that will help you interpret
ISO9001:2000 guidelines if you are trying to implement them for Software Development.

ISO has recently released its ISO9001:2000 Quality Management System Requirements.
ISO9001:2000 replaces ISO9000:1994 as the leading standard for Quality Management System.
The document encourages to create a Customer-Focused organization with strong leadership, vision,
goals objectives and plans. It encourages a process view of the organization and systems approach to
quality management. Continual improvement now is part of the standard and people including suppliers
have to be involved in the quality seeking effort.

The ISO9001:2000 document is a drastic improvement of the ISO9000:1994 standard which had 20 requirement elements.
This represents a reduction in documentation requireents.The new standard is organized along five classes instead of the 20 elements. The classes are

1.Quality Management System
2.Management Responsibility
3.Resource Management
4.Product Realization (This is where software is relatively more complex!)
5.Measurement, Analysis and Improvement

Because ISO9001:2000 is generic to all industries and sectors, it is a bit difficult to interpret
in an industry with complex processes such as the Software Development Industry. ISO has very recently (2004-02-15)
released the first edition of ISO/IEC 90003 Software Engineering - Guidelines for the application of ISO9001:2000
to computer software.


The ISO90003 document replaces the older ISO9000-3 guidelines for the application of ISO9001 to the development, supply and
maintenance of software. ISO9000-3 represented the minimal things you should do to obtain quality if you were
building software in a contract environment. We still think that it is one of the best software engineering
documents ever produced by any organization. It did have some weaknesses but if you combined it with other
documents such as 9004-2 for the services industry it provided a very down to earth and much needed standard.

The ISO90003 document examines each of the ISO9001:2000 requirements and explains what should be done
in the software development world to comply to the requirements. It does not, however, tell you how to comply.

For example there is a requirement in 9001:2000 that says that system documentation shall include the
documents needed by the organization to ensure effective planning, operation and control of it's processes.
ISO90003 states the requirement and adds 5 types of documents that could satisfy this requirement.
One of these documents is a description of the life cycle models used.

If you understand ISO9001:2000 ISO90003 gives you ideas on what must be done in the software industry.
The information is useful but unless you have been following the quality movement for a while you might
find it a bit difficult to determine how things must be done. They tell you what... you must figure how.


Usually designing a Quality Management System to a standard would be easy. However, ISO9001:2000 is very
recent and few have implemented it in the software world. It will be very difficult to find samples and templates on
the internet. Designing a QMS compliant to the older versions is easier because of the abundance of sample
quality manuals available.

In their 9001:2000 standard, ISO has embraced a process-oriented approach to quality management.
Because of this process-oriented approach, ISO12207's process-oriented
framework for software life cycle processes, activities and tasks is a great complement to ISO90003.

It is important to know that one cannot be registered to ISO90003. You get a certificate for ISO9001:2000 only.


Final tought!


A Quality Management System is an information system. If you know how to design and implement systems that
answer to requirements you will have no trouble designing an ISO9001:2000 compliant Quality Management System.
No trouble, as long as you can understand requirements that come from a standard. Usually we get a chance
to sit with the client. In this case you must understand Quality and ISO philosophy before you start.

We strongly engourage the use of context diagrams and DFD's when designing the System. This will
lead to a balanced system with all inputs and outputs being addressed. It will make progressive elaboration
of the processes much easier than other methods.

Gilbert Babin
www.productivitytree.com
506 577 1047

What do PMBOK, ISO9001:2000 and CMMI have in common

What do PMBOK2000, ISO9001:2000 and CMMI have in common?

Answer: All three are process-oriented approaches.

PMBOK2000 takes a systematic process-oriented approach to defining what is project management.Five processes are always at play within a project. These five processes (Initiating, Planning,Executing,Controling and
Closing) exist in every phases of a project.





PMI further breaks down project management in 9 knowledge areas.

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project H.R. Management
7. Project Communication Management
8. Project Risk Management
9. Project Procurement Management

Each area is broken down into independent processes.
For example Project Time Management is made up
of 5 processes.

1.Activity Definition Process
2.Activity Sequencing Process
3.Activity Duration Process
4.Schedule Development Process
5.Schedule Control Process

The process approach is very powerful. Each process has defined inputs, outputs and PMI adds Tools and Techniques descriptions for each process.

The PMBOK comprehensively models the processes that constitute project management.

Personally, I find that PMI should have used standard modelling techniques such as DataFlow Diagrams or UML to fully describe the model. Data Flow and Process Modelling techniques lead to more balanced models. Data Flow diagrams have been recently introduced in the PMI-BOK but the inputs and the outputs aren't all balanced which somewhat defeats the purpose of DFDs.


Nevertheless it is a very comprehensive model. It is great for analysis of missing project management elements.

The process approach has led to a more rigorous project management technique. Once one figures out how to implement the processes in the model.

---------------------------------------------------------------------------------------------

ISO9001:2000

ISO has finally understood the importance of processes. It has totally revamped the standard to make it process-oriented. All work in an organization is executed within a process. A process view of the organization
makes it easier to implement and improve quality. ISO9001:2000 also now takes a systems approach to management. It takes into account the interaction between the processes. Organizations must manage,measure,analyze and continually improve the processes in their Quality Management System.

The process approach is a significant paradigm shift from the 20 requirements approach of ISO9001:1994.


The Quality Manual itself can now be written in a procedural fashion or a process oriented fashion.

We have been encouraging organizations to use DFD diagrams to define their Quality Management Systems for several years. Those who use such a structured analysis approach will easily visualize the Quality processes. The DFD approach
leads to a balanced system where all inputs and outputs are treated and accounted for.


ISO90003 has replaced ISO9000-3:1987. ISO9000-3 was a very good standard. ISO90003 will make it easier for those in a process oriented world such as CMMI.

------------------------------------------------------------------------

CMMI

CMMI is as process-oriented as it comes. Most if not all of the CMMI processes are documented with DFD's
making CMMI process areas a very comprehensive balanced system.

CCMI Process Areas and Processes

Process Management

Organizational Process Definition
Organizational Process Focus
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment

Project Management
Project Planning Process
Project Monitoring and Control
Supplier Agreement Management Process
Integrated Project Management
Risk Management
Integrated Teaming
Integrated Supplier Management
Quantitative Project Management

Engineering
Requirements Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation

Support area
Configuration Management
Process and Quality Assurance
Measurement and Analysis
Decision Analysis and Resolution
Organizational Environment
Causal Analysis and Resolution

Each of these main processes are further broken down and a DFD/Contex Diagram is available for each.

Example - Generic Diagram for the Organizational Training process.



------------------------------------------------------------------------

Finally we have a unified approach between the major standards affecting our software engineering functions.
Systems and Process Training is now becoming very valuable. UML still needs some improvements before it
can be used successfully in project management, quality management and cmmi. It is only a matter of
time before we can use UML within PM,QM and CMM. Until then we strongly recommend sticking to the techniques
of Structured rather than object.

Running out of time...

What is the difference between the Project Life Cycle and the Software Development Life Cycle?
How do they fit together?
The project life cycle represents the processes use to manage the work while the SDLC actually represents the work of creating the software system. In the following figure the PLC is represented on the horizontal and the SDLC is represented on the vertical as the execution items.



In reality there is some overlap between the PLC and the SDLC but the above diagram will help you understand where the SDLC fits in within the PLC. During the planning phase you will select a SDLC. The SDLC phases usually represent milestones within your project plan. Often the SDLC phases will become levels in the Work Breakdown Structure. The SDLC represents the Software Development plan.
Selecting a properly documented SDLC makes project planning easy. Several SDLC have step by step guides identifying tasks, activities and deliverables to be completed. You might also be lucky enough to find a methodology identifying controls and execution strategies.

Here is an example of bi-dimensional project planning using SCRUM as a work model.

Introduction

ProductivityTree.com offers training and consulting services in the fields of software and process engineering. Our website is at www.productivitytree.com.

We have started this log for fun. Hopefully some of the information is useful.