One of the most critical areas of a software development project is about tracking the status of the project, and ensuring that the various risks of the project are controlled. No matter whether somebody says that their work is important, but these are the most critical items of the project. A definition of risks is difficult, but for our purposes, we would take a risk as something that could cause a problem in the project. What are items that could be risks for the project and would need to be controlled:
- Features taking more time than estimated (either because estimation was not correct or because there were problems during implementation).
- There are problems with the defects cycle in the project. This can be such as more defects being generated, defect ageing being a problem, more defects being rejected after fixed, and other issue in the defect cycle that can cause problems in the project execution.
- The team faces resourcing problems - these could be because of attrition, or the adequate number of people not being there in the project, or tensions between team members or other such reasons related to resourcing.
- Components being used in the software application can cause problems because of delivery or quality issues. So a component that is being used in the project is getting delayed which has a dependency problem in the project schedule or there are quality problems in the component that are unexpected.
- There could be a change in the feature requirement during the cycle. Now, such a change is not expected, but it can happen if a competing product comes out with some features that have been welcomed or some surveys come out with a view that the feature mix is not correct. In such cases, it is not wise business wise to continue with business as-is, and so there would be changes needed which will impact the project.
These are some of the key project risks that you would enumerate at the start of the project and then track through the project. But of course, these are only some of the risks that can come up in the course of a project. The beauty (or the horror of a software project) is that any new risk can come up anytime, and the only thing you can do is to figure out why you had not projected the risk at the start of a project, and how to handle it now.
Take an example of a risk that we had not anticipated during the course of the project. We were working on some new features for our project, and the Program Manager (I don't like to use the first person while speaking about responsibilities) had listed down a set of risks based on his experience (and also after discussion with some other senior members of the team) with the objective of tracking these risks and mitigating or handling them as they emerge. However, suddenly a shocker came.
We got a query from our legal contact about some user data collecting code that we were using in one area of our project. We had a component that we were using for data collection, and so it seemed fine since the component had been verified by the legal team in terms of privacy practices. However, our team had gone a bit ahead and used the component to collect some data which was going beyond the privacy criterion. This has gone by for the past 2 versions without any problems, but in a standard review we were doing for some new work, one of the legal team members had a query about what we had done earlier, and that lead to some serious trouble.
We had to redo the work that we had done 2 cycles back, the developer who had lead that particular project had left for another team, and we were already a bit behind in the schedule. These are the kind of ongoing risks that a Program (or Project) Manager need to consolidate and track, ensuring that the required people are aware of these risks, that mitigation strategies are in place and whatever work is needed to be done by the team or by external folks are all either in progress or are just waiting for the necessary confirmations. Without these, a software project would totally go haywire.
- Features taking more time than estimated (either because estimation was not correct or because there were problems during implementation).
- There are problems with the defects cycle in the project. This can be such as more defects being generated, defect ageing being a problem, more defects being rejected after fixed, and other issue in the defect cycle that can cause problems in the project execution.
- The team faces resourcing problems - these could be because of attrition, or the adequate number of people not being there in the project, or tensions between team members or other such reasons related to resourcing.
- Components being used in the software application can cause problems because of delivery or quality issues. So a component that is being used in the project is getting delayed which has a dependency problem in the project schedule or there are quality problems in the component that are unexpected.
- There could be a change in the feature requirement during the cycle. Now, such a change is not expected, but it can happen if a competing product comes out with some features that have been welcomed or some surveys come out with a view that the feature mix is not correct. In such cases, it is not wise business wise to continue with business as-is, and so there would be changes needed which will impact the project.
These are some of the key project risks that you would enumerate at the start of the project and then track through the project. But of course, these are only some of the risks that can come up in the course of a project. The beauty (or the horror of a software project) is that any new risk can come up anytime, and the only thing you can do is to figure out why you had not projected the risk at the start of a project, and how to handle it now.
Take an example of a risk that we had not anticipated during the course of the project. We were working on some new features for our project, and the Program Manager (I don't like to use the first person while speaking about responsibilities) had listed down a set of risks based on his experience (and also after discussion with some other senior members of the team) with the objective of tracking these risks and mitigating or handling them as they emerge. However, suddenly a shocker came.
We got a query from our legal contact about some user data collecting code that we were using in one area of our project. We had a component that we were using for data collection, and so it seemed fine since the component had been verified by the legal team in terms of privacy practices. However, our team had gone a bit ahead and used the component to collect some data which was going beyond the privacy criterion. This has gone by for the past 2 versions without any problems, but in a standard review we were doing for some new work, one of the legal team members had a query about what we had done earlier, and that lead to some serious trouble.
We had to redo the work that we had done 2 cycles back, the developer who had lead that particular project had left for another team, and we were already a bit behind in the schedule. These are the kind of ongoing risks that a Program (or Project) Manager need to consolidate and track, ensuring that the required people are aware of these risks, that mitigation strategies are in place and whatever work is needed to be done by the team or by external folks are all either in progress or are just waiting for the necessary confirmations. Without these, a software project would totally go haywire.
No comments:
Post a Comment