Purpose 

To clarify some possible misconceptions about the goal of this article series, it is NOT to advocate that there should be unrealistic schedules.  Quite the contrary, I don’t support expecting a team to deliver herculean efforts.  It’s an unsustainable model.  However, dates and requirements are often forced upon software teams, and they often have little ability to influence the commitments, both in date and content.  The goal of this series is to outline a model to successfully manage through these challenging circumstances for the benefit of the company, the team, and yourself.

Risk Management 

To manage this project successfully one model is to approach this project as an exercise in risk management.   The risk is the team will be unable to deliver the project sponsor’s complete set of requirements on the commitment date, and in an attempt to completely satisfy those commitments the team will likely deliver much later and with lower quality than is required for success.  The steps outlined in part 2 of the series essentially identify a contingency and mitigation plan for managing this risk.

Contingency Plan

The contingency plan is to identify the most important requirements that can be successfully delivered on the commitment date (Steps 1 and 2).  Believing the odds are highly against delivering the complete set of requirements successfully, you identify a set of requirements that you can successfully deliver by the commitment date.  Solicit the support of the project sponsors to identify the prioritized requirements for the release.

If you are unable to successfully enlist the support of the project sponsor’s in prioritizing the requirements, you will need to do this on your own.  With the domain knowledge that you already have, view the product from a user’s point of view and prioritize the requirements from that perspective.  While it won’t be perfect, you will likely identify many of the most important features.  If you’re fortunate enough to have customer contacts, ask them for input.  Once you’ve done that, it would be helpfully to review your prioritization with the most experienced members of your team and revise the prioritization based on their input.

Mitigation Strategy

The best way to manage a risk is to prevent it from happening in the first place.  A majority of the steps outlined in Part 2 of the series is about risk mitigation. 

The first mitigation strategy is to make sure the requirements are well understood before implementation begins (step 3).  Review the requirements with the team to ensure there is sufficient detail and understanding for the team to implement the features successfully.  Much time is wasted on projects when developers don’t have adequate understanding and detail of the requirements.  If some requirements are detailed adequately to begin design and code, start the assignee on that work immediately.  I’m not suggesting everything needs to be understood before you start the implementation, but I am recommending that you don’t start the implementation for any feature where the requirements are incomplete or where the detail is insufficient. 

The second mitigation strategy is to get it right the first time (steps 3, 5 and 6).  This is supported by up front designs and reviews.  Some methodologies in practice today promote the idea that it is impossible to get designs right up front and promote constant refactoring as an approach to arriving at an optimal design.  This is not my experience at all.  I’ve seen wonderful designs that were implemented from an upfront conceptual approach, and they lasted for many years and supported many successful iterations of the product without change.  A poorly architected system is a drag on productivity.  Refactoring as a design approach is costly and consumes too much time.

The third mitigation strategy is to create a productive work environment (steps 4, 7, and 8).  Create a culture that is solution oriented.  The team views problems as challenges to be solved rather than events to fear.  Every worthwhile software project that releases surmounts many technical challenges.  Surmounting technical obstacles is what software development is all about, and it is part of the fun.  When technical challenges are accepted as natural, it promotes an environment of collaboration and support.  Team members collaborating and supporting each other will promote better and quicker solutions.

The fourth mitigation is to promote high quality (Steps 6 and 8).  Software development is tedious and error prone, and consequently, defects are unavoidable.  It is far healthier and more productive for the team to view defects as problems to be solved rather than events to be feared.  While it is possible that too many defects could derail the delivery, it is more important to release the project with high quality.  Identify release criterion that promotes high quality.  When a product is released with low quality, the next project begins day one behind the Eight Ball.  That needs to be avoided.

The fifth mitigation is to be proactive in your management (steps 9, 10, and 11).   Identifying problems early allows the team to find solutions without impacting the release date.   If some features are progressing slowly, it may be because the assignee is struggling with the implementation.  If you identify that early, you can help them before it impacts the schedule.  It may be progress can be enhanced by adding one or more additional team members.  When you discover that early, you may have the opportunity to secure those team members in time to make a difference. 

Having weekly status meetings sets a pace for the delivery.  When team members are expected to show progress towards the schedule on a weekly basis, they tend to be more focused on the strategy, and they will typically demonstrate good progress.  The weekly status/tracking meeting reinforces what the important deliveries are to the team and their expected completion thereby improving the team’s chances of achieving milestones along the path to the release date.  A successful release is built upon a series of successful weeks.  Make sure every week is a success.  This is best achieved by meeting with your team and tracking the schedule weekly.

Summary

If your risk mitigation strategy is successful, you may have been successful in delivering upon all the commitments on the original release date while not burning out the team.  Often times the impossible becomes possible with good planning, good execution, and a disciplined approach, but even if you happen to be unsuccessful in delivering the complete set of commitments, you have put the team in a position of strength.  When you discover that you cannot meet the commitments as planned, you can offer the project sponsors some palatable options.  Assuming you secured the highest priority requirements, you can present three good options to the sponsors:

1. Release on the release date the highest priority commitments with a follow-up release a short time thereafter with the missed requirements.
2. Slip the release date to secure all or some of the missed requirements.
3. Re-prioritize the missed requirements that can still be delivered within the original release date and ship on the original release date.

While some project sponsors will be sorely disappointed with these options, it surely beats having nothing to deliver on the release date, and it is undoubtedly better than offering only one option: slip the release date as is often the case.   Over time you will build confidence in the management team for making good decisions, you will develop a reputation for reliable delivery, and consequently, as you build your reputation, you may find you are less pressured to deliver the impossible.