Note: I am pleased to announced that I am a nominee for the 2006 Excellence in Product Management award for Thought Leadership given by the AIPMM. I will be at the AIPMM conference this April 19-21 (see www.aipmm.com) and hope to see some of you there.
When Product Managers push to accomplish their goals for a product – more sales, more customers, more profit – they must struggle to identify and overcome the obstacles and limitations of their individual product, team, and company. Each company's weaknesses are unique, and require careful focus and willpower to overcome them with a solution whose uniqueness matches the problem.
But problems that are unique to a company are relatively easy to spot and solve compared with weaknesses that are common to an entire industry, such as the software industry. Industry-wide problems create a situation where there are few people to turn to who even see beyond the blind spots, let alone can point to models for a solution.
In the previous issue, I wrote about what I consider the software industry's greatest weak spot, namely creating product requirements for software development. In this issue, I'll tackle another major shortcoming, which is none other than planning software development.
As a Product Manager, chances are you find yourself working with a software development function that is challenged when it comes to planning. And so much of the success of reliable development of competitive capabilities depends upon good planning.
Read on below for a discussion of how to better understand the planning of software development — and how to overcome some common hurdles.
[private]
Does It Really Matter Why?
If you're wondering why it is that planning seems to be such a difficult activity in the software industry, perhaps it helps to understand why.
The main feature of software is that it is squishy, to put it in a very non-technical way. It's hard to pin software down. It doesn't seem as real as hardware or even services. When you build hardware, it takes lots of planning to put together the correct number of parts in the correct order. When you deliver services, they are bounded by a specific number of hours or a specific outcome, which is often documented and signed off on. There are only so many hours in a day and week, so you have to plan carefully to fit in the time required to deliver services.
But software doesn't seem so easy to pin down. Things like the time needed to develop software can be stretched and fudged. If you hurry, you can develop the same capability faster. Or if you develop code but testing reveals lots of errors, the fixes mean that you wind up spending much more time than expected in order to complete it.
Because of this, the software industry has been able to get along with less planning than, say, the construction industry. In the end, however, it doesn't really matter why. What counts is to realize that planning is not generally a strength of the software industry, and therefore chances are good that lack of planning is holding you back.
Planning Helps Solve Every Problem
Planning brings a benefit to just about everything you do. If you develop software, having a plan helps you do so in a more structured and predictable way, and probably more efficiently. If you market software, having a plan helps you do that as well. Like automation, planning can be applied to almost anything to improve it.
So it helps to apply better planning to all the difficulties you face. Does your company need to do a better job with product requirements? Try planning the effort more carefully. What about QA? Develop a plan for testing. How about invoicing customers? You can probably benefit from better planning there as well.
By planning every effort a little better, you can achieve a number of incremental improvements that add up to major progress. Don't just plan software development, plan the visioning, requirements, planning, design, testing, and rollout.
Planning Is Not Your Only Problem
While planning is involved in virtually everything, it will not solve all your problems. Software development requires planning and much more. It requires a strong vision, communicated well, requirements which are well chosen, well prioritized, and well defined, a development methodology that is suited to your product and your company, and more.
It is important not to fixate on better planning as the only cure for what is usually a tangle of problems. This is a parallel problem to the one I mentioned in the previous issue, where companies believe that better product requirements will solve all their problems.
Planning and Requirements
Planning and requirements are two separate pieces of software development. Better planning of your software development process won't necessarily result in better requirements. Better requirements won't mean you can make do with poor planning.
Requirements focus on what you need to do. Once you have decided which requirements you want to develop, and designed how you will develop them, planning focuses on structuring the development work. It's purpose is to make the development work more reliable and predictable.
Planning and Planning
Plans can be very detailed or very broad-brush. I have often encountered attitudes among software development organizations where it was assumed that there is only one kind of plan, and it happens only at a specific point of the software development lifecycle. In fact, there are preliminary plans, high level plans, detailed plans, and, where warranted, separate plans for specific portions of the development work.
Your organization may not have the bandwidth to create anything other than a high level plan. While it might be nicer to have detailed planning, you are not obligated to choose between planning everything or nothing at all.
I have spoken with people who thought they had planning nailed down tight at their company. They had extensive plans with hundreds of line items, all laid out in Microsoft Project and complete with dependencies and baselines. And perhaps that was necessary. But plans that get to big and too detailed can become time-wasters that are not worth the hours spent checking statuses and keeping the written plan updated. The view of the forest gets lost in the attention to the trees.
The key to proper planning is realizing that the definition of "proper" depends upon your organization, its culture, and the product. To benefit the most from planning, select the amount of planning detail that best suits your situation.
Planning and Design
Should you design before or after you plan? How can you do a good plan if you don't know the exact design beforehand? Conversely, why should you have to know everything about what you will design to create a solid plan that will hold throughout the development work?
This issue of whether to do a plan before or after the design is one that seems to cause a lot of organizations to get stuck. It's one of those false either-or choices that wind up stopping progress.
In reality, it is not an either-or choice. You are better off doing planning before design, and incorporating your design efforts into the plan. Use your best effort at assumptions that will hold up during design. But when the results of the design work inevitably lead to a change in the plan, revise the plan to reflect what you have learned and move forward with development.
Planning and Development
Planning is not the same as your development methodology. Your development methodology describes the steps you take and the methods you use to develop software. Planning, on the other hand, serves to create a more defined and specific structure for and tracking of those steps. It improves how neatly you carry out your methodology, but does not change your methodology itself.
Analysis Paralysis and Planning
Planning can be a way to move your organization out of analysis paralysis, where your team continues to seek out and take in new information, revising and rethinking with each new piece of knowledge. Analysis paralysis can prevent actual development work from ever starting.
Planning can help you leave analysis paralysis behind by setting bounds around the analysis work, stopping it at a specific point in time and noting the assumptions, risks, and unknowns. And then, most important of all, by setting out the tasks required to get started on actual work.
You can plan for analysis paralysis by planning for a cutoff point after which work begins with less than perfect knowledge and preparation.
Planning and Uncertainty
Planning addresses the future. And uncertainty and the future go hand in hand. Many organizations get stuck on the fact that part of their work is uncertain, and don't know how to plan for that.
When faced with uncertainty, take a long, hard look at it and define the likely minimum, maximum, and midpoint. For example, if your design calls for learning a new technology in order to incorporate it into your product, it may not be clear just how much time the learning curve is going to take away from the normal productivity of your development team. When faced with this, create a low estimate (we'll lose a week) and a high one (we'll see our productivity cut in half for four months), and determine a spot on the range that appears most likely to be the case. Then specify your decision as an assumption and plan accordingly.
Since assumptions will prove to be more or less correct as time goes by, plan checkpoints where you will assess progress and revise assumptions based on your actual experience.
Planning the Unplannable
Some tasks seem unplannable. For example, you never know how much bug fixing of the existing release will be required while you're building the next one. Such quandaries often paralyze people into not planning at all.
But there is a better way. Though you cannot plan the specific details, or the daily and weekly fluctuation in time spent fixing bugs, you can come up with a reasonable estimate of what percentage of your time will be spent on bug fixing. Then carve that percentage out of your plan. If the plan calls for 50% of your time fixing bugs, then at most 50% of your time can be spent developing new capabilities. Knowing that you have 20 hours per week on average per developer for new capabilities, you can plan the work with reasonable accuracy over time.
There Is Outside Help For Planning
The best piece of news about planning for the software industry is that there is a lot of outside help. Planning is the subject of its own career specialty, with plenty of advice, methodology, and certifying bodies. The Project Management Institute, for example, at www.pmi.org, can provide a wealth of opportunities to develop planning expertise.
With solid planning applied to your software development process, you can avoid delays, increase developer productivity, and schedule your marketing and product launch efforts for greater impact in the marketplace.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]