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.

Giving time for the testing effort

The testing process is one of the most fundamental parts of a software project. Any software that is built (or modified) would have defects in it. Even the most confident of software developers and the most skilled would admit that there will be defects that creep in when they are writing their code (in fact, the best ones are a part of the testing effort, working closely with the testing team to ensure that the team fully understands what all has been done so that they can do their best to tweak all the defects out). So it is well understood that there is a need for testing in order to deliver a high quality item to the end customer; and the process of testing tries to ensure that most of the high severity defect are found out and fixed during the process.
The challenges come in terms of ensuring that there are enough resources for the testing process and the amount of time required for the testing process is also there. There can be a lot of pushback on this front from the project managers and others in the management team, since the development and testing schedules do take up a significant amount of the overall project cycle. From my experience, there is a fair amount of pressure on the test team leaders about pulling in their estimates and trying to get that part of the project done early. If you speak to some of these testing guys, their common refrain is that management typically (in a majority of cases) do not have people that came from a testing background and hence do not really understand the work we do, and hence we get pressured a lot.
So what is the way out to ensure that the testing estimates are accepted, even though there may be some rounds of discussion and some estimates may be refined (could be reduced, or in the off case, during the process of estimation and discussion, there may be some upwards estimation of the estimates as well). Well, like many other issues that come up during estimation and planning, there would be some amount of rigor combined at the same time with some amount of rough estimates.
How does  rough estimate come up ? Well, if you have experienced testing leaders, when they look through the requirements (at a top level, since detailed requirements may not exist, but summary requirements would be there), they would be able to give a fairly good and rough estimate for the testing effort required, which can be broken down into number of people for the desired schedule.
Another way is to see similar projects (a lot of projects in large organizations can be similar, which gives a good idea of the testing efforts for a new project, at least as a good point for comparison purposes).
The effort is in preparing detailed testing estimates by taking the different requirements, breaking them down into test plans (more detailed test cases may not be possible given the state of requirements at this point of time). Some amount of rigorous review of these plans would give a very good consolidated testing requirement, both for the testing effort estimation and for later needs when these test plans would form the basis for preparing more detailed test cases.