Management Approach

I’ve identified eleven tasks that I believe are essential for delivering to an unrealistic schedule.  While the tasks are numbered, they signify a loose priority.  It’s not intended for them to be followed exactly one after the other except for the first two.  The first two are the most important of the tasks, and the approach hinges on the first two for this to be successful.  When you’ve completed the first two tasks you’ve essentially identified your strategy.

1. Identify the feature priorities.  Hopefully the Product Manager will help identify them, but it is sometimes the case that they are unable to decide on the priorities.  If they don’t, you have no choice but to ascribe your own priorities to the features.  The best way to do this is to view the requirements from a user’s perspective.  As a user of the product what would you find most to least important. Accept that this isn’t perfect, but it’s better than having no priorities.
2. Now that you have the priorities identified, put a schedule together that will absolutely deliver the largest number of high priority features with high quality. This schedule will still be aggressive and people will still be required to work overtime, but it should be a comfortable pace.  This is your first iteration that you will deliver to test.  Schedule the remaining features to fit the time remaining as best you can - even time box them if you have to.
3. Review the requirements with the software team making sure there is sufficient detail to deliver the functionality as requested.  If the requirements need further detail, then assign requirements writing to the developer responsible for implementing each feature.  Divide this work up; it needs to be completed quickly.  Some teams have Systems Analysts or Business Analysts that perform this work.  Supplement them with your developers.
4. Don’t postpone solving difficult problems.  If you postpone the difficult problems you’re creating a train wreck.  Call a meeting with the right subject matter experts and begin solving the problem. There is no time to discover the problem is bigger than thought or the proposed architecture won’t accommodate a solution to the problem. Discovering and solving problems early and quickly enhances the team’s ability to deliver quickly.  I’ve found the greatest time waster on projects is when problems go unresolved seemingly forever.  Things like not having agreement on how a feature should work, or not having engineering agreement on an interface definition.  When closure takes too long, it slows people down and the backlog builds.
5. Do up front design and hold design reviews.  As the manager, participate in the reviews for the most complicated and/or important features.  For the others, make sure your top engineers are involved in those reviews.  There is no time to use re-factoring as a methodology for arriving at an optimal design.  You only have one shot at this. Make it your best shot.   At this point things are a little scary because time has lapsed and you have little working code to show for it.  Be patient.  This is an investment and good investments take a little time to show returns. 
6. In parallel to design, the QA team should be developing their test designs.  Include the QA team member in the design reviews for the features they will be writing test designs.  Assign to the developer implementing the feature the responsibility for making sure the test designs are thorough.  The QA person writing the test design should feel comfortable approaching that developer with questions. This developer is responsible for reviewing the QA test design.There are two reasons for this:  the developer is ultimately responsible for the quality of the delivery and this affirms that, and the developer writing the functionality will know more about the feature than the QA person.   There may be differences in opinion on how the feature is supposed to work.  This is good because waiting until test is not the time to find that out.  This is a team effort; there should be no mentality of throwing the build over the wall for test.
7. Create an environment of teamwork and be solution oriented.  You don’t want team members to fear bringing problems to your attention.  Out of site, out of mind is not a successful approach for delivering this project.  Eventually, hidden problems become visible tumors.  To avoid that, you need the team members to feel comfortable with bringing problems to your attention early.  Don’t solve the problems for them, unless they are ones only you can solve, help them to solve the problems for themselves.  The only bad problem is a problem without a solution and one that was withheld.
8. View identification of defects as positive events, even if you find a lot of them.  Each defect identified under test is one less problem discovered by your customers.  If you find lots of them, you’re customers probably won’t find many as there won’t be many for them left to find.  Anecdotally, I have found that the more defects found in test, the higher the quality of software when delivered to customers.  Taking this attitude removes unnecessary stress and anxiety from the team, and consequently, they will perform better.   Writing defects is unavoidable in software development. Everyone who writes code writes defects.  Focus positively on finding and fixing them — no matter how many found.  The focus should be on flow — making sure defects are fixed as fast or faster than they are found.
9. Practice management by walking around.  Don’t be a nuisance, but show genuine interest in what the team members are doing and how they are doing.  This has positive benefits to team morale.  Many managers today manage behind a closed door and communicate via emails.  Every team member I have talked to has disdain for this approach.  Do it under a tight schedule, and they do not respect you. You need the team’s respect to have them perform at optimal performance. Build relationships.  Taking the time to talk with people and to know what they are doing and the problems they are having in a sincerely interested manner says that you value them and that they are important.  That’s the message you want to send because it’s true.  You can’t send that message from behind a closed door.
10. Be disciplined about tracking the schedule; track the schedule weekly.  Preferably use metrics for tracking.  It’s the best approach for bringing objectivity and actionable indicators to the tracking process.   The reason this is so important is that early in the project time is on your side.  If you know how the project is progressing to the schedule more accurately, you can make decisions early enough to solve the problems and bring the delivery in on schedule.
11. When you’ve detected that the project will not deliver on schedule, determine what you need to do to change that and meet with the project sponsors to agree on a course of action. Determine the following: if more people will help to bring the project in on time, identify how many, what skills, which individuals, and for how long.  Identify the features you would need to remove from the project to bring it in on time: this should not include those high priority features identified in step 2.  Identify how much more time would be required to deliver the remaining features.  You have to have an estimate you are confident of nailing with good quality without skipping important steps like design, etc…

Summary

The goal of this approach is to develop a strategy, focus on solutions, identify problems early, focus on quality, use time wisely, be proactive, and encourage teamwork.  In the next and final installment, I will describe how this supports managing an unrealistic schedule successfully.