Software Risk Management

There are numerous large software projects in the world nowadays. However, 91% of them are failed because of lots of different reasons [1]. Hence, software risk management would be a critical principle in the long term, large scale software development projects.

The definition of risk and risk management

Risk is the probability of the incurring a loss or enduring a negative impact [2]. It can be expressed by the equation RE = P (UO) * L (UO) [3]. RE illustrates the risk explore, the probability of unsatisfactory outcome is P (UO) and L (UO) demonstrate the impact of unsatisfactory result for the project. Also, we can describe risk as uncertainty, which cannot represent the probability distribution [4]. Risk is the probability of failing to achieve the certain cost, optimal performance, schedules objectives, leading to the failure of projects.

In order to reduce the frequency of failing in projects, we should try to do something to avoid it.  Hence risk management plays a dominant role in every project.  There are many elements would reduce the success rate of the project, instead of planning to assume the best case, we should incorporate the ways things go wrong into the plan [1].  Hence, we should organize risk management. It is an organized process for identifying and dealing with high-risk elements. Including both initial management and future risk management [2].

How to organize risk management process

The human species is the only species that hold its own fate. Human has the capacity to explore the future. We are always ignoring the project risk although there are some statistics evidences proving the existence of risk in project [1]. After people experienced various failure projects, they recognize that they should focus more on risk prediction and corrective actions.

An original project might provide a sense of unsatisfactory in many features, such as budgets, overruns, wrong functionality, schedule and poor-quality software. Hence, manager should create a process to improve this case like below:

无标题

To be more exact, firstly, the management should identify risk factors in the project [4].  Every large project would produce some crisis to impact the consequence of the project. This risk is a potential problem in project. Some of them should be ignored to facilitate the productivity and conserve the  time. However, it is essential that we should consider many important high-risk elements before we put enthusiasm and energy into the project. In order to practice in all positive part of the project, we should make a list of all high-risk elements, which would help people gain the risks of project. Secondly, Assessing risk probabilities and effects are necessary. For software projects, the desired outcome is an acceptable product delivered on time and within budget. If we prefer to achieve the desired result, we have to assess these high-risk elements carefully. It would make a contribution to select appropriate elements and deal with them. When we execute these two steps well, we could avoid to wasting much time on some unnecessary improvement. Also, it will boost the efficiency to implement the rest steps of risk management.

If we pre-process the elements during the first two steps, in the following stage, we should develop strategies to mitigate identified risks. A risk transform to a problem when the value of a quantitative metric  exceeds its predetermined threshold. The threshold would be established by regarding the corrective action and ahead of time of corrective action as a standard. During this step, risk plan should be divided into two sections. One of them is action planning, it can mitigate the risk by instant response. We could use experienced people or train the team, but it should not spend much time to address this problem. In terms of contingency planning,  risk management needs to monitor the future response. For example, contingency planning would monitor the vendor’s progress and develop a software emulator for the target machine [5].

After that, we should monitor risk factors and invoke a contingency plan. We observe the changed value in the metrics which crosses the predetermined threshold. Subsequently, it is essential that people should allocate adequate resources and specify a drop-dead date, then we could manage crisis, such as re-evaluate the project with corrective action. At last, we should review the crisis to summarize some principles, which would have a great effect on the future projects.

The strategy of risk management

When it comes to some strategies that could help us solve the risk problem. There are many aspects should be referred.

The initial problem is that people lack sufficient knowledge and experience to figure out the real issues in projects.  The strategy is that we should do something easy at first during a short period. After people deliver these to the system, they could detect the problem clearly and try to address them, but they should not do this many times because it will lower the efficiency of the long term large scale program. Secondly, it is smart that we divide the program and deliver some parts of them to the system early and regularly.It is very significant to do this because it can address the problem with the optimal techniques and learn from each other.We need to create a delivery schedule to ensure when we need to deliver the program, after this we could organize a team and communicate about it. This should be held not very regularly, such as six months.

When we divided the program into some parts, we would find some methods to address them, but we need to make every solution independently because all these solutions would be constrained by the manager’s insufficient information. We need to examine the small system and put the small system into large system. We could adjust or change the prototype if they are incorporated. It could help us to discover the best decision on how to reduce the risk. Then the completed program, which was adjusted by risk management, should be implemented to test your existed system.  In order to acquire the accurate data from the large program, including staff learning rates, technology effects, the management needs to run carefully, we need use our own people and experts. Most papers claim that we only need one expert. However, only one expert would lead to subjectivity, and experts are always concentrating on a special knowledge; hence we should employ two or three experts to control risk management.

Organizing a team with multiple specialties is necessary for risk management. Team has an inherent advantage of promoting communication and coordination. One factor we should focus on is the size of the team. If the team is so small like only one person, it would difficult to complete the program perfectly. In contrary, if the team is too large, it will need spend much time on holding the meeting and communication, causing conflicts, leading to the low productivity. Sometimes, we should address the problem independently; large team would result in relying on others. Also, we should start our projects immediately, the earlier, the better. Because when we put the theoretical methods into the reality, there are some high-risk elements would be found. People could communicate and cooperate to adjust and improve them . The information of risks in the program could be up to the minute, which can help experts  monitor and  control risk management.

According to the large program, we should divide the program into several appropriate parts to allocate to everyone in the team. Making sure that everyone should assume the responsibility of something by their own knowledge background. However, it is essential that we should strike the balance between different conflicts and ownership needs. If we can solve these problems well, people in the team could interact and coordinate better. There are some inevitably disturb in projects. It would become another risk to make program fail. When it is happening, we should focus on the primary goal and ignore these distractions. If we consider more about these distractions, these risks would become problems to impact the program.

Conclusion

There are many theoretical methods supporting risk management, which can make software development successfully. Most of these resources come from numerous program failure experiences and some prediction. Hence, when we complete one project, no matter what is a successful project, we need to summarize how we avoid risks and address problems. Or why we fail the program, where we should improve it and predict something. For instance, when we fail one project, maybe we having a weak risk assessment, which will introduce a considerable doubt to the accuracy and value of the results. Although we have some risk management methods now, such as waterfall and evolution, because of the lack of sufficient background knowledge and enough resources, we would choose inappropriate people and tools, underestimate the complexity of the program, make inefficient plan adjust projects.

It is no doubt that risks exist in every project, we have to do risk management to avoid potential problems, which would fail the program, especially for large software program, we have to control projects, adjust and eliminate the problem before they can impact the program.

Reference

[1]. The slide of course.

[2].Software Risk Management. R.E. Fairley. IEEE Software, May/June 2005.

[3].Software Risk Management. R.E. Fairley. IEEE Software, May/June 2005.

[4].Software Risk Management: Principles and Practices. B.W. Boehm. IEEE Software, January 1991.

[5].Implementing Risk Management on Software Intensive Projects. E.H. Conrow, P.S. Shishido. IEEE Software, May/June 1997.

[6].Risk Management For Software Projects. R. Fairley. IEEE Software, May 1994.

Response to the article: Sharing the knowledge – The role of communication across teams.

The following article is a response to the blog post: Sharing the knowledge – The role of communication across teams by Nick Kaltsas.

 

Introduction

In this post, the author described the importance of the communication and made the management of the cross team communication. When the project has a clear goal, enough experienced people and adequate resources, communication would become the determining factor in the large scale and long term projects. If projects benefit from the efficient communication and coordinating, it would boost the productivity, vice versa.

 

The importance of the communication

I agree with author’s view that communication is really significant in projects, especially in a single large project. This project cannot be independent and need organization to complete it. There are numerous relevant teams to address the problem together. If we ignore communication here, there will produce many drawbacks, such as functional defects and low quality buggy products. In the paper, the example of slow code illustrates that revising the problem result from lacking of communicating would be a waste of time. Author regards communication as a determined element to make or break the final projects in every large scale projects. It can promote the development of software depending on sharing knowledge and exchanging useful information.

 

However, I disagree that every team needs communication.  In some small teams, communications are carried out directly and regularly. They can learn from each other and solve the potential problems as early as possible. In the mean time, it will also lower the productivity of projects because of a waste of time in communicating. What’s more, when the team did not familiar with the project, they would ask two experienced people in charge of the same module so that we could compare the results to select the best one. According to this case, when the individual team organizes the team communication, it will stiff the creativity in this kind of module since they share their ideas.

 

Organizing cross team communication

Managing cross team communication needs to show many details of projects. Nevertheless, different teams often locate in different sites.  They cannot organize face to face communication all the time. When they use other informal communication (e.g. emails, video, conferencing), it would make a contribution to low confidence, delay, and communication failures. As author’s instance of Nokia and Microsoft, which minimize the need of the communication, there is another example to prove that communication cannot apply to every large scale and long term projects.

 

When a company divides a big software development project into many parts. Different parts are in the charge of different teams. The company gives every team a clear goal and standard documents of the module they are responsible for. The tasks need every module has its independent feature; it could be used in different situations and would not be affected by other modules. The only thing need to communicate is that how to connect all the modules. It should focus on the interface at the end of the project. In case of this, if different teams communicate a lot, it would lead to loss the ability of software module independence.

 

Communication in global software development

Global software development (GSD) is a unique case of distributed software development that the teams across national boundaries. Communication plays a dominant role in GSD teams, but most of them are informal communication. This project was cooperated by two companies: Radiante Corporation and Tekelec. During the time of completing the project, the process of coordination, communication and collaboration is key reasons of successfully developing software. However, this project relies heavy on communication, there are many elements from communication reduce the productivity.

 

Initially, there are numerous differences in culture and language. Communication between the two companies should focus more on requirements definition, negotiation and project management. When they cannot understand each other entirely, it would make the project fail. For example, “ Overlooking the development of the future “ can be explained as overseeing its development or forgetting its development. Also, remote sites multicultural communication would lead to time delays, and failure to understand and explain clearly the required system standard. It would cause conflicts of budget and schedule overruns. In the end, members of the project will lose trust of each other.

 

In order to remove the barriers of communication in different cultures and languages, managers come up with some methods to solve the cross cultural issues. Such as cultural liaisons, bridgehead teams, rotation of management. Although it could address the issues, in the meantime, it will decrease efficiency and take the risk of failing in this project.

 

Conclusion

Communication of large projects has an inherent advantage of sharing knowledge to improve the process of projects and addressing the potential issues earlier. It is essential that communication should play a critical role in many large projects. However, when it comes to creativity, the ability of independent, geographical, temporal, linguistic hurdles, we should consider the styles and situations of communication, which could boost the projects’ productivity. Communication cannot apply to every large project. We need to consider about the different environments and conditions of the project.

Reference

[1] Layman L, Williams L, Damian D, et al. Essential communication practices for Extreme Programming in a global software development team[J]. Information and software technology, 2006, 48(9): 781-794.

[2] Brooks Jr, Frederick P. The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering. Pearson Education (1995): 73-83.

[3] Cusumano, Michael A. “How Microsoft makes large teams work like small teams.” Sloan Management Review 39 (1997): 9-20.

[4] Andres, Hayward P. “A comparison of face-to-face and virtual software development teams.” Team Performance Management 8.1/2 (2002): 39-48.

[5] Lindvall, Mikael, et al. “Agile software development in large organizations.” Computer 37.12 (2004): 26-34.

Analysis eight secrets of the Software Measurement

In the paper “ Eight secrets of Software Measurement”, Betsy Clark gave us eight points on how to make a high measurement and some factors, which could impact the large scale and long term software measurement.

It is not about the metrics”

In the paper, there is an example (It is not about the bike: my journey back to life) to illustrate the measurement is a vehicle for produce some estimates, which could help people find the best way to reach their your goal.

I completely agree with this point. Measurement plays a role in regulating your program. It will estimate the schedule, size, cost, quality, ability and performance of the project. In the end of the program, people still need to make a decision by themselves and put all the theory into practice. In order to create an effective software measurement for the long term and large-scale program, the first thing for us is to understand the aims and find the reasons why we want to make a measurement.

However, during the long history of the software measurement, metrics are always the useful and famous tools for preparing the projects. When we tend to establish good metrics, we should abide by six principles. Initially, we should focus on meet the schedule of the program and reach its quality goals. Secondly, when we make a plan, we should build quantitative goals to allow us to realize them. At the following stage, we should compare the plans with the real performance to find out the potential problem. After that, we should collect data rather than focus on the actual values because the tendency of the data could demonstrate the potential problem better than the data values, and minimize the deviation. Although sometimes there seem to be no problem by the metrics, the problem would be explored by the data values. Metrics would become clarify or obscure their messages.

Measurement metrics are only tools. When we use metrics to make a software measurement, the conclusions are not accurate. For instance, my undergraduate major is system engineering. System engineering method ask experts to list all the factors which would affect the program and category them. Then they set the weight scores to different factors by their specialist knowledge. After we complete the pro-preparation of the data, we should use system evaluation to calculate the matrixes and predict the different kinds of results of the program. This method is so similar to the measurement metrics, especially for the large scale and long-term software program. Apparently, both of these two methods are inaccurate. System engineering matrixes rely on experts’ opinions, and some significant factors selections are intense subjectivity as well as measurement metrics. Therefore, we should not only depend on tools, which will also make some mistakes. Although measurement metrics have a long history and many successful instances, we still need concentrate on the aim of the projects, and then put the measurement into practice.

Success comes from channeling an organization’s pain into action”

During the program, we prefer to have the strong motivation to understand and improve the measurement, and then it is standard practice for people to implement the measurement in reality. In according to the experience of the long software measurement history, we can see that metrics cannot address the entire problem perfectly. Part of this opinion is correct. We have to bridge the gap between the measurement research and measurement practice. Because all the software measurement should be feasible in the real world, that is the baseline of the measurement.

However, in my view, before we put the plan into practice, we have to ensure that is it worth doing that? We need one wonderful measurement to act it, so measurement theory would be significant here. In this theory, we should measure the scale of the program and make sure that the metrics we create should suit the goals. We still need to understand the difficulty of measuring software in any special fields.

After we construct one great software measurement. We have to consider how to put the plan in reality. Many researchers focus on the importance of practice, but most of the practitioners and customers ignore it. When we tend to put the idea of the measurement into practice, we are always establishing models to estimate the conclusion, and the winners’ experience confirmed this.

 Establishing a measurement program is easy, keeping the program going is hard.”

I do not think so. To be honest, I think both establishing the model and keeping the program going are very difficulty. The paper told us that making a useful potential measurement is easy. The difficulties for us are implementing it efficiently and transforming the enthusiasm to action.

Nevertheless, I am sure that establishing a great measurement is also very important. It could create a useful engineering approach to software improvement and process development, which could replace the traditional approach in the past. One successful software measurement should have a close link to the clear definition, detailed explanations and well manipulation. It is easy to establish a model for long term and large scale program by drawing on this information from the measurement.

Absolutely, I agree with the view that put the software measurement into practice is very difficult. We often build models to test the plans, especially for empirical models, we must identify the culture, technology, structure and business issues, which could make a contribution to the model. Also, according to the paper said, some companies even make mistakes that they ignore the business issues and management issues while they make a software measurement. They have to remove these barriers if they want to build the models easily.

People skills matter more than quantitative skills”

In the paper, every step of the software measurement process gains the input information from the people who are attribute to the program. Since all the input information is from human beings, the conclusion of the measurement would be very subjective, such as emotion. Hence when we make a measurement by individuals, emotion would have a huge impact on the measurement. In this case, build a measurement by individuals would unwise.

Also, author prefer to find people who have the talent to understand the requirements and advantages, so the data from this talented people could provide the data efficiently. However, I disagree this idea. It is essential that people should complete some sections of the measurement independently. If people in the organization cooperate together, it would boost the efficiency and avoid some subjective mistakes. For example, The RAND corporation in the USA, their work is so similar to make a large scale and long term measurement. Nevertheless, they never complete by someone individually. They analyzed many different aspects of the program and enquire many experts’ professional ideas. Then they use system science to make the matrixes, in the following stage, they calculate the matrixes and predict the future. Because of their strong cooperation spirit and professional technology, their estimates are always accurate. Hence, people skills play a dominant role in making software measurement. We cannot rely on one person even he is a talented one.

 Senior-level sponsorship and leadership are critical”

In terms of the leadership, author shows us two leaderships are significant. One of them is people on the top should participate in the measurement program to familiar with the projects. Another one is measurement program need senior level sponsorship. As a leader, they should clarify organizational goals; their behaviors need identical to these goals, encouraging expose the problem rather than hide the problem. What’s more, leaders should read the conclusion of the data analysis and reflect some questions, and then they have to make decisions depending on the practical results and their experience.

I agree that every measurement needs leadership to control groups and make the final decision. However, sometimes, manager stay in the group would cause some opposite effect. For instance, in china, when the manager participant in making measurement, others would prefer to yield to manager’s opinion, it would lose some great creative idea from the groups. So it is necessary to allow the people of making measurement understand that they just need to assume their responsibility, and the manager need to find the hide problems and try to address them.

Measuring individuals can be Okay”

Here, author argues that individual work would not fulfill drawbacks. When people make the measurement, they want to escape their responsibility, so they hide the problem. This would make a contribution to delay the completion time and cause a model uselessly. If we can allocate the tasks to individuals, everyone has to shoulder their own parts of responsibility; they would try their best to make the measurement perfectly. Meanwhile, companies could make some schemes to encourage people who can find useful potential problems in the measurement.

Individual work and group work are all good; individual work can stimulate the creativity of the measurement. When we divided the large program into small parts, different people with different background could do different parts of the measurement. It can boost efficiency for the long term and large scale program. In the team, people can integrate their work and exchange their thoughts to improve the software measurement. Hence, if we can combine the independence and cooperation, we could make a better measurement.

Do not go overboard trying to be perfect” and “Understanding the reasons for variability in the data provides a powerful decision tool”

If we want to make a software measurement and establish a model, the most important thing is collecting data. When we collect information from the environment, we have tried to remove the subjective and collect more objective data.

I agree that it would be hard to reach this level because we have to collect information by people. It is possible that we could introduce machine learning to collect data from the environment, which would reduce the impact on subjective emotion. However, the most significant process is how to understand the data and how to represent the data clearly. Different people have different comprehension of the data. When the data represent to the public, people could have different ways to explain the data. If we cannot convey the data so that readers have a consistent understanding, the measurement models are difficult to establish.

I completely agree the “variability in the data provides a powerful decision tool”. Apparently, one predominant characteristic of the real data is its variation. The main point is that if we can investigate what the variation represent, we could well understand the meaning of the data. Although collect data is a time-consuming job, it is worth doing it. When we preprocess the data by statistics methods, we could use these update data and build new models to estimate the significant factors of the potential program.

Overall, create a perfect measurement is very complex and difficult. We must consider the good and bad effects on the model factors. For a large scale and long term software measurement, we should focus on the schedule, cost, size, quality, ability and performance. If we can make models have more cohesion and less coupling, the accuracy of the model will become better. All of the eight points are very informative and fantastic, and if we implement all these points successfully, we can reach a higher level of the large scale and long term software measurement.

Reference

  1. Eight Secrets of Software Measurement. B. Clark. IEEE Software, September/October 2002.(KEY PAPER)
  2. Getting Started on Software Metrics. J. Clapp. IEEE Software, January 1993.
  3. Software Metrics: Progress after 25 Years?, S.L. Pfleeger. IEEE Software, November/December 2008.
  4. Status Report on Software Measurement. S.L. Pfleeger, R. Jeffery, B. Curtis, B. Kitchenham. IEEE Software, March/April 1997.
  5. Establishing Software Measurements Programs. R.J. Offen, R. Jeffery. IEEE Software, March/April 1997.