Handling risk management as a part of Project Management

If you go through a course of how to be an effective Project Manager, there will be a number of points that would be made as critical processes. Risk management is one of the key points that the Project Manager needs to have a continuous focus on (in fact, some experts believe that once the project is on, Risk Management is the most important focus area of the Project /Program Manager). Like some of the work that the Project Manager focuses on, there is a high degree of subjective factors involved in the definition of Risk Management, but that does not mean that the Project Manager cannot focus on it and figure out how to focus on this area.
In my experience, there are 2 ways to figure out risk management (and bear with me, the suggestions that I am going to talk about would seem very obvious and common sense, but people, even those with experience, somehow seem to neglect some of these aspects; and believe me, with risk management, it can come back to bite you very hard and imperil the possible success of the project). The 2 major aspects of risk management from my experience are:
1. Common areas that are known
There are different ways to handle these 2 different factors. If you look at common areas, these are a list of factors that are common across projects. These are typical factors such as schedule slips, attrition / transfers, feature creep, etc. Any well run organization will have a database of such common factors (and which gets constantly updated in terms of severity of the issues and possible responses / mitigation factors). Knowing all this, if a project manager does not review these issues on  a regular basis and ensures that none of them reaches a critical level, it is entirely on the head of the project manager. However, sometimes it happens that a project manager gets so tied up in the daily running of the project that they do not spend the required amount of mind space on reviewing the risk factors, especially from the common such areas.
2. Unknown factors that can come up any time. These can be difficult to diagnose and even more difficult to handle, but who says that the job of the project manager has to be easy ! So, consider a case (which is also a real life situation), where a competitor made some strategic changes in their product line and this required some real time changes in the way the features being developed had to be changed, which in turn required a lot of changes in the internal schedule, in the resource management and so on. This is an example, a bit extreme, but there can be different variations as well as other kinds of issues that come up (and it is hard to speculate on the wide variety of issues that can come up). The best way to find out such issues is to have regular meetings with the leads and the product manager(s) and track the issues that come up in such meetings; and then follow these issues until they diminish or are otherwise handled properly. 

Effective project management: Controlling scope creep

We had a great Product Manager for our software project. The lady knew all her stuff, had a great rapport with the product support team and a direct contact with some of the larger customers for whom we did projects for. The design team liked how she was able to take the customer requirements and work with the design team to get the requirements into the required details that the High level design documents were able to be generated. Further, the past experience with her showed that she was available during the design and development phase for reviewing critical issues and for any consultation. 

However, inspite of all this, we used to run into issues near the scheduled completion date of our features. The team was always running and running to meet the schedule (even coming in some times during off days in order to meet the schedule - showed a good commitment for the over and beyond effort) and we never did miss the dates by more than a day, and with the required level of quality. During reviews, the team members would detail this problem out, asking repeatedly as to why this was allowed to happen since it meant a lot of extra effort for the team members and why we were not planning effectively. 

When this happened a few times, we decided to investigate more properly - after all, this could be a problem in the way we were doing the time and effort estimation, or maybe some team members were not pulling their weight. We got a couple of the more experienced leads to go ahead and they started combing through the documentation, and effort metrics to determine what was the problem. It was soon pretty clear that the time taken for coding, defect generation and fixing as well as for the earlier preparation of documents was not improper, but there were some cases where the effort overshot the estimation by around 20%. Now we were getting somewhere. However, this could not be isolated to some specific individuals, so there was a need to do a more detailed analysis.

Spoke to one person, spoke to another person, and so on. The surprising conclusion was that this was feature creep. As the people were preparing the design documents and then the development process, when there was a suggested improvement, either by the team members or the product manager, nobody really resisted, since this was apparently doing the right thing by the customer (and in a significant portion of the cases, the case for a small enhancement was put up by the product manager).

We spoke to more people, and although there were some standard design and development reasons for the effort-estimate mismatch, there were many cases where the feature creep was also causing problems. We had to make changes; you really cannot keep on pushing right upto your schedule without drastically increasing the risk of quality issues. We put in a new system  that once the requirements and design were frozen, any new changes, even if minor, would need to be tracked as a special category of defect, called a feature enhancement and these will not be approved unless the defect review team approved the changes.

This gave us a lot more insight about the kind of changes that were being requested, allowed future versions to track for changes made during the course of the project, and ensured a more detailed review of the changes, ensuring that there was no risk to quality. 

Don't hard-code URL's into the software or documentation

This is something that we discovered during the initial versions. We had placed some URL's into the documentation which pointed to some external resources. Then an year later, we got a defect logged into the system, a defect logged by a customer. This was a low level defect, about some URL in a Help Page that was not working, giving a 404 error. However, when the defect got to review, it was the tip of the iceberg, We realized that this had the potential for huge problems further ahead and we needed to change how we do things. Till now, we used to put URL's inside the software and documentation and so far had not seen any problem. However, in this case, the URL was pointing to the page of an external component help file and the external organization had changed the mapping on their site and hence the exiting URL would not work.
Now, this was a minor issue, but it was a pointer to something that was far more serious. There could be numerous reasons why a hard-coded URL might not work:
- Like in the above example, there could be linkages to external sites that are not in control
- Even internal sites could be a problem. We once had a change in the way that the Help file system was working because of a change in the software that they were using (the old software was out of date, and the new one promised a lot of advantages, so there was no option).
- Sometimes there is a change in the Help, and rather than spend a lot of effort to redo the various pages, it makes sense to update the link to point to new pages (which would take far less time).
There can be other advantages once you start thinking about, primarily the increased flexibility you get. So what is the solution ? The solution is to implement a policy of using URL redirects everywhere. What are URL redirects ? These are redirects that instead point to the end URL, but you can change the final destination anytime you want (the redirect is on an internal server and can be modified anytime).
The one thing you need to do is to ensure that you map every redirect URL, where it is used and the final destination on a file along with the date, some comments about what it is for, and who had asked for the redirect. This needs to be saved along with the other components of the code on a source safe kind system, and ensure that any changes to these redirects need to be done through the process of a defect mapping so that the entire information about why the change needed to be made can be mapped.
This policy adds a layer of extra effort, but anytime you need to make a change to the URL and you find that you are not able to make one because it has been hard-coded inside released software, you will realize the advantage of such a policy. 

Keeping up with security fixes / patches and the like

Every other day, you hear about some major security flaw letting hackers steal credit card information, steal passwords, social security numbers or something equally serious. Such news can seem remote, but not for the organization that gets impacted by such news. In such an organization, the impact of such security lapses can be shocking and dramatic, including people getting laid off and stock prices getting impacted (unless it is a mega-billion revenue earning organization which need earth shaking news to cause upheaval, small scale security scares are something that they are used to).
You might think that this is something that does not impact you too much, since nothing major has happened in the past and you are not likely to be the target of hackers. However, it is not necessary that hackers directly target you, but that there are some problems in the code that has been discovered that is not yet fixed (or fixed and not incorporated by customers) which can cause security related attacks. What is a likely scenario ?
Most large or even medium scale projects use external components for features that they need to deliver - my favorite example has been the use of decoders for handling the different image, audio and video formats, as well as the inbuilt capability within the Operating System. It is impossible for most applications to write their own software for such purposes, and they use external components for such purposes (paying a license fee or royalty or using free software for the same purpose). There are numerous other examples of the use of external components. Now, when you have incorporated an external component, it is practically a part of your own software and gets distributed with it.
If a security hole or some other such problem is there in the external component, then till the time it is patched and the patch is incorporated in your software and installed with components, there is an ongoing risk. It becomes even easier since there are numerous tools that become available which allow even non-hackers to exploit such holes or security issues.
So what is the method to reduce the risk of your customers getting impacted by such a problem? You can never entirely reduce the risk to zero, but there are a couple of strategies you can do to learn and handle the issue.
- Have a matrix of the various components you use, the critical nature of these components, is their usage such that they can be exposed for a security attack
- For each component, how would your team get informed that there is a new security flaw with the component, the severity of the flaw, when it is likely to get fixed and who is the person within your team who has the primary responsibility for evaluating any such flaw
- Detail the next step of action were such a flaw discovered. This would of course depend on the nature of the flaw, how likely it is to be exploited and other such factors, but you need to have a pre-defined strategy on how to respond (you cannot try to detail such strategies when the issue is faced, it can lead to a flawed execution)
- This one is more tricky. What should you do if the issue is found in the last released product / previous releases. This depends on the level of support you provide for previous fixes and the evaluation of the previous steps. For example, for a release that was done 2 versions back, if a small security flaw is found in an external component, and the presumed impact is minor, you may choose to not provide a fix
- Define a communication strategy for customers to let them know and to alleviate any concerns that they might have   

Partnership with an external party - quick prototyping / solution

A couple of years back, a major disaster took place. We had tied up with an external mobile based organization, larger than us, for providing a customized version of our software which would act as an entry point to their software. Such deals and partnerships happen all the time; the schedule was aggressive, but which schedule is not. Deals such as these are the life blood of a growing organization, since it helps develop partnerships and also builds credibility for other deals (even when the deal may be under an NDA, since you can still use such deals for other partnerships without revealing information that might break the NDA).
So, our marketing team along with their technical team (and a few points from us) managed to seal a deal and there were a lot of congratulations and happy faces. Since the schedule was aggressive, the work started right away. However, within a few days, as the proper design phase started, it became clear that there were problems involved in the probable design. The design changes needed were complex, the number of technical resources that were allocated were far less than the amount required after the design process was evaluated. And with the passage of time, it became clear that the process was only going to go downhill. It was an important collaboration and the organization was willing to add more resources, but the timeline was just not working out. After a series of frantic meetings, it was decided that rather than deliver an inadequate product, it was better to break the deal within time and still be able to maintain a relationship.
Given the importance of the deal and the critical nature of avoiding a situation like that in the future, there was a need to do a thorough analysis of where the problems lay. The analysis took some time, but it soon became clear that the level of interaction with the team that actually owned the product was very low and there was not enough time spent to figure out whether the solution was indeed feasible in the timeframe and with the amount of resources that could be committed. Now, this kind of problem had never been this severe in the past, but now that it had happened once, it became clear that it could occur again in the future. So, the relationship process had to be modified to include more time for a technical evaluation; if the contract was very large, then even a prototype may need to be built before such a contract can be signed off.

The importance of code walkthrough and reviews

When one studies software engineering, the importance of review like activities are actively mentioned. However, during the pressure of actual project work, there is always pressure to reduce the amount of time spent on these activities; in many cases, this is something that the project manager might push. And there are a number of such review activities that happen during the course of the project. Here are some example:
- Requirements / Design review: During the process of detailing the requirements, there is a need to do a review of the requirements to ensure that the requirements cover the entire feature needs and is  comprehensive. When the design process is done, there is a need for experienced design folks to review the design documents / architectural documents and related documents to ensure that the best possible solution is designed. In a number of projects that I have seen, such reviews typically are very value enhancing and can add a lot of improvements to the design documents.
- Test plans / test cases review: Once the design documents have been prepared, the testing documents get into high gear (in many cases, the test plan document would be started before the design documents have been completed). The testing process is critical to weed out all the defects / improper features in the software; if the test plans and cases are not comprehensive, then there would be problems with the software. Hence, a comprehensive review would be necessary, in many cases with the developer also participating.
- Code walkthrough: Code walkthrough is not done for all the code, typically done for the more critical sections of the code. In addition, as the software development process nears the end, this process gets more critical. There have been cases where a defect fix has failed, and caused more problems for the team in trying to figure out what went wrong. The advantages for a code walkthrough are very high.
- Defect review: This is not something that happens in all cases. What happens in many projects is that when a defect is written, it goes to a defect review committee that reviews whether the defect is valid, whether it has the proper severity and priority, and also whether it needs to be fixed. The committee can then decide whether to actually allocate the defect for fixing. This kind of process does add some overhead to the defect process, but can help prevent some defects from getting fixed which are not needed, and also whether the proper allocation of defects to people.
- Defect fix review: This can be critical, especially with defect fixes that touch core areas of the design or the architecture and need a proper review. This overlaps with the code walkthrough as well, but to ensure that the defects are properly fixed, this part of the process is critical.

One can quibble about the amount of time needed for such process work, but the need for reviews at different stages is critical and needs to be done. 

Coordination with external teams - regular meetings to track progress and status

Sometimes when I review some of the posts that I create, it seems like something that is so obvious, why would there be a need to even create such a post; everybody would already know this. And then, one comes across cases where it becomes clear that some people do not really know the contents of the post, that they get into problems which have been described in some of the posts. So the idea of such posts is that people read these, see whether this applies to their current situation, and work out any changes if required. If they are doing things superior to what is being written about in the post, then I would be really grateful if they can update in the comments.
For any team that has been working for some time, especially in the area of product development, there will always be the need for working with external parties. These can be other teams within the organization that depend on your product, or provide you with a component. There can be teams outside the organization with whom you are coordinating with for either inputs or outputs. For example, a simple case was whereby the marketing team had made a deal with a phone manufacturer for loading the product as a pre-loaded application on the phone (yes, the same type of product that many reviews call bloatware, and which users sometimes are unable to uninstall when they get the phone in their hands).
You might think that this is a simple transaction, you provide the product to them and they incorporate it into their phone, with schedules being the major tracking. However, life is not so easy many times. In many cases, we have had to add tracking parameters to the product which let us monitor how many times users loaded the product that was on the phone (as opposed to getting the same product from another source, or buying from us, and so on). All of this requires coordination (and there can be numerous cases where such type of changes and coordination needs to happen).
When you are dealing with teams that are outside of your organization, you should never make the mistake of assuming that they work with the same culture as teams within your organization.
Coordinating with such teams needs to ensure a proper system of tracking requirements, changes, issues, closing issues, defects, status and setting the grounds for acceptability testing (to ensure that both teams are in agreement over what is needed to finally state that the product is good to go).
- There is a need to define responsibilities and contact details, who does what on either side
- With these responsibilities, a further need to map ongoing work to people along with timelines and what the output should be like
- Set up regular meetings for discussing ongoing issues, working through the schedule, deliverables, action items, and escalations
- As work proceeds, define the changing mix of people involved in the discussions (for example, earlier states may have a mix of development and marketing people, and later, when work is ongoing, more of development and testing people from both sides)

This is the general idea of how you go about working with people from outside your organization; the exact granular details of this coordination would vary from team to team, and from project to project.