Risk register and quantitative risk analysis – managing the project risks

Risk management activities of a project typically includes risk management planning, risk identification, qualitative and quantitative analysis of the risks, risk response planning and monitoring and control of the risks.

Risk register -

Risk register is the most used tool in the above processes starting with risk identification. One can build risk register in a simple excel sheet or it can be put as share point and web based tool. Contents of a risk register should be risk ID, risk description, risk category, risk identified date, cause of the risk, descriptive impact of the risk, risk probability, risk impact, risk score, risk priority, risk response, response owner, response action due date, current status, response impact and comment. These fields are populated in different stages of risk management processes.

Quantitative risk analysis –

Estimating probability and impact values of a risk is a key process in risk management process. This process is called quantitative risk analysis. Accuracy of this process impacts response planning, monitoring and control and overall project execution considerably. It’s better practice to put the guidelines in risk register template itself to avoid any confusion. These guidelines are designed in risk management planning process. Probability value will be always between 0.1 and 0.9. Often risk impacts are not tangible enough to be quantified in terms of EMV(Expected Monetary Value). Therefore, having quantitative risk impact value also between 0.1 and .9 is a good idea and general practice. Quantitative risk analysis is repeated many times during monitoring and control phase of the project and risk register is updated subsequently. A risk turns into issue or opportunity when its probability value becomes 1. Again, it’s a good practice to record risk action response impact during risk response planning as planned impact and response action effect after the risk has occurred as actual impact. We can document this impact in terms of %. This helps evaluating the risk response planning. Risk info which can’t be categorized into any field of the risk register should be added as comment in last. Once the risk turns into issue, it can be maintained or monitored separately as issue log or in the same risk register depending on the choice.

Requirement traceability matrix – a simple and a powerful tool

One of my colleagues quotes in his signature – “Help me understand your requirements clearly.. so I can help you better through our deliverables.” I too think understanding the requirements of your customer is the most important factor in delivering the project successfully in IT business. A requirement traceability matrix (RTM) is a simple and useful tool which facilitates this understanding throughout the lifecycle of the project. A RTM is useful in many ways.

1. It controls the scope creep. This is the main job of a RTM.
2. It gives very clear picture of project in a simple consolidation
3. It is very Helpful in scope verification
4. It helps in building the customer/stakeholders confidence
5. It simplifies the complex requirements
6. It facilitates in dealing with issues and risks

A RTM can be build in a simple excel sheet, in a SharePoint listing or as a part of an enterprise PM tool. Whatever the way one builds a RTM, it will have the references to all the deliverables of all the stages of the project with some meaningful descriptions.

How to develop a RTM -

The business requirements are built in planning phase of the project. They are decomposed into functional requirement/system requirement specification/WBS in planning phase itself as a part of the scope planning. There will be one -many mapping between business requirement and functional requirement usually. The first version of requirement traceability matrix should be built at this point by writing the requirements clearly along with unique requirement traceability numbers in a tabular form. It is also advisable to get the RTM approved by the customer or the responsible stakeholders after completing a project phase. Technical requirements are built during planning/define or design phase of the project depending on the complexity and business need of the project. Functional requirements and technical requirements can have one-many or many-one mapping. Technical requirements can be referred in RTM as a short description with reference to technical or system requirement specification document. HLD and LLD can be referred in RTM with reference numbers and reference pointers. It’s as simple to do as updating an excel cell. HLD and LLD will have one-one mapping with functional/technical requirement usually. Code references should be made with component name and address of the component and unit testing references should be made with testing case number and location of unit testing document. There will be one-one or one-many mapping between technical/functional requirement and code. Requirement to unit testing mapping will be one-many mostly. Finally, functional testing and system/integration testing should be referred with test case numbers and testing document location address or testing references of the testing tool if a testing tool is being used in the project. Some testing tools also provide in-built RTM. There will be one-many mapping between functional and system testing and the requirements.

Learn scrum in half an hour

Scrum is a project management methodology guided by 3 principles – transparency, inspection & adaption.

A cross-functional team delivers potentially shippable product increments in an iterative time-boxes called sprints. Inspect & adapt is a major theme in scrum which gives opportunities to improve in the current project itself. The Scrum methodology involves -

A. Scrum Roles

B. Time-boxes

C. Scrum Artifacts

D. Agile Rules

Scrum Roles

1. Scrum Master –

Scrum Master ensures that the team adheres to values, practices and rules of scrum. Scrum Master helps the team to perform it best in an organizational environment by tackling and resolving the impediments on day-to-day basis.

2. Product owner –

Production owner is the only person responsible for managing the product backlog and maintaining its prioritization. The product owner also ensures that product backlog is visible to everyone including the team and other stakeholders.

3. Team –

Team does the work. The team turns the product backlogs into increments of potentially shippable functionality every sprint after sprint.

Time boxes

1. Release Planning –

Release planning answers two question.

I. How a vision can be turned into a winning product in best possible way?

II. How the desired customer satisfaction and ROI can be met or exceed?

Release planning establishes the goal of the release, product backlog, major risks, and the overall feature and functionality that the release will contain. It also establishes the probable delivery date cost if nothing changes.

2. Sprint Planning –

Sprint planning has two parts.

I. What –

Input of this part of meeting is product backlog, the latest increment in the product, the capacity of the team, and past performance of the team. The team decides what functionality should be delivered based in the sprint based of these inputs.

II. How –

Team figures out how to turn the selected product backlog into an incremental “done”.

3. Sprint –

Sprint consists of sprint planning meeting, the development work, sprint review and sprint retrospective. Scrum Master ensures that no change is made that would affect the sprint goal.

Daily Scrum – A 15 minute meeting preferably standup to know –

I. What has been accomplished since last daily scrum meeting?

II. What is the plan for today?

III. What are the impediments?

4. Sprint review –

Sprint review meeting mainly reviews what has been done. Team demonstrates the work that is done and answers the questions. The product owner identifies what has been done and what hasn’t been done. The team discusses what went well and what problems they faced and how did they resolve them. The product owner discusses the product backlog. Sprint review meeting provides valuable input to the subsequent sprint planning meeting.

5. Sprint Retrospective –

Sprint retrospective reviews the last sprint in regards to people, relationship, process and tools like scrum team composition, meeting arrangements, definition of ‘done’, method of communication and processes for turning product backlog items into “done”.

Scrum artifacts

Product backlog, release burndown, sprint backlog and sprint burndown are the scrum artifacts.

1. Product backlog –

The requirement of product that the scrum team is developing are listed in product backlog. Product owner is responsible for creating, maintaining and prioritizing the product backlog.

2. Release burndown –

Release burndown is graphically records the remaining product backlog in terms of user story points or effort across the time.

3. Sprint backlog –

Sprint backlog is the list of the tasks the team commits to complete to turn the product backlog items into a ‘done’ increment. Items in sprint backlog should be decomposed enough to understand the changes in progress in daily scrum.

4. Sprint burndown –

Sprint burndown like release burndown is graphical display of sprint work remaining across the time in a sprint.

Sprint Rules

The 12 agile manifesto principals are the guidelines to make sprint rules.

Statement of work and Project charter

Statment of work - Statement of work is narrative description of product and service to be delivered by the project. This is the SOW’s definition by PMI’s PMBOK-IV.
A statement of work for an IT project should contain at least following information.
1. Purpose or goal of the project
2. Project scope
3. Deliverables
4. Cost and schedule information
5. Project success or acceptance criteria
6. Constraints
7. Assumptions
8. Management guidelines

Project Charter - Project charter documents business need, customer's requirements, new product, service or result and other project details as listed below.
1. Project purpose or justification
2. Measurable project objective or success criteria
3. High level requirements
4. High level project description
5. High level risks
6. Summary milestone schedule
7. Summary budget
8. List of stakeholders authorizing the project charter
9. Responsibility and authority level of project manager
10. Project approval requirements

The different between statement of work and project charter is statement of work is prepared by customer or sponsor and it’s used as input to create project charter. Project charter contains risks and project charter formal authorizes the execution of the project.

Use case point analysis - a software estimation technique

The number of use case points of a project is dependent on following factors.

1. The number and complexity of use cases in the application system.
2. The number and complexity of actors in the system.
3. Some non-functional attributes like portability, performance, scalability etc.
4. Environmental factors team’s experience and team motivation.

Complexity of a use case is defined as simple, average or complex depending on the number of transactions in the use case. Extension transaction which starts with result of another transaction shouldn’t be counted usually. Use case points are assigned to a use case based the complexity of the use case as listed in below table.

Unadjusted Use Case Weight
Use Case Complexity	No of Transaction	Weight
Simple	3 or fewer	5
Average	4-7	10
Complex	7 or more	15

Use case points for a use case actor are calculated per below summarized description in below table.

Unadjusted Actor Weight
Actor Type	Example	Weight
Simple	Another System Through API	1
Average	Another System through a protocol, a person through text-base user interface	2
Complex	A person through a graphical user interface	3

Total unadjusted use case point for a software project is calculated as summation of use case point and actor points as shown in below table.

Unadjusted Use Case Point
Sl No	Name	Use Case/Actor	Complexity	Number	Weight	Number*Weight
1	Use Case 1	Use Case	Average	2	10	20
2	Use Case 2	Use Case	Complex	3	15	45
3	Use Case 3	Use Case	Simple	6	5	30
4	Actor 1	Actor	Average	21	2	42
5	Actor 2	Actor	Complex	9	3	27
Total						164

There are 13 parameters in technical complexity with different weight value as listed in fig 4. These factors are assessed to a value between 0-5 depending on individual project requirement. The final technical complexity factor is calculated as TCF = 0.6 + (0.01 * TFactor).

Technical Complexity Factor
Factor	Weight	Assessment(0-5)	Impact
Distributed system	2	0	0
Performance objectives	2	1	2
End-user efficiency	1	3	3
Complex processing	1	4	4
Reusable code	1	4	4
Easy to install	0.5	1	0.5
Easy to use	0.5	1	0.5
Portable	2	4	8
Easy to change	1	5	5
Concurrent use	1	5	5
Security	1	5	5
Access for 3rd party	1	5	5
Training Needs	1	1	1
Total (TFacor)			43

There are 8 parameters in environment complexity with different weight value as listed in fig 5. These factors are assessed to a value between 0-5 depending on the environment in which project is executed. The final environment factor is calculated as EF = 1.4 + (-0.03 * EFactor).

Environment Factor
Factor	Weight	Assessment(0-5)	Impact
Familiar with the development process	1.5	1	1.5
Application experience	0.5	3	1.5
Object-oriented experience	1	2	2
Lead analyst capability	0.5	5	2.5
Motivation	1	2	2
Stable requirements	2	1	2
Part-time staff	-1	1	-1
Difficult programming language	-1	3	-3
Total (EFacor)			7.5

And, finally total use case point of a software project is UUCW*TCF*EF where UUCW is unadjusted use case weight, TCF technical complexity factor and EF is environment factor.

Functional point analysis - A software estimation technique

Functional point is a standard unit of measure that represents functional size of a software application. Functional point analysis quantifies the functionality of a software application from user perspective based on a logical design. It’s technology independent and consistent across the project and across the organization.

There are five standard functions divided into two categories in functional point analysis as named below.

1. Data Function: There are two type of data functions - Internal logical file (ILF) & External interface file (EIF)

a. Internal logical file (ILF) – ILF is a group of data which are logical and user identifiable. Data defined by ILF is maintained through the elementary process occurring within the boundary of application whose functions are being counted.

b. External interface file (EIF) – EIF is also a group of data which are logical and user identifiable just like ILF. Here, the difference is EIF data is maintained outside the boundary of application whose functions are being counted. Based on the count of data element type (DET) and record element type (RET), low, average and high complexity is assigned to a data function - ILF or EIF and based on complexity of an ILF or EIF, function points are assigned to it as per below table.

c. Data element type (DET) – DET is a user recognizable and non-repeatable data of a data function – ILF or EIF.

d. Record element type (RET) – RET is user identifiable subgroup of DETs and it is part or subset of a data function - ILF or EIF.

Data Functions (ILF, EIF)
RETs	DETs				Functional Point
	1-19	20-50	51-51+		Complexity	ILF FP	EIF FP
1	L	L	A		L	7	5
1-5	L	A	H		A	10	7
6-6+	A	H	H		H	15	10

2. Transaction Function There are 3 types of transaction functions - External input (EI),External output (EO) & External inquiry (EQ).

a. External input (EI) – EI is a data entered by the user or data/file fed by an external application.

b. External output (EO) – EO is a report created by the application in consideration where the report contains derived information/data.

c. External inquiry (EQ) – EQ is a report created by the application in consideration where the report doesn’t contain the derived info/data. Based on the count of data element type (DET) and file transaction reference (FTR), low, average and high complexity is assigned to a transaction function - EI, EO or EQ and based on complexity of an EI, EO or EQ, function points are assigned to it as per below table.

d. File Transaction reference (FTR) – A FTR is an either ILF or EIF referenced by the transaction function of the application whose functions are being counted.

Transaction Functions (ILF, EIF)
FTR(EI)	DTE				FTR(EO, EQ)	DET
	1-4	5-15	16+			1-5	6-19	20+
0-1	L	L	A		0-1	L	L	A
2	L	A	H		2-3	L	A	H
2+	A	H	H		3+	A	H	H
Functional Points
Complexity			EO FP		EQ FP		EI FP
L			4		3		3
A			5		4		4
H			7		6		6

Count of data functions and transaction functions will give the total unadjusted function point count which can be put as in below table

Sl No.	File/Trans Name	Function Type(Data/Trans.)	Fn Type Name (ILF,EIF,EI,EO,EQ)	DET	RET	FTR	Complexity	Function Point
Total Unadjusted Function Point

There are also some other factors which influence the functional size of a software application. It's called value adjustment factor as a group. There are 14 parameters in the value adjustment factor known as general system characteristics listed as in below table.

General System Characteristics(GSC)	Weight(0-5)
Data Communication
Distributed data processing
Performance
Heavily Used Configuration
Transaction Rate
Online data entry
End user efficiency
Online update
Complex processing
Reusability
Installation ease
Operational ease
Multiple sites
Facilitate change
Total Degree of Influence
Variable Adjustment Factor

These characteristics are given weight value of 0-5. Value adjustment factor is calculated as VAF = (TDI * 0.01) + 0.65

And, final function point count of a software application is derived as UFPC*VAF where UFPC is unadjusted function point count and VAF is value adjustment factor.