Open access peer-reviewed chapter

Managing Requirements Risks: A Value-Based Process

Written By

Naveed Ikram, Mohammad Usman, Javeria Samad and Abdul Basit

Published: 17 August 2010

DOI: 10.5772/9905

From the Edited Volume

Advances in Risk Management

Edited by Giancarlo Nota

Chapter metrics overview

2,749 Chapter Downloads

View Full Metrics

Abstract

The technological, cost, people and schedule issues faced during software development, make it vulnerable for several types of risks. The requirements’ related risks are one of the most occurring risks. If remain unnoticed or unmanaged, the requirements related risks can cost a project greatly, financially and otherwise. It is extremely important to manage requirements related risks efficiently and effectively. Moreover, a project can never be successful if stakeholders do not get their “valued” things. Every requirement contributes towards some value for stakeholder(s). Therefore it is important to manage requirements risks to the satisfaction of stakeholders. Different stakeholders have different perception of risk, it is therefore necessary to have a process that not only manages requirements’ risks but it also fulfills the values of stakeholders as well. This chapter presents a Value-Based Requirements Risk Management (VRRM) process that is designed (Samad et al., 2008) to manage requirements related risks in a value based manner.

1. Introduction to Value Based Software Engineering (VBSE)

Most software engineering activities are practiced in a value neutral approach in which every fault, user requirement, test case, use case, risk etc. is treated equally (Boehm, 2003; Biffl et al., 2006). In Standish Group CHAOS report (The-Standish-Group, 1995) value-oriented shortfalls such as lack of user input, changing requirements, lack of resources and unrealistic time frames etc., are described as common causes of most software project failures. A value-based software engineering (VBSE) agenda has emerged (Boehm, 2003; Boehm & Jain, 2005). The focus is to integrate value considerations into current and emerging software engineering principles and practices. In traditional SE the whole development exercise focuses primarily on successful development and delivery of final product with lesser attention to the fulfillment of the values of stakeholders. On the other hand, in VBSE the focus is shifted beyond just the development of software product and consequently importance is given to the value that the software has added or it will be adding to the system. To understand the value concepts in detail, it is important first to understand what value itself is? And who are the generators of value? And how they value things?

Value: According to the Theory of Value (economics), value is economic worth of goods and services and it tries to explain the worth of goods and services provided by some entity from different angles (Wikipedia, 2007). This theory tries to answer the questions that how values of goods and services come about and how to calculate the ‘correct’ value of these goods and services. The Theory of Value suggests that the value of some entity can be seen in different perspectives. For example, it can be seen from intrinsic, subjective or objective angle. Besides the above mentioned concept of value, the Theory W of Boehm (Boehm, 1989) also makes the foundation for VBSE. The principle of this theory is to make everyone a winner. This theory also utilizes Enterprise Success Theorem. According to that theorem, enterprise will succeed if and only if it makes winners of their success critical stakeholders.

Value Holders and Propositions: It is very important to see that where does value come from? Stakeholder class is generally used for all value holders who generate value. Stakeholder is a general term that represents everyone having a stake in system e.g., developer, project manager, consumer or customer etc (Heindel & Biffl, 2005; Khalifa, 2004). We can say that all value-holders are in fact stakeholders, having some kind of value propositions from their respective perspectives.

Value-Dimensions and Perspectives: Literature describes (Heindel & Biffl, 2005);(Simmons, 1996) different value dimensions like for instance financial value, whose focus is purely on monetary elements. Similarly few other reported dimensions are economic value, business value, organizational value, technical value, end-system value, personal value and environmental value. Now the stakeholders can view these values from different perspectives. There are three different perspectives from which the stakeholders can view their values. These are Technical, Organizational and People (Simmons, 1996). Stakeholders have some value propositions and the value can be viewed from different perspectives in different dimensions.

Advertisement

2. Value Based Requirements Risk Management (VRRM) Process

Existing risk management processes do not fulfill the requirements of IEEE Standard for Risk Management (IEEE Std. 1540-2001) (Samad & Ikram, 2006).While designing the Value-based Requirements’ Risk Management (VRRM) process, it was ensured that the process overcomes as many weaknesses of the existing processes as possible, while still conforming to the IEEE standard and CMMI model requirements. The VRRM process has been designed at two levels of abstraction. The first abstraction level gives a good overview of the main activities carried out during VRRM. The second abstraction is designed at a more detailed level and presents all the activities of VRRM. The VRRM process consists of two major parts: A) Management, and B) Assessment & Mitigation.

2.1. Process Assumptions

The VRRM process is based on a few assumptions which are listed down before process description itself.

  1. 1. Policies for risk management process are already defined and stored in ‘Data Store-RM Policies’. These policies can be used for various software projects to be developed by same organization or under same authorities. However if the process is being implemented for first time and if no such policies exist, it is advisable to define the RM policies during planning phase of the project for which risk management will be performed. For later projects these can be used as required.

  2. 2. The categories for risks are also defined before hand, at least in planning phase of the project. However as this process is designed to focus mainly on requirements risks, the categories should be defined accordingly.

  3. 3. It is assumed that the process evaluation results from previous implementations of the VRRM process are recorded and available for reference. However in first time implementation, the respective data store will be empty and will continue to grow with results from further implementations the process.

  4. 4. All the data stores and artifacts produced should preferably be according to the format given by IEEE Standard for Risk Management (IEEE Std. 1540-2001).

  5. 5. The organizational and business objectives are clear and available for reference if and when required.

2.2. Abstraction Level 1

Level one description of the process consists of the six main activities. These six activities are arranged in two blocks as shown in figure 1. The activities in the Management Block are umbrella activities and are carried throughout the VRRM process. Whereas the activities in Assessment and Mitigation block are started only with/after risk identification. Relevant artifacts are produced at all steps and can be used by other subsequent activities as inputs. The activities are described hereunder:

  1. 1. The VRRM process starts with Plan activity. The risk management plan is part of the project plan and it gives the overall risk management process overview that how will it be implemented? How the activities will be carried out? Who will be responsible for the activities? And how will the process be evaluated for improvement purposes? Planning is also done (as sub-activity) for the identified risk items individually, but than its scope is limited only for the specific risk item; whereas the scope of risk management plan is spanned all over the whole process. The planning activity uses pre-defined organizational risk management policies as input. The planned information is also passed on to data stores, Risk Profile and Risk Categories.

  2. 2. The risks are identified in Identify Risk activity which uses the organizational risk management policies and risk management plan from 1 as input. The identified risks are than passed on to analyze activity.

  3. 3. In Analyze Activity, the risks are first categorized according to the pre-defined categories and afterwards the likelihoods and consequences of the identified risk items are calculated. On the basis of all this information and threshold values, the acceptance of the risk item is calculated in a value based manner and risks are prioritized in the order of treatment.

  4. 4. After analysis the risk items are passed on for treatment. The Treat activity is also made value based.

  5. 5. Monitor and Control is a continuous activity and is performed in parallel with all other activities.

  6. 6. For future improvements in the process, VRRM process is evaluated in Evaluate RM Process activity using information from all other activities. The evaluation results from previous implementation of the process can be used by subsequent implementations.

All these activities are iterative in nature especially those belonging to management block.

Figure 1.

VRRM-abstraction level 1.

2.3. Abstraction Level 2

Abstraction level 2 is the detailed representation of abstraction level 1. The sub-activities are represented as divided into six blocks representing the six activities from level 1: Plan, Identify, Analyze, Treat, Monitor & Control, and Evaluate. All the artifacts, data stores and major interactions among six blocks are similar to those at level 1. See figure 2.

  1. 1. The process starts with planning. The input to Plan RM Process is the organizational risk management policies and the process evaluation results from past. This past analogy is useful in making the VRRM process more effective and efficient while incorporating the results from previous usage of the process. The output of this activity is Risk Management Plan which is then further used as input to many succeeding activities.

  2. 2. Using this plan, roles & responsible parties are defined and resources are planned. The criteria for risk attributes, scales and measures, thresholds and risk categories is also planned and defined here. All this information is stored in their respective data stores. Data store Risk Profile acts as a basic database for keeping all the information about all risks generally as well as for each of individual risk items. The only artifact produced here at this stage is risk management plan.

  3. 3. Process evaluation is done in Evaluate RM Process activity. This evaluation is performed according to the strategy planned in Define Evaluation Process activity. All the evaluation results will be captured in data store Evaluation Results. This data store will have the evaluation results and the lessons learned from previous projects too for reference for current projects.

  4. 4. The risks are identified in Identify Risk activity. This activity is put under continuous Monitor and Control as risk identification is a continuous process and risks can occur at any time. Also some entity can be a risk at some times but cannot be the risk at some other time.

  5. 5. The identified risks (from 4) are then categorized according to the criteria set during planning activity. The categorization of risk activity can also point-out some other risks that have not been identified yet.

  6. 6. The likelihood and consequences of each risk item is then calculated.

  7. 7. As VRRM Process is focused on requirement risks, the respective requirement is linked with the business objective that it is assumed to fulfill.

  8. 8. Afterwards the success-critical-stakeholders SCSs are identified.

  9. 9. These SCSs then assess the value of the subject requirement and the value of risk identified w.r.t. that requirement. The SCSs assess the value in all three perspectives TOP individually (-these perspectives were identified while studying value-based concepts and relevant information can be seen in literature review part-3). The net value for that particular risk item is than calculated by taking aggregate of values of all stakeholders in TOP perspectives.

  10. 10. This net value plus the thresholds and consequences of the risk item are then used to evaluate the risk against thresholds defined during planning.

  11. 11. Risks that are below threshold are continuously Monitored and Controlled as some risk item that is below threshold at some time can exceed the threshold at some other moment.

  12. 12. For risks that are above threshold, the contingency plan is developed.

  13. 13. These risks are then put in priority list for treatment. The priority ordering of the risk items is done on basis of SCSs value-assessments; done in same manner as for risk acceptance. The highest valued risk items will be placed on top priority. This value assessment for priority ordering is also done in TOP perspectives and net value is calculated as aggregate of values of all SCSs in all three perspectives. The prioritized risk items are continuously Monitored & Controlled because the priority of certain risks can change at any time during the project. It can be either because of change in value propositions of the SCSs or some unavoidable circumstances.

  14. 14. The top-prioritized risk item is then passed on for treatment.

  15. 15. The treatment alternatives for top-priority risk item are defined and made available to the relevant parties in Define Treatment Alternatives activity. These treatment alternatives are then evaluated for each risk item and the value for each alternative is calculated in same way as for risk acceptance and prioritization in TOP perspectives. The final selection is made on the basis of net-value of SCSs evaluated with the help of negotiations, either against some pre-defined or on-spot criteria.

  16. 16. If the treatment alternative(s) is selected, it will be implemented according to the planned implementation process for selected treatment.

  17. 17. If the treatment alternative is not acceptable, more treatment alternatives will be defined.

  18. 18. The overall information after implementing treatment alternative is recorded and passed on to Identify Risk activity as implementing one treatment alternative can produce new risks.

  19. 19. During whole process, all the artifacts and information in respective data stores is updated when and where required.

  20. 20. As mentioned previously, Monitoring & Control will be a continuous activity covering all the activities all through the project.

Figure 2.

Vrrm-abstraction level 2.

Advertisement

3. Case Study

VRRM process has been implemented on multiple projects (Samad et al., 2008). In this section, we will describe one successful implementation of VRRM process in a large organization.

3.1. Introduction of the company and Project

The project is carried out by a multinational company “Company-A” which provides software solutions to telecommunication operators across the world. The project is referred to as IPTV. As a whole, the Company-A has the strength of 50,000 employees and 8,000 of them are working in about 100 representative offices around the world. Also, it has established joint laboratory partnerships with world’s leading technology providing companies and universities. The Company-A is holding the CMMI level-II.

The IPTV project is executed for a largest telecommunication company providing most reliable and largest converged services from basic voice telephony to data, internet, video conferencing and carrier services to consumers and businesses all over the country (Pakistan). It has employee’s strength of more than 25,000 employees with more than 4 million subscribers of basic telephony services. This telecom company entered into the broadband market in 2004 and now having the subscribers of data services more than 130,000.

The IPTV project intends to provide the various modern services to its subscribers like controlling the TV channels interactively. The responsibility of Company-A includes to provide real-time or near real-time Billing and Customer Care functions for IPTV Project. The deliverables should have a best-fit with the existing Billing and Customer Care System (B&CCS). The project has special focus on the Customer Care System (CCS) including revamping of new connection services and post installation services of Triple Play Products. The scope further covers the interfaces of CCS Module with OSS via MS SP (Mediation Service Provisioning) for services according to the North Bound Interface (NBI) shared by the OSS. However, the scope of work does not include separate Billing and Receivable Module and shall not generate Customer Invoices. The developed software shall be deployed on the existing hardware of B&CCS for quick delivery of services.

The main components of the IPTV project are:

  1. 1. New PSTN, New Broadband, New IPTV

  2. 2. Existing PSTN, New Broadband, New IPTV

  3. 3. Existing PSTN, Existing Broadband, New IPTV

  4. 4. Post Installation Services

    1. 4.1. Change of package

    2. 4.2. Permanent close

    3. 4.3. Temporary close due to no payment

    4. 4.4. Temporary close on customer request

    5. 4.5. Restore due to payment

    6. 4.6. Change of ownership

    7. 4.7. Change of password

    8. 4.8. Shift of IPTV service

    9. 4.9. Change/Replacement of CA Card

    10. 4.10. Change of modem

    11. 4.11. Change of STB

    12. 4.12. Credit control procedure

  5. 5. New packages

  6. 6. Withdrawal

  7. 7. Management of pending orders

  8. 8. Inventory management

    1. 8.1. CA inventory

    2. 8.2. Modem inventory

    3. 8.3. STB inventory

  9. 9. B&CCS-OSS External Interface

    1. 9.1. North Bond Interface (NBI)

    2. 9.2. Electronic Programmable Interface (EPI)

    3. 9.3. File Interface of Billing with AAA for Video on Demand (VOD)

3.2. Implementation of VRRM Process Model

VRRM process implementation is described in a step wise manner now.

3.2.1. Plan

The VRRM process starts with the Plan activity. There are total number of 8 activities in this group that are performed in order to produce 3 deliverables; Risk Management Plan, Risk Categories and Risk Assessment Register. The risk management plan is part of the project plan and it gives the overall risk management process overview that how it will be implemented, how the activities will be carried out, who will be responsible for which activities and how will be the process evaluated for improvement purposes. The planned information is also passed on to data stores of Risk Profile and Risk Categories.

Plan RM Process

In IPTV project the VRRM Process was planned along with the project team and responsible parties. Company-A considers Risk Management as an important factor to improve its business, products, services, solution and eventual satisfaction of the customers. As per Company-A risk management policy, the management aims to achieve best practices in managing all risks. To achieve this objective and aim, risk management standards involving risk identification and risk evaluation linked to practical and cost-effective risk control measures. All the planning was done by keeping in view the VRRM process model guidelines. The collected information was documented in “IPTV - Risk Management Plan”.

Plan Resources

In IPTV project a dedicated risk management team was established for execution and management of VRRM process model. After negotiations with Project Managers of both sides (Company-A and Telecom Company) the Risk Manager (Company-A) was heading the team of three members including the following individuals:

  1. 1. Software Engineer, Company-A

  2. 2. Manager B&CCS, Telecom Company

  3. 3. Manager Multimedia & Broadband, Telecom Company

Risk management team was properly trained for the execution and management of VRRM process model. In addition to the dedicated risk management team one of the authors was actively monitoring the whole process. All the necessary material resources were also provided to the subject team.

Figure 3.

Identify Responsible Parties

The Risk management is a continuous process which requires risk awareness and proactive measures by all the resources and the partners who actively participate to eliminate the occurrence and impact of risk events.

In IPTV project, responsible parties for managing the risks were the Project Manager, Risk Management Team and the author himself. The management of both companies (Company-A & Telecom Company) was regularly evaluating and reviewing the measures for the best fit for achieving business objectives. Keeping in view the complexity lies in the volume and spread of geography, the team comprises of two members from Telecom Company for coordinating the risk management activities within itself.

Define Roles & Responsibilities

As mentioned above, at IPTV the risk management team was responsible to conduct the risk management along with the participation of one of the authors. The team was focusing on the implementation activities of risk management process and its monitoring and controlling. The risk management team worked in close coordination with project management team under the leadership of a dedicated Project Manager. Further, the Risk Manager was attending all the meetings with regards to the requirements and status reviews. Apart from the regular feedback, the project manager may ask for instant feedback as and when required depending upon the situation. The risk management team was also having a mandate to coordinate with all success critical stakeholders to ensure the effective mitigation of the risks. Risk information was regularly communicated among all relevant project members according to the schedule (time-periods) set by project manager and risk manager. The Risk Manager was also entrusted with the responsibility to disseminate the risk related information to all concerns. The risk management team ensured the effective management of data stores for VRRM Process Model. The risk mitigation strategies were formulated after deliberations and discussions among risk management team and with the help of executive management of Telecom Company and success critical stakeholders.

Define Scales & Measures

Following scales and measures were used:

  1. 1. Likelihood of each risk item was assessed on scale of 1-10

  2. 2. Impact of each risk item was classified on scale of Low, Medium and High. In quantifiable terms it will be measured on the scale of 0-1 where “0 - 0.3 = Low, 0.4 – 0.6 = Medium and 0.7 – 1 = High”.

  3. 3. Magnitude of each risk item was calculated on basis of probability and impact.

  4. 4. Value assessment of requirements and risks from success critical stakeholder was done on the scale of 1-10 in all three perspectives of Technical, Organizational and People (TOP).

  5. 5. Net value was calculated by aggregating the value of all stakeholders.

  6. 6. Threshold for acceptance of risk item was decided to be 5. Only the risk entities with aggregate value greater than 5 (calculated on basis of magnitude and net stakeholder value), were accepted as risk and treatment activities were planned accordingly for them.

Define Objectives and Assumptions

The objectives for VRRM Process Model are to:

  1. 1. Identification of the risks and their mitigation in value based manner

  2. 2. The requirements and allied risks are valued by the success critical stakeholders instead of the project or risk management teams

  3. 3. The success critical stakeholders are valuing the identified alternate treatments for successful mitigation of the identified risks

  4. 4. The companies executing the projects are willing to employ the value based risk management process model to ensure successful delivery of the software projects

  5. 5. The development companies are more concerned about their processes related to the risk management

Define Risk Categories

The risk categories were defined as Product and Process risks as given in the description of VRRM Process Model. There were some other suggestions too but it looked feasible to categorize them in this manner as they can easily be mapped for requirements risks specifically to fulfill the mandatory requirements of VRRM Process Model. Focusing strictly on VRRM Process Model, the product risks include only the risks related to end-product itself and the process risks include all the other risks that are related to development process or team involved.

Data Stores

Implementation of VRRM process requires the organization’s business objectives and organizational risk management policies to be documented during project planning phase. The implementation was done in continuous coordination with all project team members to keep low the chance of biasness. During the implementation process, all the artifacts were produced more or less according to the templates suggested by IEEE Standard for Risk Management (IEEE Std. 1540-2001) except for contingency plan as this Standard doesn’t provide any template specifically for contingency plan. The Standard template was used according to description given in VRRM Process.

A master list containing all risks “Risk List” is maintained throughout the lifecycles of project. The other artifacts of Risk Management Plan (RMP), Risk Assessment Register (RAR), Risk Treatment Plan (RTP) and Risk Contingency Plan (RCP) were produced during the process of risk management. These artifacts were updated continuously as new risks are uncovered and existing risks are mitigated or retired. During the implementation of VRRM Process Model, the data stores to be maintained are Risk policies, Risk Management Plan, Risk categories, Business Objective Document, Requirement Document, Risk Assessment Register, Value Assessment Register, Risk Treatment Register.

All the above artifacts were developed. These data stores may contain the information and data from previous projects, if any. However, these data stores shall be empty in first implementation of VRRM process. These data stores shall provide a comprehensive repository for future implementations.

3.2.2. Identify

In this activity group, risks were identified according to the companies’ risk management policies and risk management plans. As VRRM Process model does not recommend any specific technique for identification of risks, best practices from risk management literature (project information, brainstorming, interviews, analysis of historical data and cause & effect analysis) were used for risk identification. 24 risks were identified for IPTV project. The risk identification exercise was done by risk management teams in close coordination with one of the authors. All the information is recorded in the Risk Assessment Register.

3.2.3. Analyze

Risk analysis is the third group of activity in the VRRM process model. It starts immediately after the identification of risks. The core activities of value-based requirements’ risk management process model belong to this activity group. During the risk analysis, the success critical stakeholders were involved actively as they assess the requirements’ and risk’s value for the acceptance of risk. The complete analysis process was performed as under:

Categorize Risks

The categorization of risks into products and process risks is made for separate purposes. The process related risks will be helpful in the process evaluation and improvement which is an integral part of VRRM. Also, the risks related to products will lessen the chances of failure of delivered product. Jointly, these categories will be helpful in improving overall quality of the product and process ensuring successful product development in terms of cost, time, quality and value. Categorization of risks was done by risk management teams with consultation of relevant stakeholders. The information is recorded in the data stores of Risk Assessment Registers.

Estimate Likelihood & Consequences

Likelihood of the risk is its probability to occur during the project lifecycle and consequences is the expected impact of the risk, if it occurs. The values of Likelihood and consequences to the risks are assigned by risk management team in close coordination with project management team on the scales defined during the planning phase. Net magnitude is calculated by taking product of likelihood and consequences. This information is recorded in Risk Assessment Register data store.

Link Risks to Requirements

From this step to onward the core activities of VRRM Process model start. As VRRM process model deals only with requirements related risks, we need to clearly identify that what are the risk(s) associated with a particular requirement or vice versa. This association is done by risk management team by conducting in depth analysis and consultation with success critical stakeholders. In IPTV project this exercise was done in a very good manner because most of the success critical stakeholders were available for face to face meetings and a proper risk management tame was working for the coordination and management of the process. The results were recorded in Risk Assessment Register.

Link Requirements to Business Objectives

At this stage, we need to identify that what are the business objectives which can be affected as a result of risk occurrence. All the risks are indirectly linked with the business objectives through means of requirements. Only those business objectives and requirements were recorded that have some risks associated with them. This exercise was also done by risk management team and Requirements Document and Business Objective Document were maintained for project.

Identify Success Critical Stakeholders (SCSs)

As VRRM process model brings the concept of value in risk management process and the values are assessed by success critical stakeholders. So, it is very much critical to identify success critical stakeholder in order to complete the process of VRRM. The Theory of Salience applied in order to identify the Success Critical Stakeholders in IPTV project. Only definitive and discretionary types of stakeholders are considered as success critical stakeholder and consulted for the process of valuation due to the possessed attributes of power and legitimacy. The identification and categorization of stakeholders was done by project management team in close coordination with risk management team and one of the authors. The following is the list of stakeholders.

Stakeholders Type Attributes
Power Legitimacy Urgency
Board Members Dominant Yes Yes No
President & Chief Executive Officer Dominant Yes Yes Yes
Senior Executive Vice President (Finance) Discretionary Yes Yes No
Executive Vice President (Finance) Discretionary Yes Yes No
Executive Vice President (Revenue Accounts) Definitive Yes Yes Yes
General Manager (Revenues) Definitive Yes Yes Yes
General Manager (Cost Accounts) Discretionary Yes Yes No
Senior Executive Vice President (Commercial) Definitive Yes Yes Yes
Executive Vice President Multimedia & Broadband Definitive Yes Yes Yes
Manager PMO Multimedia & Broadband Definitive Yes Yes Yes
Chief Information Officer Definitive Yes Yes Yes
Executive Vice President (Information Systems) Definitive Yes Yes Yes
General Manager (Billing Solution) Definitive Yes Yes Yes
General Manager (Customer Care and Supported Solutions) Definitive Yes Yes Yes
Senior Executive Vice President (Operations) Discretionary No Yes No
Senior Executive Vice President (Business Zones) Definitive Yes Yes Yes
Executive Vice President (Business Zone North) Definitive Yes Yes Yes
Executive Vice President (Special Projects) Definitive Yes Yes Yes
Executive Vice President (Business Zone Central) Definitive Yes Yes Yes
Executive Vice President (Business Zone North-II) Definitive Yes Yes Yes
Regional General Manager (Central-I) Definitive Yes Yes Yes
Regional General Manager (Central-II) Definitive Yes Yes Yes
Senior Executive Vice President (Business Zone South) Definitive Yes Yes Yes
Executive Vice President (South) Definitive Yes Yes Yes
Executive Vice President (West) Definitive Yes Yes Yes
Regional General Manager(s) Definitive Yes Yes Yes
Senior Member Advisory Team Discretionary Yes Yes No
Member Advisory Team (Finance) Discretionary Yes Yes No
Member Advisory Team (Operations) Discretionary Yes Yes No
Member Advisory Team (Finance) Discretionary Yes Yes No
Member Advisory Team (Information Systems) Discretionary Yes Yes No
Member Advisory Team (Billing and Customer Care System) Discretionary Yes Yes No
Member Advisory Team (Multimedia and Broadband) Discretionary Yes Yes No
Company-A, Company-B Definitive Yes Yes Yes
Other solution providers Definitive Yes Yes Yes

Table 1.

Iptv - success critical stakeholders.

Success Critical Stakeholders Assess Requirements’ and Risks’ Value

As per VRRM Process Model, requirements’ value is assessed by success critical stakeholders in all three perspectives (Technical, Organizational & People). The stakeholders were given necessary overview and practice sessions prior to the execution value assessment exercise, in order to make the value assessments more appropriate. Net value for each requirement is calculated by aggregating the values of all success critical stakeholders. Subsequent to the requirements’ value assessment, risks’ values are also assessed in the same manner. The results of value assessment exercise are recorded in “Value Assessment Register”.

Calculate Net Value

The calculation of net value is done by risk management teams. In previous activity, values of requirements and their associated risks are assessed by success critical stakeholders and net values for requirements and risks are calculated separately for requirements and their associated risks. As per recommendation of VRRM process model, here both values are aggregated in order to get a single value for each requirement’s risk to evaluate them against the agreed threshold. The results are recorded in “Value Assessment Register”.

Evaluate Against Threshold

During this step, net requirements’ risk values are evaluated against the agreed threshold of 5. In individual value assessment risk no. 5 and 18 of IPTV project were having values lower than the agreed threshold, hence; not qualifying for the treatments. But after aggregating the requirements’ value, the net value of both risks crossed the threshold level. As result of this activity all 24 risks were qualified for the treatment and their treatment planning was started.

Establish Contingency

The commercial and operations departments were negotiated to provide the kind of contingency required for the mitigation of the risks.

Place in Priority Order

This activity is a simple re-order of the risks on the basis of calculated net requirement’s risk value. This was done by risk management team. Risk Assessment Registers was reordered accordingly.

3.2.4. Treat

After completion of the analysis stage, all the accepted risks were passed on to the treatment. In this group of activities, the mitigation strategies for the accepted risks were defined and executed in value based manner. This stage of implementation of VRRM process model is very crucial, as it needed too many resources and extra efforts to mitigate the risks before their occurrence. At this stage many problems were faced due to the reluctance of companies in putting extra human and material resources.

Management was reluctant to put extra resources on the process but minimum required resources were provided by the company to mitigate the risks. The complete task of risk treatment was performed as under:

Define Treatment Alternatives

Treatment alternatives for all risks were defined by risk management teams in close coordination with success critical stakeholders. The defined alternatives were then discussed with project management team for their consent. After approval and recommendation of project manager, the alternatives were presented to success critical stakeholders for value assessments. The identified treatment alternatives are recorded in “Risk Treatment Register”.

Define Measures for Effectiveness of Alternatives:

The measures for effectiveness are established in terms of reaching to logical conclusion of execution of selected treatments from the defined alternatives. It is notable that the alternates are valued by the success critical stakeholders and their priorities were defined accordingly.

Assess Value of Each Alternative

Similar to the value assessment of requirements and risks during analysis activity, values of treatment alternatives were also assessed by success critical stakeholders in Technical, Organizational and People (TOP) perspectives. Same process of value assessment was followed. Interviews and meetings with success critical stakeholders were conducted, in order to complete the activity. Same scales and measures were used and results were recorded separately in Risk Treatment Registers.

Calculate Net Value

Net values of treatment alternatives were calculated by aggregating the values of all success critical stakeholders for each treatment alternative. This exercise was done by risk management team at IPTV project. The results were recorded in Risk Treatment Register.

Evaluate Acceptability

This activity is simple comparison of net values of treatment alternatives against the threshold of 5 agreed during the planning activity. It was analyzed that more than one alternative for a risk were qualified for the treatment of risk. In that situation the matter was discussed with the project management team and success critical stakeholders and maximum valued treatment alternative was adopted and implemented for risk mitigation and treatment. However, all the results of evaluation were recorded in data store of Risk Treatment Register.

Define Implementation Process for Selected Treatment

This step is about planning for the treatment actions. In this activity, the steps for each selected treatment activity were defined and resources were planned for the implementation of to selected treatments. This activity was successfully performed by risk management team in coordination with the both project managers.

Implement Treatment Alternative

Implementation of treatment alternatives was found to be a difficult activity in the implementation of the VRRM process model. As this activity requires putting extra efforts and resources, the companies and the risk management teams were reluctant to perform this activity despite agreeing to it. Non cooperation and lukewarm gesture from management was observed during the execution of this activity.

The risks related to hardware sizing, integration with billing as one package and workflow for manual monitoring of new subscription cases were highlighted during early stage by the risk management team. Also, the alternate treatments were monitored rigorously for these risks in order to mitigate them. However, less importance were given by the TELECOM COMPANY for timely mitigation of these risks which resulted into their occurrence during transition phase. The business decisions were required with continuous will to execute mitigation strategies.

3.2.5. Monitor & Control

Monitoring of the VRRM process model was done on weekly basis. Regular meetings were conducted with risk and project management teams and status of each risk treatment was tracked and monitored in order to ensure the proper execution of the mitigation strategy. It was observed that some of the risks identified during the identification phase did not occur due to the timely execution of mitigation strategy. The effective monitoring was also useful in order to identify the residual risks and coming up new risks into the risk register.

3.2.6. Evaluate

Define Evaluation Process

The quality assurance team was involved in order to ensure the execution of each and every activity of VRRM Process Model with necessary order and process flow. The process execution was monitored for appropriate recording and updates in the artifacts and data stores.

Evaluate Risk Management Process

The quality assurance team was having the mandate to monitor the activities in order to evaluate the risk management process on IPTV Project. The QA team engaged at various stages of execution of the VRRM Process model keeping in view the CMMI quality standards. The periodic reviews, meetings and interviews conducted to find out the variations from the VRRM process model. The variations were noted down and presented in the conclusion section along with the other results.

3.2.7. Results

Following are the results of VRRM implementation.

  1. 1. The VRRM Process Model provides the improved risk management which is utmost important in terms of successful delivery of software projects.

  2. 2. The concept of success critical stakeholders to value the requirements were greatly welcomed on IPTV Project. In fact, the success critical stakeholders never took risk management for software projects in value based manner before this project.

  3. 3. The real problems were faced in creating the awareness regarding the value based risk management process.

  4. 4. The management was convinced to employ VRRM Process Model and dedicate their resources to participate in the activities of implementation process.

  5. 5. The people engaged in the implementation process were given formal training sessions.

  6. 6. It was observed that the software developers were having very little understanding about the general risk management process and especially for the concept of value in the overall software engineering.

  7. 7. The alternate treatments could not be executed for three risks in IPTV project despite repeated efforts due to cumbersome negotiations in terms of bringing the whole management to consensus.

The overall implementation of VRRM Process Model was successful as all potential risks were identified and analyzed during early stages of the project lifecycle and no surprises were recorded at later stages. However; some risks occurred due to the non implementation of the suggested treatment alternatives. This was lack of cooperation from top management rather than process failure. Table 2 presents the summary of the data recoded during the course of project.

Items Number
Identified Risks 24
Process Related Risk 6
Product Related Risk 18
No. of Requirements related to Risks 10
No. of Business Objectives Related to Requirements 4
Total Success Critical Stakeholder 31
Minimum Value assessed for a risk 5.11
Maximum Value assessed for risk 7.19
Average Value assessed 6.1
No. of risks qualified for treatment 24
Total No of treatment alternatives identified 33
No. of risks mitigated 21
Risks occurred 3
Overall success rate of Risk Management 87.50%

Table 2.

VRRM Case Study Result Summary.

Advertisement

4. Conclusion and Future Work

Value-based Requirements’ Risk Management Process Model brings the innovation to the traditional risk management process, by introducing the concept of value into it. The value based management of the risks is introduced in this process model at two stages. Firstly, the risks are selected and prioritized in a value-based manner by keeping in focus all success critical stakeholders during the analysis phase. Secondly, the treatment of risks is also made value-based. During the selection of treatment alternatives, success critical stakeholders are consulted for there assessment about the treatment alternatives so that treatments having high values should be executed.

In the light of the feedback from VRRM implementation, we intend to further elaborate Monitoring and Control activity to make it more robust and having controls at each stage of the abstract level-1 of the VRRM Process Model. The connections of “Estimate Likelihood” and “Estimate Consequences” activities with other other activities of the process need to be updated to link them properly with other activities. These revisions shall be incorporated in next version of VRRM.

Lack of management support for implementation of proper risk management (RM) is usually because of the effort and resources required by RM. VRRM process model consists of many activities. Different data stores and artifacts are also associated with different activities. VRRM implementers have to make certain decisions well. In future, we plan to develop an electronic process guide (EPG) for practitioners. EPG will not only guide the practitioners during VRRM implementation, it will also provide templates and samples of different artifacts required. Further, we also intend to launch a project to develop VRRM tool support. We will integrate EPG in the tool. Tool support will reduce the effort and resources required during VRRM implementation. Project data will be easily maintained in the tool and will be available for reference for future implementations. Successive implementations of VRRM by one company will yield useful historical data related to risk management.

References

  1. 1. Biffl S. Boehm B. Erdogmus H. Aurum A. Grunbacher P. (Eds.) 2006 Value Based Software Engineering. Germany: Springer-Verlag Berlin Heidelberg 2006, (10 3-540-25993-7 Springer Berlin Heidelberg).
  2. 2. Boehm B. Jain A. 2005 An Initial Theory of Value-Based Software Engineering. USC-CSE-2005-502, February 2005.
  3. 3. Boehm B. 1989 Theory-W Software Project Management: Principles and Examples. IEEE Transactions on Software Engineering, 15 7 July 1989.
  4. 4. Boehm B. 2003 Value Based Software Engineering. ACM SIGSOFT, Software Engineering Notes, 28 2 1-11
  5. 5. Heindl M. Biffl S. 2005 A Case Study on Value-based Requirements Tracing. Proceedings of ACM, ESEC-FSE’05 60 69 .
  6. 6. IEEE. 2001 IEEE Standard for Software Life Cycle Processes-Risk Management. Software Engineering Standards Committee of the IEEE Computer Society, (IEEE Std. 1540-2001), IEEE-SA Standards Board.
  7. 7. Khalifa A. S. 2004 Customer Value: A Review of Recent Literature and an Integrative Configuration. Published in Management Decision, 5 645 666 .
  8. 8. Samad J. Ikram N. 2006 Managing Risks: An Evaluation of RM Processes. Proceedings of IEEE International Multitopic Conference (INMIC 2006), 281 287 , Islamabad, Pakistan, December 2006.
  9. 9. Samad J. Ikram N. Usman M. 2008 VRRM : A Value Based Requirements’ Risk Management Process, proceedings of The IASTED International Conference on Software Enginnering SE 2008, 184 191 , Innsbruck, Austria, Feb 2008.
  10. 10. Simmons P. 1996 Quality Outcomes: Determining Business Value. Published in IEEE Software. 25 32 .
  11. 11. The-Standish-Group. 1995 THE STANDISH REPORT, available at: www.standishgroup.com.
  12. 12. Wikipedia. 2007 a. Theory of Value. Retrieved April 2007; from: http://www.wikipedia.org/wiki/theory_of_value_(economics).
  13. 13. Wikipedia. 2007 b. Value Engineering. Retrieved March 2007; from: http://www.wikipedia.org/wiki/theory_of_value_(economics).

Written By

Naveed Ikram, Mohammad Usman, Javeria Samad and Abdul Basit

Published: 17 August 2010