Project schedule: A team member departs and a feature is at risk - What do you do ?

This is the kind of situation that no project manager would want to land into. You are into a tight project, and like any other project, there is some amount of tension in the product (it has always been my understanding, and more that of my managers as well that if everything is going fine in a project, there is something wrong with the planning; some amount of tension in the project is necessary for the team to work perfectly and work at full capacity). You have the confidence that with effective project management, which includes some great risk and issue management, you will be able to ensure that incoming issues that could imperil the schedule of the project are handled well, and if there are issues that are beyond your control, you have escalated them to the right set of stakeholders for the next action.
However, there are some set of circumstances that can cause a lot of tension in a project, such as the concept of the team falling behind in the implementation of the initial agreed set of features. At the start of a project, the team and the Product Manager typically agree to a set of features to be implemented during the project schedule. These features also have a minimal set of important features that need to be implemented without fail for the product release to be deemed as worthy of release.
Now, the team is implementing these features and are at the second half of the schedule. Some of the features have been implemented, but there is still critical work remaining to be done. At this stage, one of the team-members working on one of the important feature has to leave - whether this be due to attrition, or the team member having to leave become of some personal emergency. Now you are in a situation where one of the important features deemed necessary for the release of the cycle is at risk, and you need to figure out what you need to do. Here are some possible options, some of which will work while others would not work:
- If the person is leaving because of attrition, then the leaving date discussion can be tweaked to ensure that the person finishes the work and then leaves.
- If the person is leaving because of an emergency, and even in the case of attrition, the transition from the leaving team member to the person who is the replacement needs to happen, and if the amount of work pending to be done is less, this can happen very quickly.
- If the team is a bit ahead of schedule, then it would be possible to still get the important feature done, without stopping any other work. However, if this does not seem possible, then it would be important to ensure that the relevant discussion happens with regard to dropping one of the less important features and getting the more important feature completed.
- If the amount of time left is less, and the completion of the important feature is at risk, then it is important to have a conversation with the stakeholders to ensure that experienced team members are brought in from another team to get the work done.
In all such cases, it is important to ensure that you review the current situation, determine the resource situation and the amount of resources required to complete the important feature, and have a discussion with all the stakeholders. In the extreme situation, if there is a need to ensure that the feature needs to be done and the schedule is at risk, then the schedule may need to be extended to ensure that it is done.

Preparing external teams with feature requests well in advance

One of the most necessary processes in the project development or product development cycle is the handling of requirements. In typical literature, you will learn that the product manager or the product management team generate the requirements at the start of a cycle, and then these requirements are prioritized, discussed and estimated with the product team in order to get to a situation where it can figured out as to what are the set of features that will be there in the given release. Seems simple. However, there are complications in such a situation and planning, especially when it comes to getting work done by external teams which work on their own schedule and their own priorities.
One way of handling this was through providing the requirements to them earlier than the above process. We work with several external teams, such as the team that works on our installer and release process, and teams that provide us components (with the same components being provided to other teams as well). We typically would have a lot of work for our installer / release teams, and hence it was difficult for them to do a lot of new work during the operative parts of the cycle where feature work was doing (getting a stable build and release process, and ensuring that defects were fixed, that glitches in the process were repaired, that builds that were broken were repaired and the process modified to ensure that the builds did not break again for this reason); hence we had to take a new strategy for getting new work done.
What was this strategy. We took the list of features that were proposed for the next couple of releases, and did a sorting of features where there was some changes required from the installer / release teams or from the teams that prepared the installers. Once this done and we had a list, we would run the list again with the product manager and do a prioritization of the features. At the same time, we also had discussions with the external teams on the amount of work that they could do and what was feasible for them (for example, there could be resource constraints or the organization priority for a product could be higher than the priority of your product), and also generated some estimates from them. This was an iterative process, since if a high priority feature required a lot of work from the external teams that they were unwilling or unable to provide, we would have to jiggle the list around to either modify the feature so that it was still feasible, or drop it entirely (and this not easy - once we dropped a feature that was #3 on our top list, but it required support from an external team to a resource level that they were unwilling to commit and for which even escalation did not help). This took some weeks, but at the end of this, we had a list that we could provide to our external teams.
Now all this is not useful unless it is done early in the cycle, and that is what we did. We took the list of features generated from the process that is described above in the middle of the current cycle and talked to our external teams so that they could accommodate this in their cycle; and in most cases, the extra available time was just the buffer required to ensure that the work could be done by the external team and be available in time for when the next version of the product started and work was being done on those features in the core development team. Of course, in some cases, even this extra time will not work if the team is not getting the sufficient priority by the external team, and sometimes you just have to shrug and accept it (after you have done all the escalation and prioritization discussions).

Encouraging a creative team member to assist in the UI designer duties

There are a certain number of resources that any particular software team can have assigned to them. Based on the amount of work that is under consideration of the team, the needs of the team are estimated in terms of the developers and testers vs. the amount of work done. If there is a lot of work and there are not enough developers or testers needed for this quantity of work, then the team has only 3 choices:
- Ask for and get more testers and/or developers, and take on this quantity of work
- Ask for and not get more testers and/or developers, and decline work beyond the amount that can be done with the team that you have
- The third one is the most problematic. The team does not get additional testers or developers, but there is a lot of pressure built to take on the additional work. One would not like to think of such a scenario, but it does happen, and eventually the team either gives up the additional work or takes on a lot of stress, and maybe even has a reduced quality in terms of their deliverable.
However, twice in the past 4 years, we have come across a situation which is not easily solvable, and for which we did not get any additional support. What was this case ? This was the case where the release we were doing had a number of features that required the support of a workflow designer / UI designer. In a typical release, we have a certain number of such resources assigned to the team, based on an expectation that the amount of workflow and UI required will be of a certain % (let us assume that 60% of the work being done by the team needs the support of the workflow / UI team - the reason for it being 60% is that the remaining 40% is where the team does some kind of tweaking / modification which does not require any workflow changes or UI changes).
However, this gets badly affected when there was a release where the estimation of the amount of work where the workflow / UI designer is needed was around 80%, and it was pretty clear that the team that was doing the workflow / UI design was not staffed for this extra work, and even if we had got allocation of budget for the extra work (which was not 100% certain by itself), it takes months to hire somebody with this skill set. Hence, there was no getting around the fact that we had a puzzle on our hands - we had estimated work for which we had enough developers and testers, we did not have enough designers. What to do ?
When we were discussing with the senior members of the team, we came across an interesting suggestion. Over the past, the team had noted that there were some members of the team who were more easily able to comprehend the designs put out by the designer team and understood the way that they were doing their reasoning. Given that we really did not have a choice, we went ahead with the open offer to team members who wanted to give open flow to their creative juices, and prepare the design, with rounds of review by the designer team (we found that this amount of effort could be accommodated), and then present to this team. One of the main persons we expected did not volunteer, but another person who was also seen a prospect volunteered, and we pulled her off her current responsibilities and got her temporarily assigned to the designer team. Over the next few weeks, we did a close watch on this arrangement, and while it was not as good as the design done by the designer team, our Product Manager was satisfied with this, and so was the design team, and we went with the design that she produced and the team accepted. Now, this was not a long term arrangement, but in the scenario described above, it seemed to work.