The path to building great software goes through scope management and to define the project requirements. As a software professional, you know all too well that software development isn’t easy. A software product is never completed.
There’s always an opportunity to improve functionality and there’s no shortage of challenges to overcome along the way:
- Lots of people involved in the process
- Customers have difficulty articulating their real needs
- Requirements constantly change
- Teams are spread across multiple geographies
- There’s growing pressure to release products faster
- The complexity of software doubles every 2-3 years
- More projects fail than succeed
Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success. And, the path to building great software goes through scope management. Organizations that embrace this concept enjoy greater results. They experience fewer errors and frustration, faster planning and development cycles and they’re able to deliver higher quality products to their customers.
Tip #1 – Stay Connected
You can eliminate most issues by keeping everyone connected.
So much attention is placed on the high failure rates of software projects, it has been shown over an over again that communication with all parties is the key to a successful project. If you can get connected and stay connected throughout the entire development process, you can eliminate the vast majority of issues.
| Collaboration | Keeping your entire team connected throughout the development process |
| Traceability | Keeping all the requirements, artifacts and other related information connected |
There are two parts to staying connected.
- Collaboration – Analysts, project managers, developers, testers, product managers, executives, stakeholders, and customers – is everyone on the same page about what you’re building and why? Keeping everyone connected is often easier said than done, but it’s absolutely critical to the success of your project. Depending on the size and location of your team, you can do this manually through meetings, phone calls, and documents or you can use a tool to help keep your team connected. It depends on your situation and the complexity of what you’re building.
- Traceability – the act of connecting up the requirements and other artifacts such as use cases, test cases, tasks, defects, and even user documentation – all the details that are related to each other within a project. For complex development projects, there can easily be hundreds or thousands of items involved and it’s critical to establish the traceability relationships between these items – both upstream and downstream. For example, when a high-level business requirement changes 30 days into a project, through trace relationships you can then immediately assess the impact it has on any downstream functional requirements, tasks, and defects that a developer or tester might be working on. This helps to minimize errors and costly rework because the team members affected are aware of the specific change and its impact.
Implementing traceability and a change control process that’s appropriate for your situation is one of the most important steps to ensuring success. As a simple first step to establishing change control, you can use a change request form manually to document changes right now. Click here for a change request template and other resources.
Tip #2 – Take Action Now
Don’t wait for your process to be “perfect”, doing something is better than nothing.
It’s easy to fall victim to what you might call “process perfects” – a condition reached by teams that get paralyzed by process and analysis versus delivering working software. How many times have you heard someone say, “Well, we’ll get to that project as soon as we really lock down our process? ” Is any process perfect? More importantly, should that really be the highest goal of your team?
Whether your team is practicing some flavor of Agile or not, there’s one thing we can all take away from the principles of Agile – it’s that working software is the primary measure of progress. Don’t get us wrong, optimizing your process is important, very important. We’re constantly tweaking our process. However, if you have a better process and no product, you still have nothing to show your customers.
Doing something is better than nothing. Start small, identify a few critical requirements and take the approach of continuous improvement where you build, reflect, refine and repeat. Then, with each release cycle, you’ll learn more about the needs of your customers and continuously improve and expand upon the software solution you deliver to them. If you think your team suffers from process perfects, look for these symptoms:
- The scope definition phase seems to drag on and on and on
- In the last month more time when spent talking about process, while your product stayed the same
- Lack of a decision-maker to make the call when to move forward with development
Tip #3 – Eliminate Ambiguity
Requirements management begins with writing good requirements. One of the things you can do immediately makes a “do not use” word list and post it up on the walls in your office. Visual reminders will help you to avoid using ambiguous terms when writing requirements. Here are a few ambiguous terms:
| fast | specify the minimum acceptable speed which the system performs some action |
| flexible | describe the ways in which the system must change in response to changing conditions or business needs |
| acceptable, adequate | define what constitutes acceptability and how the system can judge this |
| simple, easy | describe system characteristics that will achieve the customer’s needs and usability expectations. shouldn’t |
| shouldn’t | try to state requirements as positives, describing what the system will do, instead of what it won’t do |
| robust | define how the system is to handle exceptions and respond to unexpected operating conditions |
You can search on the internet for other ambiguous words
Tip #4 – Reconnect with Your Customers
You don’t have to be an expert to capture the voice of your customer – just committed.
This may sound obvious, but it’s easy to lose sight of customer needs as a project gets underway and the team gets to work building the solution. Keep in mind, we use the word “customers” to define the end-users of the product you’re building – these customers could be external consumers for commercial products or internal users in the case of internal IT systems where other departments and employees are your customers.
Capturing the voice of the customer isn’t a one-time effort. Most project teams do thorough requirements gathering session at the beginning of a project but rarely does the customer interaction carry through to the end. Successful requirements management practices include constant communication with customers. Otherwise, you risk falling into the classic trap of delivering a product that end-users reject because it doesn’t resonate with how they expect to use it.
There’s definitely an art to eliciting feedback and requirements from customers and clearly, some people are better at it than others. There’s a plethora of books and courses out there to provide training for this specific skill. However, you don’t need to be a requirements management expert to capture the voice of your customers. The fundamental skill required is commitment. Commit to picking up the phone every week and talking to customers. Commit to getting out of your office and sitting down with customers in their real environments. These are things everyone on the team can do and should do. Even in Agile, it’s not always possible to have an on-site customer present, so you have to commit to getting that feedback in other ways.
Here’s a quick list of Do’s and Don’ts to follow as reminders for how to stay connected to your customers.
| Be a journalist | Ask open-ended questions Think you know best what customers want |
| Talk to your customers every week | Assume past experience is representative of current needs |
| Be open and flexible to change | Assume customer needs are static |
| Just pick up the phone and call customers | Elicit requirements & feedback only at the start of a project |
| Listen with an open mind during elicitation | Sell customer on your idea for how a solution should work |
| Sit with a customer and watch how they work | Assume customers know how to articulate their exact needs |
| Close the loop with customers when their feedback has been implemented in the product | Forget to capture and share the evidence you gather with your team |
Tip #5 – Prioritize Objectively
Avoid building functionality customers don’t need and may never use.
Development time is so valuable. There’s nothing more frustrating for everyone than wasting time building features that customers don’t actually use and don’t provide value back to your company.
This is where requirements prioritization is essential. You need to avoid the common pitfalls of building features that seem cool or that someone thought a customer might need. Too often, requirements prioritization happens subjectively. The team holds a meeting and debates over the requirements and the loudest voice win, or a request comes in from a salesperson who just spoke to a customer and the most top of mind request now becomes the hottest priority du jour. With each new feature request or high-level requirement, ask these questions to determine if this is a must-have or a nice-to-have feature:
- What percentage of our customers will benefit from it?
- Does it fit our brand values and enhance competitive differentiator?
- What is the trade-off if we prioritize this ahead of other requirements?
It’s best to establish an objective prioritization model that quantifies the variables that matter most and that each high-level requirement gets evaluated against. That way, by getting agreement on the scoring model, it’s easier to get consensus on the highest priority requirements your team should focus on, objectively. Click here to get a feature prioritization matrix template.
Tip #6 – Minimize Overhead
Select the right tools to get the job done. If you’re a small team in the same office developing a fairly straight-forward product, then you can use a whiteboard, task cards and daily face-to-face meetings to manage requirements. A specialized tool, in this case, could create unnecessary overhead. Likewise, if your team is building a product where the requirements are all agreed upon upfront and won’t change much throughout the course of development, then documents and periodic status meetings may work just fine.
As projects grow in complexity and teams grow in size and geography, so do the communication challenges and overhead of trying to keep everyone and everything in sync. It’s in these scenarios, where a requirements management tool can add value because the overhead of using the tool is far less than the manual overhead it takes to keep track of changes, manage trace relationships, update documents and communicate constantly with everyone on the team.
Here’s a checklist of a few common tipping points where a specialized tool makes sense and can help reduce overhead by automating the process of keeping people and all the related information connected.
Complexity The more complex the project, the greater the need. If you have over 100 requirements. 72% of teams have projects that on average have 100+ requirements Team Size The bigger the team, the greater the need. If you have over 25 people involved Over 40% of teams have at least 25 members and stakeholders. If 10%+ are virtual. Location The more geographically distributed the team, the greater the need. Over 60% of teams have at least 10% of their team working in different locations. Change The more changes, the greater the need. If you spend 10% or more of your time managing changes to requirements Over two-thirds of teams spend 10% or more of their time managing change. Traceability If traceability is a priority for meeting standards or government regulation, a tool is valuable for automating the management of trace relationships, change control and version history
Tip #7 – Use a Scope Matrix as a repository of information
- Use cases
- Process Flows
- Client conversations and documentation
- Project visions
Leave a Reply