Tuesday, July 27, 2010

Software Project Management- Estimation and ISO

1)Bring out the importance of software project estimation in the context of software project management.
Estimation is the basis of project planning because it establishes feasible targets for the cost and the schedule. The projects that are planned and executed based on unrealistic deadlines lead to poor quality and overshooting of budgets and schedules. In order to achieve the planned targets, the estimates may need to be revisited during project execution, to take into account the altered situation and revised assumptions.
For reliable estimation, the scope of the product should be well defined. If the product scope is ambiguous, the estimation may be inaccurate, leading to unrealistic targets. For the product scope to be unambiguous, the statement of scope should be bounded, that is, it should clearly state the quantitative data, the constraints, and the mitigating factors related to the product.
The initial estimation for a project is based on the functional decomposition of the product, which is derived from the bounded statement of scope. Grammatical parse is a simple technique used for performing functional decomposition when given the bounded statement of product scope.
Estimation is necessary for project planning and target setting. However, uncertainty is inherent in any estimate; therefore, multiple methods are used to derive multiple estimates, which are then reconciled. These methods fall under two broad approaches—empirical model approach and decomposition-based approach.
In the empirical model approach, the relationship between size, effort, and project duration is used, in which the size is taken as an input to obtain the overall effort and duration of the project. In the decomposition-based approach, the project is decomposed into smaller work components. Each work component is individually estimated using historical data. The estimates of the work components are then added to obtain the total estimate for the project
1. Do you agree with the statement that an easy and useful way to estimate software efforts and costs is to estimate the lines of code of the software?
The Estimating Life Cycle

Figure 1. Cost Estimate Accuracy by Development Stage
________________________________________


Early uncertainty in cost estimates is due to variances in the input parameters to the estimate. Later uncertainty can be traced back to variances in the estimating models. While at the concept stage, when requirements may be hazy, the general purpose of the new software should be clear. At this point, estimates using informal techniques such as historical comparisons or group consensus should have an accuracy of plus or minus 50 percent. By the time the detailed design is complete, an implementation-oriented estimate will be accurate within plus or minus 10 percent.
Estimating Program Volume
The first step in preparing an estimate is to characterize the project volume. One measure is the number of source lines of code, or SLOC. A SLOC is a human written line of code that is not a blank line or comment. Do not count the same line more than once, even if the code appears several times in an application. We typically work with a related number, thousands of SLOC, or KSLOC, when estimating. SLOC as an estimating metric was popularized by Barry Boehm’s Constructive Cost Model, or COCOMO, model remain the most common estimating approach.
If you know the number of KSLOC your developers must write, and you know the effort required per KSLOC, then you could multiply these two numbers together to arrive at the person months of effort required for your project. This concept is at the heart of all of the estimating models. Table 1 shows some common values that researchers have found for this linear productivity factor. Note that although language affects productivity in terms of functionality per hour, effort measured in terms of effort per line of code is language-independent.
Table 1. Common Values for the Linear Productivity Factor
________________________________________
Project Type Linear Productivity Factor
COCOMO II Default 2.94
Embedded Development 2.58
E-commerce Development 3.60
Web Development 3.30
Military Development 2.77
If you know how many thousands of lines of code (KSLOC) your developers must write and you know the effort required per KSLOC, you can multiply these two numbers together to arrive at the person months of effort required for your project. This concept is at the heart of all of the estimating models.
Suppose we were going to build an e-commerce system consisting of 15,000 lines of code. How many person months of effort would this take using just this equation?
The answer is computed as follows:
Productivity*KSLOC=3.60*15=Effort=54PersonMonths
If all of your projects are small, then you can use this basic equation. Researchers have found, however, that productivity does vary with project size. In fact, large projects are significantly less productive than small projects—probably because they require increased coordination and communication time, plus more rework due to misunderstandings.
Table 2. Typical Size Penalty Factors for Various Project Types
________________________________________
Project Type Exponential Size Penalty Factor
COCOMO II Default 1.052
Embedded development 1.110
E-Commerce development 1.030
Web development 1.030
Military development 1.072
Productivity does vary with project size. In fact, large projects are significantly less productive than small projects—probably because they require increased coordination and communication time, plus more rework due to misunderstandings. The exponential factors above penalize large projects for decreased efficiency.
This productivity decrease with increasing project size is factored in by raising the number of KSLOC to a number greater than 1.0. This exponential factor then penalizes large projects for decreased efficiency. Table 2 shows some typical size penalty factors for various project types.
So, after we do a size penalty adjustment, how many person months of effort would our 15,000 lines of code e-commerce system require? The answer is computed as follows:
Productivity*KSLOCPenalty=3.60*151.030=3.60*16.27=Effort=58.6PersonMonths
All of this is pretty straightforward. The next logical question is, "How do I know my project will end up as 15,000 SLOC?"
There are two main approaches to answering this question: direct estimation and function points with backfiring. Using either approach, the fundamental input variables are determined through expert opinion, often with your developers as the experts.
Normally, the first step in estimating the number of lines of code is to break the project down into modules or some other logical grouping. For example, a very high level breakdown might be front-end processes, middle-tier processes and database code. Your developers then use their experience building similar systems to estimate the number of lines of code required.
We strongly recommend that you obtain three estimates for each input variable: a best case estimate, a worst case estimate and an expected case estimate. With these three inputs, you can then calculate the mean and standard deviation as

The standard deviation is a measure of how much deviation can be expected in the final number. For example, the mean plus three times the standard deviation will ensure that there is a 99 percent probability that your project will come in under your estimate.
2. Discuss the strengths and weaknesses of the main classes of cost estimation models for procedure-oriented software systems. Explain one such method in detail.
3. Describe the attributes of an Object Oriented software develop process. Can the size estimation method described by you above, be Used for such systems? Justify your answer.
4. Suppose that as the project manager you estimate the effort required to develop a software product to be 50 person-months. Can you develop this product by employing: (i) 50 persons for one month (ii) one person for 50 months? Justify your answer in each case.
7. What are the factors influencing the cost estimation of a software product
What is an estimate?

An estimate is the most knowledgeable statement you can make at a particular point in time regarding:
• Ø Effort
• Ø Cost
• Ø scheduling
• Ø staffing
• Ø risk
Software cost estimation
Software cost estimation refers to:
Predicting the resources required for a software development process. It includes an approximate judgment of the cost for a project involving many variables. Often measured in terms of effort (person months or man months).
Software cost estimation is important because without it:
• Software analyst /system engineer cannot make realistic hardware-software tradeoff analysis
• Project managers do not have a clue what is going on, how much effort is required to complete an activity, how much calendar time needed, and what is the total cost of an activity.
It is measured on two bases:
Size-related measures based on some output from the software process.
Function-related measures based on an estimate of the functionality of the delivered software.
Staffing level estimation
Once the effort required to develop a software has been determined, it is necessary to determine the staffing requirement for the project. Putnam first studied the problem of what should be a proper staffing pattern for software projects. He extended the work of Norden who had earlier investigated the staffing pattern of research and development (R&D) type of projects. In order to appreciate the staffing pattern of software projects, Norden’s and Putnam’s results must be understood.

Norden’s Work
Norden studied the staffing patterns of several R & D projects. He found that the staffing pattern can be approximated by the Rayleigh distribution curve (as shown in fig. 11.6). Norden represented the Rayleigh curve by the following equation:

E = K/t²d * t * e-t² / 2 t²d

Where E is the effort required at time t. E is an indication of the number of engineers (or the staffing level) at any particular time during the duration of the project, K is the area under the curve, and td is the time at which the curve attains its maximum value. It must be remembered that the results of Norden are applicable to general R & D projects and were not meant to model the staffing pattern of software development projects.
Putnam’s Work

Putnam studied the problem of staffing of software projects and found that the software development has characteristics very similar to other R & D projects studied by Norden and that the Rayleigh-Norden curve can be used to relate the number of delivered lines of code to the effort and the time required to develop the project. By analyzing a large number of army projects, Putnam derived the following expression:

L = Ck K1/3td4/3

The various terms of this expression are as follows:

• K is the total effort expended (in PM) in the product development and L is
the product size in KLOC.
td corresponds to the time of system and integration testing. Therefore, td can be approximately considered as the time required to develop the software.
• Ck is the state of technology constant and reflects constraints that impede the progress of the programmer. Typical values of Ck = 2 for poor development environment (no methodology, poor documentation, and review, etc.), Ck = 8 for good software development environment (software engineering principles are adhered to), Ck = 11 for an excellent environment (in addition to following software engineering principles, automated tools and techniques are used). The exact value of Ck for a
specific project can be computed from the historical data of the organization developing it.
Putnam suggested that optimal staff build-up on a project should follow the Rayleigh curve. Only a small number of engineers are needed at the beginning of a project to carry out planning and specification tasks. As the project progresses and more detailed work is required, the number of engineers reaches a peak. After implementation and unit testing, the number of project staff falls.

However, the staff build-up should not be carried out in large installments. The team size should either be increased or decreased slowly whenever required to match the Rayleigh-Norden curve. Experience shows that a very rapid build up of project staff any time during the project development correlates with schedule slippage.
It should be clear that a constant level of manpower through out the project duration would lead to wastage of effort and increase the time and effort required to develop the product. If a constant number of engineers are used over all the phases of a project, some phases would be overstaffed and the other phases would be understaffed causing inefficient use of manpower, leading to schedule slippage and increase in cost.
Effect of schedule change on cost
By analyzing a large number of army projects, Putnam derived the following expression:

L = CkK1/3td4/3
Where, K is the total effort expended (in PM) in the product development and L is the product size in KLOC, td corresponds to the time of system and integration testing and Ck is the state of technology constant and reflects constraints that impede the progress of the programmer

Now by using the above expression it is obtained that,

K = L3/Ck3t d4
Or,
K = C/td4

For the same product size, C = L3 / Ck 3 is a constant.

4 4
or, K1/K 2= td2 /t d1
or, K ∝ 1/td4
or, cost ∝ 1/td
(as project development effort is equally proportional to project development cost)

From the above expression, it can be easily observed that when the schedule of a project is compressed, the required development effort as well as project development cost increases in proportion to the fourth power of the degree of compression. It means that a relatively small compression in delivery schedule can result in substantial penalty of human effort as well as development cost. For example, if the estimated development time is 1 year, then in order to develop the product in 6 months, the total effort required to develop the product (and hence the project cost) increases 16 times.
Project scheduling
Project-task scheduling is an important project planning activity. It involves deciding which tasks would be taken up when. In order to schedule the project activities, a software project manager needs to do the following:
1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path. A critical path is the chain of activities that determines the duration of the project.
The first step in scheduling a software project involves identifying all the tasks necessary to complete the project. A good knowledge of the intricacies of the project and the development process helps the managers to effectively identify the important tasks of the project. Next, the large
kdown the tasks
systematically
After the project manager has broken down the tasks and created the work breakdown structure, he has to find the dependency among the activities. Dependency among the different activities determines the order in which the different activities would be carried out. If an activity A requires the results of another activity B, then activity A must be scheduled after activity B. In general, the task dependencies define a partial ordering among tasks, i.e. each tasks may precede a subset of other tasks, but some tasks might not have any precedence ordering defined between them (called concurrent task). The dependency among the activities are represented in the form of an activity network.

Once the activity network representation has been worked out, resources are allocated to each activity. Resource allocation is typically done using a Gantt chart. After resource allocation is done, a PERT chart representation is developed. The PERT chart representation is suitable for program monitoring and control. For task scheduling, the project manager needs to decompose the project tasks into a set of activities. The time frame when each activity is to be
performed is to be determined. The end of each activity is called milestone. The project manager tracks the progress of a project by monitoring the timely completion of the milestones. If he observes that the milestones start getting delayed, then he has to carefully control the activities, so that the overall deadline can still be met.
Work breakdown structure
Work Breakdown Structure (WBS) is used to decompose a given task set recursively into small activities. WBS provides a notation for representing the major tasks need to be carried out in order to solve a problem. The root of the tree is labeled by the problem name. Each node of the tree is broken down into smaller activities that are made the children of the node. Each activity is recursively decomposed into smaller sub-activities until at the leaf level, the activities requires approximately two weeks to develop. Fig. 11.7 represents the WBS of an MIS (Management Information System) software.
While breaking down a task into smaller tasks, the manager has to make some hard decisions. If a task is broken down into large number of very small activities, these can be carried out independently. Thus, it becomes possible to develop the product faster (with the help of additional manpower). Therefore, to be able to complete a project in the least amount of time, the manager needs to break large tasks into smaller ones, expecting to find more
parallelism. However, it is not useful to subdivide tasks into units which take less than a week or two to execute. Very fine subdivision means that a disproportionate amount of time must be spent on preparing and revising various charts.
ig. 11.7: Work breakdown structure of an MIS problem Activity networks and critical path method
WBS representation of a project is transformed into an activity network by representing activities identified in WBS along with their interdependencies. An activity network shows the different activities making up a project, their estimated durations, and interdependencies (as shown in fig. 11.8). Each activity is represented by a rectangular node and the duration of the activity is shown alongside each task.
Managers can estimate the time durations for the different tasks in several ways. One possibility is that they can empirically assign durations to different tasks. This however is not a good idea, because software engineers often resent such unilateral decisions. A possible alternative is to let engineer himself estimate the time for an activity he can assigned to. However, some managers prefer to estimate the time for various activities themselves. Many managers believe that an aggressive schedule motivates the engineers to do a better and faster job. However, careful experiments have shown that unrealistically aggressive schedules not only cause engineers to compromise on intangible quality aspects, but also are a cause for schedule delays. A good way to achieve accurately in estimation of the task durations without creating undue schedule pressures is to have people set their own schedules.
Desi
Design Code Database
Database Part Part 105
45
Specification
15
Design GUI Code GUI Part
Part 45
30
Write User
Manual
60

Integrate and
Test
120
Finish 0
Fig. 11.8: Activity network representation of the MIS problem

Critical Path Method (CPM)
From the activity network representation following analysis can be made. The minimum time (MT) to complete the project is the maximum of all paths from start to finish. The earliest start (ES) time of a task is the maximum of all paths from the start to the task. The latest start time is the difference between MT and the maximum of all paths from this task to the finish. The earliest finish time (EF) of a task is the sum of the earliest start time of the task and the duration of the task. The latest finish (LF) time of a task can be obtained by subtracting maximum of all paths from this task to finish from MT. The slack time (ST) is LS - EF and equivalently can be written as LF - EF. The slack time (or float time) is the total time that a task may be delayed before it will affect the end time of the project. The slack time indicates the “flexibility” in starting and completion of tasks. A critical task is one with a zero slack time. A path from the start node to the finish node containing only critical tasks is called a critical path. These parameters for different tasks for the MIS problem are shown in the following table.
Task ES EF LS LF ST
Specification 0 15 0 15 0
Design database 15 60 15 60 0
Design GUI part 15 45 90 120 75
Code database 60 165 60 165 0
Code GUI part 45 90 120 165 75
Integrate and test 165 285 165 285 0
Write user manual 15 75 225 285 210

The critical paths are all the paths whose duration equals MT. The critical path in fig. 11.8 is shown with a blue arrow.
Gantt chart
Gantt charts are mainly used to allocate resources to activities. The resources allocated to activities include staff, hardware, and software. Gantt charts (named after its developer Henry Gantt) are useful for resource planning. A Gantt chart is a special type of bar chart where each bar represents an activity. The bars are drawn along a time line. The length of each bar is proportional to the duration of time planned for the corresponding activity.

Gantt charts are used in software project management are actually an enhanced version of the standard Gantt charts. In the Gantt charts used for software project management, each bar consists of a white part and a shaded part. The shaded part of the bar shows the length of time each task is estimated
to take. The white part shows the slack time, that is, the latest time by which a task must be finished. A Gantt chart representation for the MIS problem of fig. 11.8 is shown in the fig. 11.9.
Fig. 11.9: Gantt chart representation of the MIS problem
PERT chart
PERT (Project Evaluation and Review Technique) charts consist of a network of boxes and arrows. The boxes represent activities and the arrows represent task dependencies. PERT chart represents the statistical variations in the project estimates assuming a normal distribution. Thus, in a PERT chart instead of making a single estimate for each task, pessimistic, likely, and optimistic
estimates are made. The boxes of PERT charts are usually annotated with the pessimistic, likely, and optimistic estimates for every task. Since all possible completion times between the minimum and maximum duration for every task has to be considered, there are not one but many critical paths, depending on the permutations of the estimates for each task. This makes critical path analysis in PERT charts very complex. A critical path in a PERT chart is shown by using thicker arrows. The PERT chart representation of the MIS problem of fig. 11.8 is shown in fig. 11.10. PERT charts are a more sophisticated form of activity chart.
In activity diagrams only the estimated task durations are represented. Since, the actual durations might vary from the estimated durations, the utility of the activity diagrams are limited.

Gantt chart representation of a project schedule is helpful in planning the utilization of resources, while PERT chart is useful for monitoring the timely progress of activities. Also, it is easier to identify parallel activities in a project using a PERT chart. Project managers need to identify the parallel activities in a project for assignment to different engineers. )

13) You have estimated the nominal development time of a moderate-sized software product to be 10 months. You have also estimated that it will cost Rs.500,000/- to develop the software product. Now, the customer comes and tells you that he wants you to accelerate the delivery lime by 10%. How much additional cost would you charge the customer for this accelerated delivery? ? Irrespective of whether you take less time or more time to develop the product, you are essentially developing the same product. Why then does the effort depend on the duration over which you develop the product?

14) Explain the ISO 9000 registration process and accredition system. Do you think there are any shortcomings of the current accredition system that needs to be addressed?
15) List five salient requirements that a software development organization must comply with before it can be awarded the ISO 9001 certificate. What are some of the shortcomings of the ISO certification process?
SEI Capability Maturity Model

SEI Capability Maturity Model (SEI CMM) helped organizations to improve the quality of the software they develop and therefore adoption of SEI CMM model has significant business benefits.
SEI CMM can be used two ways: capability evaluation and software process assessment. Capability evaluation and software process assessment differ in motivation, objective, and the final use of the result. Capability evaluation provides a way to assess the software process capability of an organization. The results of capability evaluation indicates the likely contractor performance if the contractor is awarded a work. Therefore, the results of software process capability assessment can be used to select a contractor. On the other hand, software process assessment is used by an organization with the objective to improve its process capability. Thus, this type of assessment is for purely internal use.
SEI CMM classifies software development industries into the following five maturity levels. The different levels of SEI CMM have been designed so that it is easy for an organization to slowly build its quality system starting from scratch.
Level 1: Initial. A software development organization at this level is characterized by ad hoc activities. Very few or no processes are defined and followed. Since software production processes are not defined, different engineers follow their own process and as a result development efforts become chaotic. Therefore, it is also called chaotic level. The success of projects depends on individual efforts and heroics. When engineers leave, the successors have great difficulty in understanding the process followed and the work completed. Since formal project management practices are not followed, under time pressure short cuts are tried out leading to low quality.
Level 2: Repeatable. At this level, the basic project management practices such as tracking cost and schedule are established. Size and cost estimation techniques like function point analysis, COCOMO, etc. are used. The necessary process discipline is in place to repeat earlier success on projects with similar applications. Please remember that opportunity to repeat a process exists only when a company produces a family of products.
Level 3: Defined. At this level the processes for both management and development activities are defined and documented. There is a common organization-wide understanding of activities, roles, and responsibilities. The processes though defined, the process and product qualities are not measured. ISO 9000 aims at achieving this level.
Level 4: Managed. At this level, the focus is on software metrics. Two types of metrics are collected. Product metrics measure the characteristics of the product being developed, such as its size, reliability, time complexity, understandability, etc. Process metrics reflect the effectiveness of the process being used, such as average defect correction time, productivity, average number of defects found per hour inspection, average number of failures detected during testing per LOC, etc. Quantitative quality goals are set for the products. The software process and product quality are measured and quantitative quality requirements for the product are met. Various tools like Pareto charts, fishbone diagrams, etc. are used to measure the product and process quality. The process metrics are used to check if a project performed satisfactorily. Thus, the results of process measurements are used to evaluate project performance rather than improve the process.
Level 5: Optimizing. At this stage, process and product metrics are collected. Process and product measurement data are analyzed for continuous process improvement. For example, if from an analysis of the process measurement results, it was found that the code reviews were not very effective and a large number of errors were detected only during the unit testing, then the process may be fine tuned to make the review more effective. Also, the lessons learned from specific projects are incorporated in to the process. Continuous process improvement is achieved both by carefully analyzing the quantitative feedback from the process measurements and also from application of innovative ideas and technologies. Such an organization identifies the best software engineering practices and innovations which may be tools, methods, or processes. These best practices are transferred throughout the organization.
What is ISO 9000?
Quality is something every company strives for and is often times very difficult to achieve. Complications concerning efficiency and quality present themselves everyday in business, whether an important document cannot be found or a consumer finds a product not up to their expectations. How can a company increase the quality of its products and services? The answer is ISO 9000.
As standards go, ISO 9000 is one of the most widely recognized in the world. ISO 9000 is a quality management standard that presents guidelines intended to increase business efficiency and customer satisfaction. The goal of ISO 9000 is to embed a quality management system within an organization, increasing productivity, reducing unnecessary costs, and ensuring quality of processes and products.
ISO 9001:2008 is applicable to businesses and organizations from every sector. The process oriented approach makes the standard applicable to service organizations as well. Its general guidelines allow for the flexibility needed for today's diverse business world.
How does ISO 9000 work?
ISO 9000 is set up as a collection of guidelines that help a company establish, maintain, and improve a quality management system. It is important to stress that ISO 9000 is not a rigid set of requirements, and that organizations have flexibility in how they implement their quality management system. This freedom allows the ISO 9000 standard to be used in a wide range of organizations, and in businesses large and small.
One important aspect of ISO 9000 is its process-oriented approach. Instead of looking at a company's departments and individual processes, ISO 9000 requires that a company look at "the big picture." How do processes interact? Can they be integrated with one another? What are the important aspects of products and services?
Once this process-oriented approach is implemented, various audits can be done as a check of the effectiveness of your quality management system. There are three main types of audits – 1st, 2nd, and 3rd party audits. An internal audit is a 1st party audit. ISO 9000 encourages (and requires) this type of audit so that an organization can get feedback quickly from those who know the company best. However, this audit process cannot be viewed as impartial. Therefore, 2nd party audits allow for a consumer to evaluate the performance on an organization. As an alternative to a 2nd party audit, many companies choose to become certified with ISO 9000 through a 3rd party audit. In this case, an independent certification body comes into an organization and evaluates it in terms of the ISO 9000 guidelines. If an organization meets the requirements of the standard, it becomes certified in ISO 9000 and carries a seal of quality recognized throughout the world.
Why is ISO 9000 important?
The importance of ISO 9000 is the importance of quality. Many companies offer products and services, but it is those companies who put out the best products and services efficiently that succeed. With ISO 9000, an organization can identify the root of the problem, and therefore find a solution. By improving efficiency, profit can be maximized.
As a broad range of companies implement the ISO 9000 standards, a supply chain with integrity is created. Each company that participates in the process of developing, manufacturing, and marketing a product knows that it is part of internationally known, reliable system.
Not only do businesses recognize the importance of the ISO 9000, but also the customer realizes the importance of quality. And because the consumer is most important to a company, ISO 9000 makes the customer its focus.
What are the ISO 9000 Principles?
1. A Customer Focus

As stated before, the customer is the primary focus of a business. By understanding and responding to the needs of customers, an organization can correctly targeting key demographics and therefore increase revenue by delivering the products and services that the customer is looking for. With knowledge of customer needs, resources can be allocated appropriately and efficiently. Most importantly, a business's dedication will be recognized by the customer, creating customer loyalty. And customer loyalty is return business.
2. Good Leadership

A team of good leaders will establish unity and direction quickly in a business environment. Their goal is to motivate everyone working on the project, and successful leaders will minimize miscommunication within and between departments. Their role is intimately intertwined with the next ISO 9000 principle.
3. Involvement of people

The inclusion of everyone on a business team is critical to its success. Involvement of substance will lead to a personal investment in a project and in turn create motivated, committed workers. These people will tend towards innovation and creativity, and utilize their full abilities to complete a project. If people have a vested interest in performance, they will be eager to participate in the continual improvement that ISO 900 facilitates.
4. Process approach to quality management

The best results are achieved when activities and resources are managed together. This process approach to quality management can lower costs through the effective use of resources, personnel, and time. If a process is controlled as a whole, management can focus on goals that are important to the big picture, and prioritize objectives to maximize effectiveness.
5. Management system approach

Combining management groups may seem like a dangerous clash of titans, but if done correctly can result in an efficient and effective management system. If leaders are dedicated to the goals of an organization, they will aid each other to achieve improved productivity. Some results include integration and alignment of key processes. Additionally, interested parties will recognize the consistency, effectiveness, and efficiency that come with a management system. Both suppliers and customers will gain confidence in a business's abilities.
6. Continual Improvement

The importance of this principle is paramount, and should a permanent objective of every organization. Through increased performance, a company can increase profits and gain an advantage over competitors. If a whole business is dedicated to continual improvement, improvement activities will be aligned, leading to faster and more efficient development.
Ready for improvement and change, businesses will have the flexibility to react quickly to new opportunities.
7. Factual approach to decision making

Effective decisions are based on the analysis and interpretation of information and data. By making informed decisions, an organization will be more likely to make the right decision. As companies make this a habit, they will be able to demonstrate the effectiveness of past decisions. This will put confidence in current and future decisions.
8. Supplier relationships

It is important to establish a mutually beneficial supplier relationship; such a relationship creates value for both parties. A supplier that recognizes a mutually beneficial relationship will be quick to react when a business needs to respond to customer needs or market changes. Through close contact and interaction with a supplier, both organizations will be able to optimize resources and costs.
Why is root cause analysis and systemic corrective action so important in management system standards, such as ISO 9001?
When problem solving, it is important to find the cause of problem in order to develop a solution. Sometimes, the most obvious cause is not the right one. This is why ISO 9000 stresses the importance of finding the root cause(s) of a problem. There may be multiple, subtle reasons why a process isn't working correctly, and finding the actual causes will lead a company one step closer to a solution and implementation of corrective actions.
The goal of finding root causes is to improve the way problems are managed. Becoming adept in recognizing the root causes of a problem will lead to a reduced impact, a containment of error, and the prevention of recurrence. Identifying and correcting root causes will also lead to the reduction of unnecessary efforts which in turn will lower the cost of maintaining quality. As more and more corrective actions are taken, processes will become more stable, and continual improvement will face less interruptions.
How does ISO 9000 interact with other standards?

ISO 9000 is the standard for a quality management system that closely resembles many other management systems. These other systems, based on health, safety, the environment, and business continuity, can be integrated into an overarching business management system. Benefits of this system include aligned interests, reduced costs, and improved efficiency. With one of these systems in place, it is easier to implement any of the others; many documents required for a different standard are already prepared, and personnel are already accustomed to the audit process. Using multiple standards will not only increase the efficiency of an organization, but increase the integrity of its operations.
What does ISO 9000 mean to me and my company?
ISO 9000 is a standard created to make the attainment of quality, consistent products easier by providing specific steps for development of an organization's quality management system. This quality management system is meant to monitor the progress of a product or service as it goes through each stage of production, from development to testing to assembly to customer feedback.
One cornerstone of ISO 9000 is continual improvement. No company should ever be satisfied with the conditions of a process at the given moment; they should always be looking for ways to make these processes more efficient and effective. ISO 9000 was written with the business world's insatiable desire for excellence in mind. This is why continual improvement is a requirement of the standard – to inspire progress and the pursuit of perfection.
ISO 9000 is an internationally recognized standard, and that may seem daunting for some smaller businesses. How are they going to implement the same standard adopted by multi-national corporations? Quite easily, actually. ISO 9000 is a flexible standard that lays down requirements for an organization to follow, but allows the organization to fulfill these requirements any way they choose. This increases ISO 9000's scope of effectiveness, allowing a wide range of companies to create quality management systems that match their needs.
ISO 9000 is seen in every sector of the business world, and its success is a testament to its worth. With a focus on customer satisfaction, products and services improve and flourish under ISO 9000's quality management system. With a combination of continual improvement and corrective actions – tenets of ISO 9000 – a business will create processes that run smoothly and efficiently.
How will ISO 9000 benefit my small business?
A good foundation builds a good business, and ISO 9000 is a good foundation for small businesses that want to expand their market. By introducing a quality management system like ISO 9000 to a small business, the quality of processes will increase and costs due to inefficiency will decrease. In addition, a small business will be able to advertise their use of the internationally recognized ISO 9000. This may create business opportunities that were not available before an objectively verified quality management system was in place.
Having management systems in place, such as ISO 9000, will also help when selling a business. The integrity and value of a small business will be apparent with well-documented processes and proof of quality. ISO 9000 will ensure the reputation of your business in any situation.


16) What go you understand by total quality management (TQM)? What are the advantages of TQM? Does ISO 9000 standard aim for TQM?
The basic principles for the Total Quality Management (TQM) philosophy of doing business are to satisfy the customer, satisfy the supplier, and continuously improve the business processes.
Questions you may have include:
• How do you satisfy the customer?
• Why should you satisfy the supplier?
• What is continuous improvement?
This lesson will answer those questions. There is a mini-quiz near the end of the lesson.
Satisfy the customer
The first and major TQM principle is to satisfy the customer--the person who pays for the product or service. Customers want to get their money's worth from a product or service they purchase.
Users
If the user of the product is different than the purchaser, then both the user and customer must be satisfied, although the person who pays gets priority.
Company philosophy
A company that seeks to satisfy the customer by providing them value for what they buy and the quality they expect will get more repeat business, referral business, and reduced complaints and service expenses.
Some top companies not only provide quality products, but they also give extra service to make their customers feel important and valued.
Internal customers
Within a company, a worker provides a product or service to his or her supervisors. If the person has any influence on the wages the worker receives, that person can be thought of as an internal customer. A worker should have the mind-set of satisfying internal customers in order to keep his or her job and to get a raise or promotion.
Chain of customers
Often in a company, there is a chain of customers, -each improving a product and passing it along until it is finally sold to the external customer. Each worker must not only seek to satisfy the immediate internal customer, but he or she must look up the chain to try to satisfy the ultimate customer.
Satisfy the supplier
A second TQM principle is to satisfy the supplier, which is the person or organization from whom you are purchasing goods or services.
External suppliers
A company must look to satisfy their external suppliers by providing them with clear instructions and requirements and then paying them fairly and on time.
It is only in the company's best interest that its suppliers provide it with quality goods or services, if the company hopes to provide quality goods or services to its external customers.
Internal suppliers
A supervisor must try to keep his or her workers happy and productive by providing good task instructions, the tools they need to do their job and good working conditions. The supervisor must also reward the workers with praise and good pay.
Get better work
The reason to do this is to get more productivity out of the workers, as well as to keep the good workers. An effective supervisor with a good team of workers will certainly satisfy his or her internal customers.
Empower workers
One area of satisfying the internal suppler is by empowering the workers. This means to allow them to make decisions on things that they can control. This not only takes the burden off the supervisor, but it also motivates these internal suppliers to do better work.
Continuous improvement
The third principle of TQM is continuous improvement. You can never be satisfied with the method used, because there always can be improvements. Certainly, the competition is improving, so it is very necessary to strive to keep ahead of the game.
Working smarter, not harder
Some companies have tried to improve by making employees work harder. This may be counter-productive, especially if the process itself is flawed. For example, trying to increase worker output on a defective machine may result in more defective parts.
Examining the source of problems and delays and then improving them is what is needed. Often the process has bottlenecks that are the real cause of the problem. These must be removed.
Worker suggestions
Workers are often a source of continuous improvements. They can provide suggestions on how to improve a process and eliminate waste or unnecessary work.
Quality methods
There are also many quality methods, such as just-in-time production, variability reduction, and poka-yoke that can improve processes and reduce waste.
Summary
The principles of Total Quality Management are to seek to satisfy the external customer with quality goods and services, as well as your company internal customers; to satisfy your external and internal suppliers; and to continuously improve processes by working smarter and using special quality methods.
Total Quality Management (TQM) is a management style that implies non-stop process of quality improvement of products, processes and
personnel work. This is a bunch of methodologies that drive company to strategic goals achievement through unceasing quality
development. It is focused on production of goods and services that possess high-quality from viewpoint of customers. TQM was
elaborated on basis of Edward Deming's theory. This philosophy has successfully started many years ago in Japan and USA . TQM has
shown phenomenal results and now it is used in many successful enterprises all across the world. It allows obtaining faster, fundamental
and more efficient business development, because it stimulates production of much better products for better prices.
There are 5 "sicknesses" or mistakes that should be driven out of organization for successful implementation of TQM. If these "sicknesses"
are not eliminated, they can entail failure of TQM and gradually destroy a company. Here are these "sicknesses":
Management of only basic line. Organization that takes care only about basic line of development and manages only numeric
results is doomed to failure. Management is a hard work and manager that works only with numbers lightens his/her task. Actually
manager should know all process workflow and being involved into the process, understand what can be the source of problems
and be an example for subordinates.
Evaluating of activity with a help of quantitative rates system . Evaluating of activity with a help of quantitative rates system.
Evaluating that uses system of quantitative rates, reports, annual reviews of attainments, etc. can cause forced quotes,
classification and ratings that entail unhealthy competition, break of team collaboration within company. Instead of such systems
managers should personally comment employees' work, advice and help to improve it.
Stress on receiving of short-term benefits. If employees have experience of getting fast profits they will try to work in the same
way. Management should convince workers that it is better to prefer long-term and stable growth and improvement than quick,
short-term profits.
Lack of strategy. If there is no any sequence of realizing goals in a company, employees will feel uncertainty about possibility of
constant professional and carrier growth. Organization should have continuously realizing strategic plan where considerable part
should be devoted to questions of quality improvement.
Staff turnover. If high staff turnover within organization is apparent, this indicates serious problems. Eliminating of previous four
sicknesses will help to solve this one. Management should assume the proper arrangement to make employee feel as an
important part of one consolidated team.
Advantages of TQM:
TQM gives some short-term advantages, however majority of advantages is long-termed, and tangible benefits from them appear only after successful realization. In big organizations this process can take few years. Long-term benefits expected from implementation of TQM - higher productivity, higher moral tonus of personnel, decreasing of costs and increasing of consumers' trust.
This will make company popular and increase its status within society. Avoidance of mistakes allows company to save money
and time. Extra resources can be used for range of products and services expansion or for other improvements. TQM creates
atmosphere of enthusiasm and satisfaction with performed job and welcomes awarding bonuses for creative approach to
professional duties.
TQM intensively uses team style of work that allows employees share their experience, use their skills effectively and apply joint efforts for solving issues. As far as team members gain experience of team problem solving they can be a part of cross-department "mega teams" that work at tasks that are beyond of local group possibilities. TQM gives to organization more flexibility in work and problem solving and improve work environment for each employee.
As we can see team collaboration is an important part of TQM philosophy. In order to be efficient each team should be managed properly. For this purpose special software can be used.

Software Project Management-Planning

2)Why is it necessary to plan software projects? What are the broad activities that encompass software project planning? What are the different levels at which software project planning is carried out? List the steps involved in detailed planning?
Project planning is an aspect of Project Management, which comprises of various processes. The aim of theses processes is to ensure that various Project tasks are well coordinated and they meet the various project objectives including timely completion of the project.
Project Planning is an aspect of Project Management that focuses a lot on Project Integration. The project plan reflects the current status of all project activities and is used to monitor and control the project. The Project Planning tasks ensure that various elements of the Project are coordinated and therefore guide the project execution.
Project Planning helps in
- Facilitating communication
- Monitoring/measuring the project progress, and
- Provides overall documentation of assumptions/planning decisions
The Project Planning Phases can be broadly classified as follows:
- Development of the Project Plan
- Execution of the Project Plan
- Change Control and Corrective Actions
Project Planning is an ongoing effort throughout the Project Lifecycle.
“If you fail to plan, you plan to fail.”
Project planning is crucial to the success of the Project. Careful planning right from the beginning of the project can help to avoid costly mistakes. It provides an assurance that the project execution will accomplish its goals on schedule and within budget.
Steps in Project Planning
Project Planning spans across the various aspects of the Project. Generally Project Planning is considered to be a process of estimating, scheduling and assigning the projects resources in order to deliver an end product of suitable quality. However it is much more as it can assume a very strategic role, which can determine the very success of the project. A Project Plan is one of the crucial steps in Project Planning in General!
Typically Project Planning can include the following types of project Planning:
1) Project Scope Definition and Scope Planning
2) Project Activity Definition and Activity Sequencing
3) Time, Effort and Resource Estimation
4) Risk Factors Identification
5) Cost Estimation and Budgeting
6) Organizational and Resource Planning
7) Schedule Development
8) Quality Planning
9) Risk Management Planning
10) Project Plan Development and Execution
11) Performance Reporting
12) Planning Change Management
13) Project Rollout Planning
1) Project Scope Definition and Scope Planning:
In this step we document the project work that would help us achieve the project goal. We document the assumptions, constraints, user expectations, Business Requirements, Technical requirements, project deliverables, project objectives and everything that defines the final product requirements. This is the foundation for a successful project completion.
2) Quality Planning:
The relevant quality standards are determined for the project. This is an important aspect of Project Planning. Based on the inputs captured in the previous steps such as the Project Scope, Requirements, deliverables, etc. various factors influencing the quality of the final product are determined. The processes required to deliver the Product as promised and as per the standards are defined.
3) Project Activity Definition and Activity Sequencing:

In this step we define all the specific activities that must be performed to deliver the product by producing the various product deliverables. The Project Activity sequencing identifies the interdependence of all the activities defined.
4) Time, Effort and Resource Estimation:
Once the Scope, Activities and Activity interdependence is clearly defined and documented, the next crucial step is to determine the effort required to complete each of the activities. See the article on “Software Cost Estimation” for more details. The Effort can be calculated using one of the many techniques available such as Function Points, Lines of Code, Complexity of Code, Benchmarks, etc.
This step clearly estimates and documents the time, effort and resource required for each activity.
5) Risk Factors Identification: “Expecting the unexpected and facing it”
It is important to identify and document the risk factors associated with the project based on the assumptions, constraints, user expectations, specific circumstances, etc.
6) Schedule Development:
The time schedule for the project can be arrived at based on the activities, interdependence and effort required for each of them. The schedule may influence the cost estimates, the cost benefit analysis and so on.
Project Scheduling is one of the most important task of Project Planning and also the most difficult tasks. In very large projects it is possible that several teams work on developing the project. They may work on it in parallel. However their work may be interdependent.
Again various factors may impact in successfully scheduling a project
...........o Teams not directly under our control
...........o Resources with not enough experience
Popular Tools can be used for creating and reporting the schedules such as Gantt Charts


7) Cost Estimation and Budgeting:
Based on the information collected in all the previous steps it is possible to estimate the cost involved in executing and implementing the project. See the article on "Software Cost Estimation" for more details. A Cost Benefit Analysis can be arrived at for the project. Based on the Cost Estimates Budget allocation is done for the project.
8) Organizational and Resource Planning
Based on the activities identified, schedule and budget allocation resource types and resources are identified. One of the primary goals of Resource planning is to ensure that the project is run efficiently. This can only be achieved by keeping all the project resources fully utilized as possible. The success depends on the accuracy in predicting the resource demands that will be placed on the project. Resource planning is an iterative process and necessary to optimize the use of resources throughout the project life cycle thus making the project execution more efficient. There are various types of resources – Equipment, Personnel, Facilities, Money, etc.

9) Risk Management Planning:
Risk Management is a process of identifying, analyzing and responding to a risk. Based on the Risk factors Identified a Risk resolution Plan is created. The plan analyses each of the risk factors and their impact on the project. The possible responses for each of them can be planned. Throughout the lifetime of the project these risk factors are monitored and acted upon as necessary.

10) Project Plan Development and Execution:
Project Plan Development uses the inputs gathered from all the other planning processes such as Scope definition, Activity identification, Activity sequencing, Quality Management Planning, etc. A detailed Work Break down structure comprising of all the activities identified is used. The tasks are scheduled based on the inputs captured in the steps previously described. The Project Plan documents all the assumptions, activities, schedule, timelines and drives the project.

Each of the Project tasks and activities are periodically monitored. The team and the stakeholders are informed of the progress. This serves as an excellent communication mechanism. Any delays are analyzed and the project plan may be adjusted accordingly

11) Performance Reporting:
As described above the progress of each of the tasks/activities described in the Project plan is monitored. The progress is compared with the schedule and timelines documented in the Project Plan. Various techniques are used to measure and report the project performance such as EVM (Earned Value Management) A wide variety of tools can be used to report the performance of the project such as PERT Charts, GANTT charts, Logical Bar Charts, Histograms, Pie Charts, etc.

12) Planning Change Management:
Analysis of project performance can necessitate that certain aspects of the project be changed. The Requests for Changes need to be analyzed carefully and its impact on the project should be studied. Considering all these aspects the Project Plan may be modified to accommodate this request for Change.
Change Management is also necessary to accommodate the implementation of the project currently under development in the production environment. When the new product is implemented in the production environment it should not negatively impact the environment or the performance of other applications sharing the same hosting environment.
13) Project Rollout Planning:
In Enterprise environments, the success of the Project depends a great deal on the success of its rollout and implementations. Whenever a Project is rolled out it may affect the technical systems, business systems and sometimes even the way business is run. For an application to be successfully implemented not only the technical environment should be ready but the users should accept it and use it effectively. For this to happen the users may need to be trained on the new system. All this requires planning.
1)When does the project planning activity start and end in a software life cycle? List the important activities that software project managers perform during project planning. What are some of the factors which make it hard to accurately estimate the cost of software projects?
After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals.
Project planning generally consists of
• determining how to plan (e.g. by level of detail or rolling wave);
• developing the scope statement;
• selecting the planning team;
• identifying deliverables and creating the work breakdown structure;
• identifying the activities needed to complete those deliverables and networking the activities in their logical sequence;
• estimating the resource requirements for the activities;
• estimating time and cost for activities;
• developing the schedule;
• developing the budget;
• risk planning;
• gaining formal approval to begin work.
Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable.
For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities.
Executing Process Group Processes[19]
Executing consists of the processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan.

e) What are the most important functions of software project planning?

Monday, July 26, 2010

Software Project Management-RISKS

What are the Risk management activities for a software project?
Risk are future uncertain events with a probability of occurrence and a potential for loss”. Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work. Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.
Risk management should:
• create value
• be an integral part of organizational processes
• be part of decision making
• explicitly address uncertainty
• be systematic and structured
• be based on the best available information
• be tailored
• take into account human factors
• be transparent and inclusive
• be dynamic, iterative and responsive to change
• be capable of continual improvement and enhancement
Categories of risks:
Schedule Risk:

Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:
• Wrong time estimation
• Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
• Failure to identify complex functionalities and time required to develop those functionalities.
• Unexpected project scope expansions.
Budget Risk:• Wrong budget estimation.
• Cost overruns
• Project scope expansion
Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:• Failure to address priority conflicts
• Failure to resolve the responsibilities
• Insufficient resources
• No proper subject training
• No resource planning
• No communication in team.
Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
• Continuous changing requirements
• No advanced technology available or the existing technology is in initial stages.
• Product is complex to implement.
• Difficult project modules integration.
Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:
• Running out of fund.
• Market development
• Changing customer product strategy and priority
• Government rule changes
Identification
After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself.
• Source analysis] Risk sources may be internal or external to the system that is the target of risk management.
Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport.
• Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government.
When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties.
The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are:
• Objectives-based risk identification] Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk.
• Scenario-based risk identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk
• Taxonomy-based risk identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.[5]
• Common-risk checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation.[6]
• Risk charting[7] This method combines the above approaches by listing resources at risk, Threats to those resources Modifying Factors which may increase or decrease the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about.
Assessment
Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan.
The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is:
Rate of occurrence multiplied by the impact of the event equals risk
Composite Risk Index
The above formula can also be re-written in terms of a Composite Risk Index, as follows:
Composite Risk Index = Impact of Risk event x Probability of Occurrence
The impact of the risk event is assessed on a scale of 0 to 5, where 0 and 5 represent the minimum and maximum possible impact of an occurrence of a risk (usually in terms of financial losses).
The probability of occurrence is likewise assessed on a scale from 0 to 5, where 0 represents a zero probability of the risk event actually occurring while 5 represents a 100% probability of occurrence.
The Composite Index thus can take values ranging from 0 through 25, and this range is usually arbitrarily divided into three sub-ranges. The overall risk assessment is then Low, Medium or High, depending on the sub-range containing the calculated value of the Composite Index. For instance, the three sub-ranges could be defined as 0 to 8, 9 to 16 and 17 to 25.
Note that the probability of risk occurrence is difficult to estimate since the past data on frequencies are not readily available, as mentioned above.
Likewise, the impact of the risk is not easy to estimate since it is often difficult to estimate the potential financial loss in the event of risk occurrence.
Further, both the above factors can change in magnitude depending on the adequacy of risk avoidance and prevention measures taken and due to changes in the external business environment. Hence it is absolutely necessary to periodically re-assess risks and intensify/relax mitigation measures as necessary.
Risk Options
Risk mitigation measures are usually formulated according to one or more of the following major risk options, which are:
1. Design a new business process with adequate built-in risk control and containment measures from the start.
2. Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business operations and modify mitigation measures.
3. Transfer risks to an external agency (e.g. an insurance company)
4. Avoid risks altogether (e.g. by closing down a particular high-risk business area)
Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed.
In business it is imperative to be able to present the findings of risk assessments in financial terms.
Potential risk treatments
Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:[9]
• Avoidance (eliminate, withdraw from or not become involved)
• Reduction (optimise - mitigate)
• Sharing (transfer - outsource or insure)
• Retention (accept and budget)
Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions.
Risk avoidance
This includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the Legal liability that comes with it. Another would be not be flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits.
Hazard Prevention
Hazard prevention refers to the prevention of risks in an emergency. The first and most effective stage of hazard prevention is the elimination of hazards. If this takes too long, is too costly, or is otherwise impractical, the second stage is mitigation.
Risk reduction
Risk reduction or "optimisation" involves reducing the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy.
Acknowledging that risks can be positive or negative, optimising risks means finding a balance between negative risk and the benefit of the operation or activity; and between risk reduction and effort applied. By an offshore drilling contractor effectively applying HSE Management in its organisation, it can optimise risk to achieve levels of residual risk that are tolerable.[10]
Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration.
Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks.[11] For example, a company may outsource only its software development, the manufacturing of hard goods, or customer support needs to another company, while handling the business management itself. This way, the company can concentrate more on business development without having to worry as much about the manufacturing process, managing the development team, or finding a physical location for a call center.
Risk sharing
Briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk, and the measures to reduce a risk."
The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party. As such in the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage.
Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group.
Risk retention
Involves accepting the loss, or benefit of gain, from a risk when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much.
Create a risk management plan
Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For instance, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks.
The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.
According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.
Implementation
Implementation follows all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity's goals, reduce others, and retain the rest.
Review and evaluation of the plan
Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.
Risk analysis results and management plans should be updated periodically. There are two primary reasons for this:
1. to evaluate whether the previously selected security controls are still applicable and effective, and
2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.
c) What are the different risk assessment activities? Discuss anyone of them.
1. List three common types of risks that a typical software project might suffer from. Explain, how you can identify the risks that your project is susceptible to. Suppose you are the project manager of a large software development project, point out the main steps you would follow to manage risks in your software project.
2. What is project risk management? Discuss how should an organization following project management equip to cope with and overcome project risks?
3. Explain, how you can choose the best risk reduction technique when there are many ways of reducing a risk.
4. Discuss how a software project manager deals with the risk of unrealistic schedules and budgets.
5. Suppose you are the project manager of a certain software development project. Explain how you would carry out the risk analysis? What would be the outcome of the risk analysis? How would the outcome of your risk analysis be used to manage the risks?
2. The next item, unrealistic schedules and budgets, happens very frequently due to business and other reasons. It is very common that high-level management imposes a schedule for a software project that is not based on the characteristics of the project and is unrealistic. This risk applies to all projects. Project-specific risks in cost and schedule occur due to underestimating the value of some of the cost drivers. Recall the cost models like COCOMO, Function Point estimates. Even the size estimate is correct, by incorrectly estimating the value of the cost drivers; the project runs the risk of going over budget and falling behind schedule. The cost and schedule risks can be approximated by estimating the maximum value of different cost drivers along with the probability of occurrence and then estimating the possible cost and schedule overruns.
3. The next few items are related to requirements. Projects run the risk of developing the wrong software if the requirement analysis is not done properly and if development begins too early. Similarly, often improper user interface may be developed. This requires extensive rework of the user interface later or the software benefits are not obtained because users are reluctant to use it. Gold plating refers to adding features in the software that are only marginally useful. This adds unnecessary risk to the project because gold plating consumes resources and time with little return. Some requirement changes are to be expected in any project, but some time frequent changes are requested, which is often a reflection of the fact that the client has not yet understood or settled on its own requirements. The effect of requirement changes is substantial in terms of cost, especially if the changes occur when the project has progressed to later phases. Performance shortfalls are critical in real-time systems and poor performance can mean the failure of the project.
4. If a project depends on externally available components – either to be provided by the client or to be procured as an off-the shelf component or dependency with other services – the project runs some risks. The project might be delayed if the external component is not available on time. The project would also suffer if the quality of the external component is poor or if the component turns out to be incompatible with the other project components or with the environment in which the software is developed or is to operate. If a project relies on technology that is not well developed, it may fail. This is a risk due to straining the computer science capabilities.
5. Using the checklist of the top-10 risk items is one way to identify risks. This approach is likely to suffice in many projects. The other methods are decision driver analysis, assumption analysis and decomposition. Decision driver analysis involves questioning and analyzing all the major decisions taken for the project. If a decision has been driven by factors other than technical and management reasons, it is likely to be a source of risk in the project. Such decisions may driven by politics, marketing, or the desire for short-term gain. Optimistic assumptions made about the project also are a source of risk. Some such optimistic assumptions are that nothing will go wrong in the project, no personnel will quit during the project, people will put in extra hours if required, and all external components (hardware and software) will be delivered on time. Identifying such assumptions will point out the source of risks. An effective method for identifying these hidden assumptions is comparing them with past experience. Decomposition implies breaking a large project into clearly defined parts and then analyzing them. Many software systems have the phenomenon that 20% of the modules cause 80% of the project problems. Decomposition will help identify these modules.
Evaluating and Managing the Risks You Face
Almost everything we do in today's business world involves a risk of some kind: customer habits change, new competitors appear, factors outside your control could delay your project. But formal risk analysis and risk management can help you to assess these risks and decide what actions to take to minimize disruptions to your plans. They will also help you to decide whether the strategies you could use to control risk are cost-effective.
How to use the tool:
Here we define risk as 'the perceived extent of possible loss'. Different people will have different views of the impact of a particular risk – what may be a small risk for one person may destroy the livelihood of someone else.
One way of putting figures to risk is to calculate a value for it as:
risk = probability of event x cost of event
Doing this allows you to compare risks objectively. We use this approach formally in decision making with Decision Trees.
To carry out a risk analysis, follow these steps:
1. Identify Threats:
The first stage of a risk analysis is to identify threats facing you. Threats may be:
• Human - from individuals or organizations, illness, death, etc.
• Operational - from disruption to supplies and operations, loss of access to essential assets, failures in distribution, etc.
• Reputational - from loss of business partner or employee confidence, or damage to reputation in the market.
• Procedural - from failures of accountability, internal systems and controls, organization, fraud, etc.
• Project - risks of cost over-runs, jobs taking too long, of insufficient product or service quality, etc.
• Financial - from business failure, stock market, interest rates, unemployment, etc.
• Technical - from advances in technology, technical failure, etc.
• Natural - threats from weather, natural disaster, accident, disease, etc.
• Political - from changes in tax regimes, public opinion, government policy, foreign influence, etc.
• Others - Porter's Five Forces analysis may help you identify other risks.
This analysis of threat is important because it is so easy to overlook important threats. One way of trying to capture them all is to use a number of different approaches:
• Firstly, run through a list such as the one above, to see if any apply
• Secondly, think through the systems, organizations or structures you operate, and analyze risks to any part of those
• See if you can see any vulnerabilities within these systems or structures
• Ask other people, who might have different perspectives.
2. Estimate Risk:
Once you have identified the threats you face, the next step is to work out the likelihood of the threat being realized and to assess its impact.
One approach to this is to make your best estimate of the probability of the event occurring, and to multiply this by the amount it will cost you to set things right if it happens. This gives you a value for the risk.
3. Managing Risk:
Once you have worked out the value of risks you face, you can start to look at ways of managing them. When you are doing this, it is important to choose cost effective approaches - in most cases, there is no point in spending more to eliminating a risk than the cost of the event if it occurs. Often, it may be better to accept the risk than to use excessive resources to eliminate it.
Risk may be managed in a number of ways:
• By using existing assets:
Here existing resources can be used to counter risk. This may involve improvements to existing methods and systems, changes in responsibilities, improvements to accountability and internal controls, etc.
• By contingency planning:
You may decide to accept a risk, but choose to develop a plan to minimize its effects if it happens. A good contingency plan will allow you to take action immediately, with the minimum of project control if you find yourself in a crisis management situation. Contingency plans also form a key part of Business Continuity Planning (BCP) or Business Continuity management (BCM).
• By investing in new resources:
Your risk analysis should give you the basis for deciding whether to bring in additional resources to counter the risk. This can also include insuring the risk: Here you pay someone else to carry part of the risk - this is particularly important where the risk is so great as to threaten your or your organization's solvency.
4. Reviews:
Once you have carried out a risk analysis and management exercise, it may be worth carrying out regular reviews. These might involve formal reviews of the risk analysis, or may involve testing systems and plans appropriately.
Key points:
Risk analysis allows you to examine the risks that you or your organization face. It is based on a structured approach to thinking through threats, followed by an evaluation of the probability and cost of events occurring.
As such, it forms the basis for risk management and crisis prevention. Here the emphasis is on cost effectiveness. Risk management involves adapting the use of existing resources, contingency planning and good use of new resources.