A common criticism of IT people is their over-focus on technology. Typically, this is coupled with an under-focus on user needs and long-term business goals.
This can mean that the IT team is focusing on solving problems that are not a priority for the user and or C-suite.
How do we effectively translate or quantify the handful of business goals of the user into the hundreds of requirements given to a programmer?
Fulfilling each requirement
Fulfilling each requirement requires an investment of time and effort on the part of the programmer. Some matter more than others; some require more (or less) precision. How do we guide programmers, project after project, to best invest their time?
As an example, a programmer may be working on a report that requires aggregated values. Now the question becomes, how often should these values be aggregated? And how much precision is required? Typically, these questions aren’t specified in the requirements, so the coder makes a guess.
Identifying and interviewing the stakeholders
Identifying and interviewing stakeholders is a critical first step. It’s also a messy business. Stakeholders are numerous and there needs are varied:
- One might be a line operator, monitoring the extruder, who requires an improved HMI / human machine interface [e.g. to be able to see all process information on the same page].
- Another might be a process engineer, trying to optimize a certain process [we need to better control yield in order to reduce scrap].
- A third might be a business manager trying to attain defined business objectives [Resins are expensive. Therefore, reducing resin consumption offers an excellent pay-off.]
How do we create requirements that meet all of these goals?
Turning needs into requirements
The first challenge in aligning requirements with goals is that user goals can be very high-level:
- I want to reduce my invested time on Process XYZ by 10%
- Manager wants waste on Process QPR to be reduced by 30%
For the line operator, the requirements might be:
- Ability to visualize data in less than 15 sec
- Ability to visualize data by hour, shift, production day, week, month, year etc.
For the process engineer, the requirements might be:
- Aggregate over flowrate [lbs/min] with accuracy -+0.5%
And for the business manager:
- 3 – 4 % resin savings
- Improve forecast and reduce material on stock by 10%
For project success, it’s critical to have a complete list of all requirements, each one linked to a business goal. It’s more important to be able to answer yes to the question “Have we got them all?” than “Have we got them right?”
Making quantified choices
To make smart choices, you have to quantify your goals and the resources it takes to achieve them. Say you have achieved a requirement, but not with the precision in the original specs. How much time and effort (if any) is it worth to achieve that extra precision?
If you can quantify the requirement, and relate it directly to the goal, you have a better idea as to whether to invest further time and effort.
Who does the quantifying?
Ideally, the person responsible for laying out the requirements in a given project should be a bridging type – someone who knows the business but also understands also how to write software. That way, they know what demands they are placing on the programmer in the requirements they write.
Typically though, there’s a language barrier here. The individual writing the requirements doesn’t know how difficult the demands they are making are. They may, and often do, ask for a requirement and specify a level of precision on a requirement that is extremely difficult IT-wise, and not overly important business-wise.
Quantifying the goals
The more requirements are linked to goals, throughout the project, the easier it is to focus resources on the goals that count. In the automotive sector, I’ve worked with clients who start with defining five customer goals, and relate all progress throughout the project to these five goals.
Everything moves better if the developer knows how important a requirement is, if it’s been quantified in terms of its importance to a particular goal. This way, requirements become less like barked commands, and more like steps towards an overall goal, steps that demand the IT person use their judgment to fulfill.
- If a difficult requirement doesn’t appear to be worth the extra effort, the developer will question the time invested and turn to a supervisor, or the team as a whole, to revisit the issue.
- Throughout, we know what percentage we have achieved of the overall business goal.
In every project, you’ll encounter obstacles that have the power to send the team in the wrong direction. This means measuring requirements against goals needs to be a repeated behavior throughout, to ensure your IT activities are proportional to project goals.
Customer goals and IT requirements are expressed in two different languages. The possibilities for wasted effort are high.
Begin mapping goals to each requirement, and your opportunity to use resources appropriately and achieve project success will skyrocket.