Defining the scope of your new technology procurement project, including what’s in spec and what’s not, is critical to transforming your technology dreams into a new organizational reality.
So far, we’ve looked at how to gather various stakeholders’ requirements for a new technology acquisition, and then how to distill those requirements into a budget, engaging stakeholders every step of the way.
At this point, it’s time to move out of the world of business requirements and into the world of market solutions, so that we can explore product scoping and specifications.
In this chapter, we cover:
- What a product specification should be
- How to take project requirements and a budget and distill them into a functional specifications list
- How to determine which features are necessary and which are just nice-to-have
- Common pitfalls of product scoping and specifications.
What is a product/solution specification?
At this point, you should be looking at your project through a table framework something like this:
Now, it’s time to look at how you distill those requirements into a specifications list.
A product specification, or product spec, is simply a list of the features that a solution should provide.
For instance, you might be considering the purchase of a new content management system. One of your business/technology requirements might be:
- Non-developers must be able to make changes to your organization’s website with no knowledge of HTML code
- The solution must be able to integrate with your existing business solutions, which have been built on a Microsoft platform.
Therefore, your product spec might be:
- Page layouts based on web-forms, with “what you see is what you get” (WYSIWYG) editors
- .NET-based system for integration flexibility.
In this example, identifying a market solution would be easy. But that won’t always be the case.
How to take project requirements and a budget and distill them into a functional specifications list
Let’s assume that you know the category of product you want to buy. For instance, you know that you’re looking for a CMS or a CRM, or a new ERP or DAM system.
So the first step you need to take is matching each of your business requirements with a technical function that is performed by a piece of software.
Basically, you’re going to follow the process you used to distill business requirements into a budget. Only this time, you’re distilling business requirements into technical functions.
There are two ways to approach this.
First, if you aren’t familiar with the technology you’re considering, or if you don’t have a technology partner, the best approach is to draw up a comprehensive list of all the functionality most software solutions offer, and then try to match specs with requirements as closely as you can.
For instance, if you’re considering a new CMS, your list of specifications might include:
- WYSIWYG code-free publishing
- Automatic content organization
- Storage limits and capabilities
- Multi-user access and user rights
- Underlying code base (e.g. WordPress, Joomla)
- Compatibility with your other software (e.g. if you’re using a DAM).
Of course, a list like this can quickly get out of hand, even for simple purchases. The staggering diversity of products/services available in the market means that your list could grow to include hundreds of different specifications, and the task of sifting through them, matching them with business requirements, and then prioritizing them will be time-consuming.
An alternative approach is reviewing your business requirements with an external consultant. This is often a more efficient way to identify technical requirements, for a number of reasons:
- Consultants understand the technology landscape because they spend much of their time talking to and evaluating solution providers.
- They have partners who can quickly provide them with detailed information about the solutions that are available.
- They have experience solving problems like yours. Most organizations are facing technology challenges that are not unique. A third-party consultant can help identify solutions that have performed well for organizations similar to yours.
Whichever approach you take, you should be looking at a table framework something like this:
Next up, prioritizing solutions to maximize results.
The difference between nice-to-have and need-to-have
The key to a well-managed and well-executed technology project isn’t having a superhero as a project manager.
It’s having a clearly defined project scope. And that should come into focus during the procurement process.
Many organizations encounter this challenge:
During the requirements gathering process, they consult all of their stakeholders and end up with a laundry list of functionality.
As they make their way through the budget planning process, project managers soon realize that not all business requirements are created equal. Some will have to be cut, so priorities need to be established.
The question then becomes: how do you distinguish between a nice-to-have feature and a need-to-have feature?
High/medium/low-priority format
The best approach is to rank your requirements as having either high, medium, or low priority.
But first, let’s define what these mean.
- High priority: the project requirements and the business objective cannot be achieved without including this functionality. It’s a must-have.
- Medium priority: it’s much more challenging for the project to achieve the business objective without this functionality. A medium-priority requirement will make the project outcome better, but it is not essential.
- Low priority: functionality that you would really like to have – but at the end of the day, you can probably live without. That would be a nice-to-have.
Now, we can go back to our objective/requirement/budget/tech spec table framework:
At this point, we want to look at the business requirements and business objectives our technical specifications are expected to meet, and determine priority based on that.
For instance, let’s say you’re looking at the technical specifications for this business objective: to close 20% more sales through the acquisition of new CRM technology.
First, identify the technical specifications that are connected to meeting the business requirement of processing sales data faster:
- Usable interfaces
- Customizable dashboards
- Integration with existing call/email software
- A place to take notes
- Automatic activity logging.
All of these features can help achieve faster sales data processing.
But it’s clear from this list that the business objective cannot be achieved without these two:
- Integration into existing call/email software
- Automatic activity logging.
So, in order to be considered, a CRM must provide these two features.
Why? Because no extrapolation is needed in order to understand how these two features will contribute to achieving the primary business objective.
Some of your stakeholders might want to include another kind of specific functionality (better interfaces, for example), and they might say:
“Better interfaces will help our sales team do their job faster! And even a 1% improvement in the experience will lead to faster interactions, which will drive more efficient data entry, which in turn will help grow our business!”
And that’s not wrong – it’s just not as right as the case for automatic activity logging.
Automatic activity logging directly contributes to achieving the business objective, making it a need-to-have feature.
That’s how you can make the distinction between a nice-to-have feature and a need-to-have feature: if more than one degree of extrapolation is needed to connect the requirement to the business objective, then it’s not a high-priority item.
Managing stakeholders: how consultants can help
Much of the work we’ve outlined to this point can be done internally. However, an external consultant can also help by setting out the technology requirements they think are appropriate, based on their experience and expertise.
A second (and often overlooked) benefit of using a third-party consultant is that they’re a neutral voice. Organizations can sometimes fall prey to their own internal politics, but an external consultant has no ulterior motives. As a result, if they say “you should consider doing this,” it carries more weight, because they’re not involved in any internal politicking.
And as unlikely as it might sound, a third-party consultant often has the strongest motivation to help make your project work, because their reputation will be on the line if it doesn’t.
Common specification pitfalls
As in any other stage of a complex procurement project, there are specification pitfalls you should be watching out for. Here are four you should try to avoid.
1. Scope creep
One way to keep your stakeholders happy is to simply blow out the budget and accept every one of their requirements as a need-to-have. The problem with this approach, in addition to blowing out the budget, is that it’s very unlikely you’ll see a carte blanche solution like this actually get off the ground.
The budget usually has the highest priority, and so decisions are often made in a hurry, without consultation – which can lead to a solution that isn’t fit for its purpose.
2. Seniority-led requirements
Stakeholder consultations usually cover a spectrum of the organization, from the senior executives who set business objectives to the end-users who are able to explain the problems and pain points they face.
It can be difficult for internal project managers to balance these different concerns appropriately. Status is not easy to ignore and more often than not, a CEO’s concerns carry more weight than those of a CSR.
Bringing in an external consultant is one effective way to get past these challenges. Because they bring an objective viewpoint (and because they can’t be fired so easily), a third party can help ensure that stakeholders’ concerns and requirements are given a ranking closely aligned with best practices.
3. Medium-priority and high-priority merge into one
Another challenge can arise when organizations try to rank the priority of technical requirements as high, medium or low. Often they end up with one or two that are high-priority, one or two that are low-priority, and 30 that are medium-priority – which makes the rankings almost meaningless.
An effective approach in a situation like this is to continue to rank within high, medium and low priority. So if you have 30 medium-priority requirements, restart your ranking process with those by applying the same extrapolation method to subdivide them into high, medium or low.
In the end, you’ll have a well-ordered list of priorities.
4. Failing to understand technology options
Some organizations begin the procurement process by saying something like, “we’re looking for a new CRM” or “we’re looking for a new CMS” – before they have even started compiling and analyzing their business objectives and business requirements.
Remember: the purpose of a project isn’t to acquire technology, it’s to solve business problems.
Long before you start considering technical specifications, you need to think carefully about your business objectives and requirements.
An external consultant with a deep understanding of the technology landscape can often serve as a key resource, because they can help you match your business problems with the most appropriate technology options available in the marketplace.
Chapter summary
- A product specification is a list of the features and technical requirements of a product that are necessary to meet business requirements and achieve an organization’s business objectives.
- Your project/business requirements should inform your technological requirements, and your tech spec should be directly connected to business objectives.
- Distinguishing between need-to-have features and nice-to-have features is essential. The extrapolation method can be useful here: the more extrapolation needed to connect a technical requirement to a business objective, the less important that technical requirement is.
- Two pitfalls to avoid when distinguishing between need-to-have and nice-to-have are: assessing everything as medium-priority; and giving more weight to the requests of senior executives than those of end-users, rather than assigning relative weight by applying the extrapolation method. The first pitfall can be avoided by reranking the priority of all medium-priority requirements as either high, medium or low. The second can be addressed by bringing in an external consultant who isn’t part of your organization’s internal hierarchy.
- Remember to put aside any preconceived notion of what your solution should be. For instance, “we need a CMS” is often a poor approach to starting a procurement project. A third-party consultant can help clarify your business objectives, and then match those objectives with the most appropriate technology options.