Again and again, I see organizations struggle with requirements, that component of making software where the needs and desires for new and changed capabilities are defined and handed to Development to build into the product. The challenges stem from one or more important misconceptions about requirements. These misconceptions in turn prevent the team in various ways from providing, creating, selecting, or transmitting requirements so that work can begin on enhancing the product.
Read on for a discussion of ten common misconceptions about requirements that hold organizations back from good requirements and more effective product development.
[private]
Software Requirements Are Visionary
When you believe, as many people seem to do, that requirements must point the way towards transformative changes and groundbreaking new capabilities in the existing product, it's awfully hard to sit down and get started. The team winds up paralyzed because it's expecting too much, almost wanting something which is magical, from the requirements effort.
While it's true that visionary requirements are great, it doesn't follow that great requirements must be visionary. There are plenty of more pedestrian improvements to your product that, over time and over multiple releases, add up to significantly better capabilities. In fact, you may impress the market, and your customer base, more by steady, incremental improvement than by dramatic leaps forward.
It's like improving a house. Nobody will argue that adding a new wing, or placing a second story on a rancher, doesn't make for a greatly improved house. But your house won't be the great house you want without the steady maintenance work to care for the flower beds, to repaint trim, to replace old windows, and keep up the inside.
So don't let a desire for amazing new capabilities distract you from the need for steady, ongoing improvements that build momentum and pay you back over time.
There Is Only One Type of Requirement
Development work is needed to make all sorts of changes and improvements to your software product. Different types of requirements take different approaches.
Using the house analogy again, building an addition or putting on a new roof are a once-in-a-generation activity. Cutting the grass and tending the yard takes place weekly. When you build an addition, you go through an extensive design, planning, and management effort. When you cut the grass, you tell yourself to do what you did last week, but watch out for the rocks you hit last time.
Different types of requirements call for different levels of effort and are the responsibility of different departments. Minor improvements come from customers and users at your own organization. Major new capabilities require Product Management, Marketing, and the management team to help define and design. Performance improvements stay mostly in the hands of Development, with suggestions and feedback from Customer Service. Bug fixes are driven by Customer Service and QA.
Having different types of requirements makes the whole requirements effort more varied and harder to understand than many teams are ready for. It's important for each organization to define the different types of requirements it works with, and to thoroughly explain the differences between them to all team members.
All Software Requirements Are Equal
Highly technical individuals often fall into the trap of believing that each requirement on the list needs the same amount of attention, effort, and definition, and that each should be accommodated and completed. But some requirements are more equal than others. When a Product Manager balances out the conflicting demands from the market, the customer base, customer service calls, and the management team, certain requirements will take priority over others. And priority isn't just an objective, quantifiable process. There are political decisions that tip the balance towards some requirements and away from others. Some requirements will never get selected for Development. And for those who have trouble dealing with that, it helps to understand the following misconception, or myth.
A Requirement Is a Commitment
Many people hear the word "requirement" and believe that it is something that will most certainly be done. This holds true both for customers and your own teammates. The fact is that a requirement is no more than a request from Product Management or Marketing to add something to your product. It is no more a requirement than when your 16-year-old son tells you he must have a new sports car.
An individual requirement is one member on a long list, and may never see the light of day in your product. It's important to capture each requirement, both to encourage people to continue making suggestions, and to gather these suggestions together to look for patterns and trends. But only a certain number of those suggestions will be given a high enough priority to make it into the next release.
There Is Only One Right Way to Do Requirements
There are great methodologies out there for doing requirements. But organizations are different, with different cultures and a different balance of power and influence between Development, Marketing, Product Management, and Professional Services. They are different enough that most organizations must adapt any given methodology to better suit their own situation.
Belief in this myth becomes a problem when a Product Manager tries to take a thoroughly defined methodology from a previous job, or learned externally, and insist that it must be followed to the letter in order to have successful requirements for his or her current product. This is more likely to lead to resistance and failure to implement a requirements process than it is to turn the organization around.
Just like a consultant usually brings his or her own methodology, but must adapt it to the current organization and project, the most valuable contribution a Product Manager can make towards requirements is to figure out how to successfully adapt good methodologies to the product at hand.
All Coding Necessitates a Requirement
Like the analogy above about cutting the grass, certain coding efforts may not lend themselves to a defined requirements process. Bug fixes and performance improvements, or even user interface improvements, may be better off with iterative, mostly verbal interactions between Customer Service, Development, and QA. In many cases the mandate for a written requirement will only delay the improvement to the software.
Other coding absolutely needs to come from well defined, written requirements. But insisting that all coding changes pass through the requirements process adds overhead with little or no value for certain types of changes.
Marketing Creates Requirements
I have often run into organizations that struggle with their requirements efforts because they have only a partial view of where in the organization requirements are created and managed. And the problem comes when one function considers itself responsible for creating requirements and does not acknowledge the other functions. No single function holds all the responsibility. Instead, many functions share it.
This problem stems in part from the fact that Product Management, the function that is ultimately responsible for requirements, often reports into either Marketing or Development, and requirements reflect the bias of the department where it reports. So when Product Management is part of Marketing, there is a tendency to define requirements as the higher level Marketing Requirements that specify, in a very non-technical way, what great, big new features should go into the software. Then Marketing hands off its requests to Development. But this isn't the whole story of requirements.
When Marketing believes it fully owns requirements, you often get great, market-leading ideas, but not tempered by reality.
Development Creates Requirements
After receiving the Marketing Requirements, Development works to understand and clarify them, and then to flesh them out into instructions that are detailed enough that developers can move forward with design, planning, and coding. But when Development believes that it alone owns and creates requirements, it often skips the stage where Marketing analyzes and defines what the market wants. You wind up with software that works well, but doesn't do something that people want. All of this is more likely to happen when Product Management reports in to Development.
The real challenge with requirements is that they are a back-and-forth process between Product Management, Marketing, Development, the management team, and other functions at your organization. Requirements don't travel in one direction down a path from Marketing through to Development. They get passed back and forth to be defined and clarified. The requirement identified as Marketing's top priority may not be so important once Development points out that it would take all the developers an entire year to build. When you create requirements, there is an interaction between the ends and the means to achieve them.
This need for interaction is also why there is no single way to create requirements. The interaction and non-linear nature of requirements development adds enough complexity that each organization finds the need to customize the structure and process.
A Requirement Must Be All Inclusive
One of the bigger hurdles facing an organization is having a staff of developers whose limited time is already filled with more requests for new development than can possibly be accommodated. This makes development of major new features all the more daunting. It's that much harder to set aside time for five programmers to work for four to six months on a big new capability.
This is where a Product Manager can prove invaluable by working with developers to break major initiatives down into successive phases and complementary functionality. With requirements structured to reflect a more granular and phased approach to the development of new components, it becomes that much easier to tackle them a few at a time for the next release. When you read the requirements all together, the cumulative effect is impressive, but what Development always needs to focus on is how to define segments of their work and fit them into the next release, and that's where it helps to have the requirements broken down into small enough pieces.
Requirements Must Drive the Release Date
And last but not least, there's the belief that you must set your release dates only after you define and complete the requirements process. Development is afraid of being forced into doing more work than it can possibly complete by having release dates set independently from the workload necessitated by those requirements which have been identified as top priority. What this belief leads to is an unpredictable release schedule that changes every year, where the rest of your organization outside Development is unable to plan and structure its work around a stable release schedule.
The truth is that requirements will always be unpredictable. What is entirely predictable, however, is how much time you have to develop software, based on simple facts like the number of days in the week, weeks in the month, and people in your Development department. Your organization is much better off selecting release dates and sticking to them, and choosing from the requirements in order to accommodate that schedule. Larger requirements can be partially completed in the upcoming release, with a follow-on phase in the next one.
Mythology Is a Powerful Force
I have touched on major myths relating to requirements, and I'm sure you have run across others. Mythology is a powerful force, and Product Management faces the challenge of helping the organization get beyond these myths in order to be more productive. By growing beyond its myths about requirements, your organization can increase the momentum of its product development.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]