Keeping some capacity of the superstar developers free for quick resolution

In every development team, you will always have a mix of people of different technical capabilities. This may not be for lack of trying; a person may try real hard and put in a lot of effort but may still not be able to work as quickly and as efficiently as another developer who seems to have the knack of being much more skilled. The better developer will eventually get more rewards and sail through appraisals much quicker, just as long the person also puts in the hard work, besides the skill.
Because of the skill levels of the more skilled developer, in a lot of organizations, such a person would be used for more difficult technical work and yet not one that could end up to be boring or repetitive (sounds very obvious, but it can happen that the work that is assigned is not interesting enough and i have known such a skilled developer to want to join other teams when they start feeling that the work they are doing is not really interesting).
One area in which such a developer is used is for new work, or for some new feature where there are expected to be technical challenges and is also critical for the project / schedule. In such a case, one would want the best resources on the team to be on these investigations, since the actual work on these features depend on how well the initial prototype / technical research is done. Once the initial work is done, it might be feasible to hand over the actual detailed work to other members of the team and utilize the more skilled developer for other similar projects.
However, if you want to plan for amount of risk mitigation for the project, one risk that comes up again and again is about serious defects coming up during the cycle, especially near the middle to the end of the schedule. If there is a serious defect coming up in such a phase, it gets more problematic since such a defect needs to be evaluated with a lot of care. While fixing any defect, one needs to be very careful that the fix is done completely and no other problem is caused by the fixing of the defect, and it can and most likely will happen that fixing of a defect will cause some problem (the percentage of such events is low, but not zero, and will happen).
When such serious defects are found near the middle to the end of the project cycle, one really needs to be very careful that these defects are evaluated properly, risks enumerated, and any possible complications reduced or brought down to zero. And as one advances in the schedule, the time period available to do these evaluations reduces. In such a case, it is necessary that the most skilled person in the team either looks at such defects, or reviews the work done by other developers in order to reach the same conclusion.
For this to happen, some amount of time needs to remain free for the skilled developer so that he / she can be put on such defects. Else, if the developer is working full time for some other feature (and it would be an important feature), pulling aside for defect evaluation may not be possible, or may impact the other feature negatively, which has its own impact.

Working on items in your status report that are critical and moving them to a green status

For a good Project manager or Program Manager, maintaining the status of the project is one of the most critical items that they need to do. The status of the project is a dashboard that reflects on the status of the various risks and issues that may be faced by the project, and which can cause delay or otherwise imperil the schedule of the project.
For any project, there are a large number of items that can cause problems to the schedule of the project, but not all of them are problematic at the same time. A risk or issue may be small or minimal at some point in the project and be much more significant at another stage of the project, and it is upto the project manager to have the current status of the project in hand at all stages of the project.
So, you have a situation where the project manager already has a listing of all the major items or issues that can cause a risk to the project and is also on the lookout for more such issues that could cause risk, and it is very important that the project manager highlights the risks that are significant at this point of time and brings them up to the attention of the management team of the product.
But it is not just the highlighting of the risks that is a primary job of the project manager. The project manager is not just somebody who reports the issues and risks of the project, but also takes the lead in trying to solve the risks / issues. For this purpose, the project manager needs to have a good understanding of the risks / issues and work with the relevant people for understanding how the risk needs to be mitigated. This needs to be followed by actually working out the mitigation plan (and if these are known risks or issues that were known even before they were actually a risk, then the mitigation plan would already be known) and ensuring that the mitigation plan is as per the actual risk, since even for a known issue, the actual mitigation plan depends on the exact scenario in which the problem occurred.
In some cases, the mitigation plan does not depend on only the team but may need help from outside the team. For example, there may be a situation where the team is behind in the schedule and needs more people helping out the team, and this cannot be solved by the team; the similar is the case when there is a dependency which needs a resolution from outside the team. In such cases, the project manager should bring this plan to the management team of the product where it can even be escalated to outside the team and to senior management if required. It is the responsibility of the project manager to drive this process and reach a point where the plan has helped in reducing the critical status items of the project to less than critical where they can then be managed to become a normal problem.

Working with external teams for getting them to resolve their defects

When we do our planning for the next release of the software, we normally consider a number of risks, seeking to define a risk database that tabulates various known issues that could cause problems to the schedule and the smooth progress of the project. One lesser known risk that sometimes does not make it to the list of known risks relates to defects with people who are outside the core development team. For example, you may have a component that is being used in the product, and there is a defect against that component. Such defects have a higher risk than defects that are with the core team, even if the defect is of the same severity. There are many reasons for these defects having a higher risk. Some of these are:
- The outside team may not follow the same schedule or the priority as the product team.
- In fact, supporting the product team may be a lower priority for the component team, since they may have been given a task of providing support to other teams. This can happen a lot in organizations where there are a number of teams, and a strategic product will get much more support. For example, if the MS Access team and the MS Office team report defects in a component used by both teams, who do you think will get the priority support. In such cases, there will need to be more discussions, escalations, and other such measures before there is support granted.
- There is a much higher degree of coordination and communication needed when interaction with a developer who is outside the core development team
- The same defect may be treated as expected behavior by another team that is using the same component. You may be having a doubt about why a defect can be treated as a feature, but in some cases, a particular workflow behavior may be seen as a defect by one team, and desired behavior by another team. In such cases, the situation may be such that the defect may never be fixed.
- When the defect is with a component that is an open source component similar, there is no guarantee that such a defect may be fixed.

Given some of these reasons above, defects with developers who are outside the core development team are a much higher risk than most teams tend to visualize. We once had a hair raising case where the component we were integrating had a defect, but somehow the developer working on it was not able to replicate the defect. This was close to an important pre-release milestone, and we needed to get some fixing done on this defect, but this back and forth discussion and coordination at a remote location meant that it took around 2 weeks to get the defect fixed and a new component integrated, and this was a big problem for us.
What do you do when you have such dependencies on extended teams ? Well, you can never really get away from the defects, but atleast have processes setup to reduce the time period and coordination cost for these defects. What should you do ?
- Have an understanding with the remote team about the level of testing at their end. If necessary, send them test cases and ask them to provide completed test cases before they provide the component. This helps in reducing the chances of defects passing through their end.
- Setup a process where they can received updated copies of your software so that they can test with such latest software
- Ensure that the external team totally understands your defect management system and processes and they have been provided permissions for the software.
- Have a protocol with them about exchanging information with them about defects and if there are queries on these defects
- Have a regular meeting with them, this help in ensuring that any issues from either end are resolved quickly
- Ensure that any serious defects are communicated to them at a higher priority. This also includes defects that need to be fixed on priority.
- Define an escalation matrix with them, so that if there are cases where you are dis-satisfied or need quick action, what is the process to follow.

All of these will not mean that you will not have external dependencies on defects with external team members, but the problems associated with these defects will be reduced.

Working with people who are not so responsive as developers or testers ..

It can really test the patience of a team when they work with people who do not seem to follow the same guidelines, processes and schedules as the rest of the team does. It seems a bit odd though. The schedule is the most important item of a software development project, with a lot of effort going towards determining whether the team is following the schedule or not, and if there are any slippages from the schedule, it can imperil the success of a project. If there are slippages of the schedule, then it would take a lot of effort from the project manager and other managers and senior members of the team to get the project back on track. In such a case, it seems strange that there can be members of the extended team who are not so committed to the schedule (actually, it is not right to say that they are not committed to the project, it is just that it can be a challenge to get them to follow the details of the schedule).
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.

Dealing with dependencies that can impact your project schedule ..

Dependencies are the bane of a project schedule, or as one of the developers in a team told me, dependencies and other risks are the reason that a team needs a Project or a Program Manager. I have had informal discussions with some of the senior members of the team, as well as the members of the management team, and there is a lot of discomfort in handling the various dependencies that bedevil a project; as well as doing all the negotiations that are required to mitigate the risk of a dependency, or when the dependency causes a problem to the project.
What am I talking about ? Well, consider the fact that in today's world, most projects have a lot of dependency on items outside the control of the core team. You may be getting some work done from outside the core team by an external team, you may be picking up a component that has been created by an external team (which can be somebody who you pay for delivering the component, or you may be picking up a component that is being done by a open source type of team which produces a component and you pick up the component as and when it is prepared).
However, anytime you are using an external component, you are exposing yourself to a dependency and to a high amount of risk (actually the risks depends to the extent on which the dependency can screw your project). Let me list down a few examples:
- You use a component that is fairly stable (say, being done from another team in your organization). The component is fairly stable, and even though new versions of the component are released from time to time, there is no major necessity of picking up a new version of the component. The dependency is there, but the risk is low and so the mitigation required is also low. Even if there is a problem with the latest version of the component, you can stay with the version that you already have.
- You use a component where there is a bug fix that is needed for solving a problem in your application. In such a case, the risk to your product or project schedule depends on the critical nature of the defect in your application. If the defect is critical to your application, then you have a high amount of dependency and need some mitigation plans. If the component has some problem, then you have to consider the impact on your project and have mitigation plans accordingly. If you are able to survive with the defect in your software, then you would not imperil your schedule if there is any problem in the delivery or the quality of the component.
- Now consider the case of a component that is critical to your product, or delivers a functionality that is critical to your component. For example, when you consider the Adobe Camera Raw and the products that incorporate it, one of the critical advantages that a new version of the Camera Raw provides is support for new Digital SLR's that have been released. So if you were releasing a new version of Photoshop or a new version of Lightroom, it is important for them to integrate the latest version of Adobe Camera Raw because of this support for new cameras. In such cases, if a component is delayed, it causes significant problems for the product schedule and needs a high degree of mitigation. In this case, the mitigation that is done by these products is by enabling this component to be updated later. However, the mitigation strategy for every such component or dependency may not be so easily solved, and the team needs to ensure that there is a lot of thought to how to mitigate these problems.

Program Manager - Ensuring that risks are consolidated and controlled

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.

The Risk Mitigation, Monitoring and Management (RMMM) Plan

The Risk Mitigation, Monitoring and Management, RMMM, plan documents all work performed as part of risk analysis and is used by the project manager as part of overall project plan.
The goal of the risk mitigation, monitoring and management plan is to identify as
many potential risks as possible.It is the organization’s responsibility to perform risk mitigation, monitoring, and management in order to produce a quality product.
Every phase of this plan is of equal importance. More focus is maintained in the initial phases i.e. the identification and assessment of possible risks.
Once RMMM has been documented and project has begun, risk mitigation and monitoring steps commence.
Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.
The measurement of effectiveness of these mitigation / contingency plans should be well carried. It must ensure that after the execution of such plans the risk exposure is reduced or preferably eliminated.

- Risk Mitigation covers efforts taken to reduce either the probability or consequences of a threat.
- Risk monitoring and control is the process of identifying, analyzing, and planning for newly discovered risks and managing identified risks.
- Risk management is the identification, assessment, and prioritization of risks.