Software development organizations struggle mightily with planning their development efforts and sticking to the plan. Some Development departments fail to plan at all, other than following constantly changing, seat-of-the-pants estimates, much to the chagrin of the rest of the company that depends upon their output. Others have solid plans that they can follow and use to track their progress, and this shows in the steady stream of new capabilities and releases that result.
Still others live in the messy situation where some of the team, usually management, wants a clear plan, while some or all of the Development team resists being pinned down and made to commit.
The reason Development’s planning efforts are so important is that the rest of the company depends upon the success of such planning in order to plan their own work. Functions such as QA and Documentation (if they are separate from Development), Training, Marketing, Sales, Hosting and Production, and Customer Support all need solid assumptions upon which to build their plans. And this is where the Product Manager gets involved.
Without Development’s ability to pin down dates and expected results, Product Management can’t build reliable plans for product releases, and the entire momentum of your product is affected. So whether a Product Manager wants to or not, he or she must be involved in the planning of Development work.
Read on for ideas on how you as the Product Manager can help get your Development organization to the point where it has clear, useful, and reliable plans.
[private]
Who Gets Involved?
In companies where the Product Manager role is designed to be tightly bound to the Development function, it is only natural for the Product Manager to be integrally involved in planning work for each version, perhaps even driving the planning effort. Other companies, on the other hand, center the duties of their Product Managers in the Marketing area (still others have Product Management operate independently of both these areas). Product Managers located in Marketing have a more challenging time getting involved with Development’s planning activities, because there’s less agreement (not to mention active disagreement) about whether Development planning falls within their scope of responsibility.
Ultimately, whether a Product Manager gets involved in Development planning is driven not by where he or she falls in the organization, but by how successful Development is at planning. If Development is doing fine with its plans, and can deliver code to spec and to plan, then Product Management can successfully plan product rollouts. But if Development plans are consistently unreliable and delayed, Product Management has no choice but to get involved in order to successfully manage releases and the competitive position of the product.
No Plan At All
It can be difficult for a Product Manager to involve him- or herself in planning when there’s resistance from Development. But when there’s no plan at all – and it’s always surprising how often this is the case – then you have no choice but to get involved and stay involved.
With no plan at all in place, nobody in the company believes the dates that Development commits to, including those working in Development. And without a plan, significant money is lost to the inefficiency resulting from the fact that no department has a reliable base upon which to build its own plans. Lots of time is wasted waiting to begin sales and marketing efforts that depend on new capabilities.
The Goal Is the Big Picture
Before you work on developing a plan, you have to determine what your goal is. What do you want out of the Development Plan? What do you want it to do for your company?
The reason you need a Development Plan is so that your management team can know what capabilities will be added to the product and when they will be ready to take to market. Additionally, you need a way of judging whether your development efforts are on time or delayed compared to the plan.
The goal is not to have each individual’s tasks written out in excruciating detail. Instead, you need to have little enough detail that the management team can sit down and look at the pieces and know which ones are on time and which are not, so that the team can make informed decisions on how to cut (or add) functionality to meet dates, or push deadlines back to meet feature requirements.
The Right Development Methodology
There are many different examples of software development methodology in use out in the market. The methodology you choose is intimately tied to the planning effort.
Which methodology you choose is a decision your company makes based on what is right for the people involved, the size of the team, the technology they are using, and your departmental and company culture.
In order to reach your goals for seeing the big picture and for getting software built according to plan, Product Managers may find themselves asking for things that alter or set the development methodology. If, for example, you want to plan and measure progress in month-long increments, it’s worth considering structuring your development cycles into monthly code releases.
The Right Timeframe
The desire to establish control over developer schedules and carefully measure progress and output can lead to excesses when it comes to planning. One reaction is to create down-to-the-minute plans, where each task is broken out into fine-grained subtasks and estimated in hours. Unless you are only measuring the work of a two-person team over a month or two, your hour-based plan will take you down into the weeds. You will fail to see the big picture entirely.
Aim to plan using units of time that an individual developer can plan for while retaining the flexibility required by the fact that a plan is not reality, but merely an estimate. Individual tasks wind up coming in both under and over plan. A week is a good period of time to let most developers plan with reasonable accuracy and get better as they go. It’s also the shortest period of time you probably want to use to track progress. Weeks can be rolled into larger cycles of a month (four or five weeks), to track progress on a larger scale and push new code to QA and the rest of the organization.
The Burden of Paperwork
Another important reason that you want to use suitable timeframes for planning is to reduce overhead from paperwork and meetings to assess progress. Too short a timeframe places an unwelcome burden on developers to submit status reports – either written or verbal – as well as burdening the managers who have to meet to check progress. Keep status checks simple. You want to know how far developers have gotten on their assignments for the week, including how much time they spent fixing bugs, and that’s it.
The Main Hurdle: Planning the Undefined
Software developers resist planning for two main reasons. One is that they feel they are being asked to estimate how long it will take to complete work which is undefined – or worse, can’t be defined – where they can’t possibly figure out how long it will take. There are a few important things you can do as a Product Manager to help developers get past this problem.
The first thing you can do is explain that you are asking for an estimate based on the developer’s best judgment. You are not asking for a hard date which the developer is expected to meet regardless of what new discoveries and decisions extend the initial estimate.
The next thing you can do is to help developers talk through the factors that lead them to state that an effort can’t be defined. Instead of first aiming for a fixed number, have the developer set a range with a minimum and maximum estimate.
Next, help the developer clearly define those factors that are likely to shorten and lengthen the development time needed. Get them written down.
Finally, look at those factors and work with the developer to decide what is most likely to happen, and base the estimate on that. Then note down in writing, on the plan, the most important risk factors (even the min-max range) that could change the time required.
Another Hurdle: Feature Overload
The second source of resistance you face from developers is their experience with being asked to build capabilities to impossible deadlines. After receiving requirements and coming back with an estimate of eight months to build them, for example, they’re told “Well, you’re just going to have to do it in six, because we want the release out by (insert your non reality-based date here).” And then Development gets flack for not meeting a date they said they couldn’t meet six months earlier.
Product Management needs to play an active role if management is overloading the release with features. There are many things that you can propose: “Can we delay this feature? Can we break the feature into a first and second phase, and work on Phase 1 for this release?”
Way Off Course (Of Course!)
Just because you’ve planning things realistically and carefully, it doesn’t change the fact that a plan is only an estimate, not reality. You may find that your development effort gets off course, even way off course.
This is only natural, and the key thing when this happens it to help direct the team towards a constructive reaction. Scale back or drop certain work from the current cycle in order to get back on track. Document the reasons, and more importantly, review risks and assumptions for future work to see if recent discoveries don’t change the original estimates.
Remember that the shorter your cycle to plan and review development, the shorter the possible amount by which you can get off track. To put it more cynically, if you review and redo plans each month, the most your plan can be delayed is one month.
In order to shore up morale and confidence in the planning process, it’s important to focus status meetings on:
- Clarifying delays (determining how delayed you are).
- Understanding the reasons for delay.
- Applying new knowledge to reset future estimates.
- Adhering to the newest version of the plan.
Agile Development, Really
Because you are looking to create a development planning effort that carries the least burden, a workable level of detail, and timeframes that participants can easily grasp, it’s worth investigating agile development methodologies. Agile development tends to structure work into smaller chunks and creates short, iterative cycles of design-build-test activity.
It’s simplistic to think you will transform your development methodology by simply picking a few isolated ideas from one school of thought here and another there. But every Development function is ultimately required to adapt doctrinaire methodologies to suit the culture, personalities, and characteristics of their department, their product, and their company. So take a look at specific techniques of agile development to see which ones can be applied to enhance your development planning efforts.
For example, the index card based Use Case concept in Extreme Programming makes for a fast and readily understandable way to build a plan with estimates and development broken down into little pieces that can be measured every week.
Outsourcing and Planning
It’s worth mentioning how outsourcing fits in with planning efforts. As more and more companies outsource a portion of their development to both save money and augment their capacity, plans need to incorporate outsourcing. The tendency with outsourcing is too often to treat it like a black box: “We’ll tell you what we want, you build it, then hand it to us when you’re done.”
Reports from the field show that outsourcing efforts require tight and ongoing coordination and review between the in-house team and the outsourcer. Planning must also include the ability for your company to regularly measure progress of the outsourced work. While the plan for the outsourced effort may not be as detailed, you want to incorporate that effort in all assessments of progress you make. At a minimum, the management team reviews the outsourcer’s progress once a month. You need the same big picture for outsourced efforts as for in-house ones.
Blaming and Solving
Finally, the ability to support an enhanced planning ability within your Development team depends upon making sure that developers, not just Product Managers and other managers, clearly benefit from it.
As you assess delays and missed functionality compared to the current plan, don’t use deadlines as a stick with which to beat Development over the head. (Well, okay, one useful purpose of deadlines is to hold people’s feet to the fire. But generally if you convince people of the importance of meeting deadlines, most developers will willing try to meet theirs.) Don’t use the plan as a way to blame individuals and crack down on them. Use it to demonstrate problem solving and your commitment to improving plans to make them more reliable. Use the regular assessment sessions to solve problems: “Let’s drop this feature for now. Let’s move the Copy and Paste capability to the next phase. That will put you back on track.”
By improving the Development planning at your company, you create the conditions for the more efficient and profitable functioning of the rest of your company, which depends on the output of Development to execute on their own plans. And that can only be a good development!
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]