Welcome to our new ‘Ask An Engineer’ series, where Dan Slaski addresses questions that have you losing sleep or staring off into space during important meetings. Have a question for Dan? Send it in.
Question: My company doesn’t create product requirements I feel they are necessary to do my job effectively. What can I do?
Dear Metrics Minded,
Start by making a business case. Point management to books or articles that articulate how requirements are critical to project success and highlight how creating them is in their best self-serving interest. Advise that research shows better requirements lead to better on-time delivery and higher quality products that are more successful over time.
“So, tell me what you want, what you really, really want!”
Point out how in no other aspect of life would one consider making big decisions without a plan. For example, if you need a vehicle and you get a Harley motorcycle, that may be fine. However, if the real need is to take your four kids to soccer, you are going to be doing a lot of walking. If you live in Sedona, Arizona with the means for a small starter house and get a houseboat instead, you must have met Steve, the best salesperson ever.
After all of your logic and reason-based attempts fail, if you like, you can try kicking and screaming and throwing a temper tantrum.
Some organizations just won’t generate requirements. Even worse, they are still more than happy to put hard deadlines on your nebulous objectives. That’s probably not the answer you wanted. Sorry, you may have better luck with a more conventional company or by becoming an alpaca herder. It’s up to you.
Why organizations can be so hesitant to write down requirements remains a mystery. I have heard a variety of excuses on the general theme of not having the time, need, or resources to do it. I suspect there is a fear that when requirements are written down they are carved in stone, and the future predetermined, right or wrong. Like looking into a crystal ball and seeing a dark fate. Doom, doom, DOOM!
Perhaps some critical requirement was missed or overlooked, or misinterpreted information led to incorrect requirements. While this is possible, it is way, Way, WAY more likely to happen without any requirements in place.
There must be a disciplined adherence to the requirements for them to serve their purpose. However, periodic reevaluation based on new and changing information that results in logic-based changes is fine. What is important is that the requirements are real, meaning properly derived from accurate information.
To us, it often appears that requirements are created and changed, and I say this in all seriousness, willy-nilly. Requirements can adapt and still meet their goal of serving as a unified plan and finish line.
“You can’t always get what you want, but if you try sometimes, you might find you get what you need.”
The reality is that since requirements are so important and nobody else will formally document them, that leaves it up to you. You likely already feel like an army of one, and this completes the circle of you doing everything. I’m sorry bub.
Designers, by nature, tend to think and act a bit differently than the norm, so if we are designing for ourselves we are likely not designing for the intended audience. And, somewhat paradoxically, as we continue to zoom in further and further on the details of a project we may lose perspective or distort the actual problem that we are trying to solve.
As the joke goes, “The engineer says if it ain’t broke, it doesn’t have enough features yet.” It is likely someone’s role within the organization to research market drivers, customer needs, and competitive comparisons. In the absence of that, I don’t recommend you take on this burden more than doing some cursory internet research.
What the designer possesses is the most knowledge about the technological drivers. These drivers can be the primary influencers for driving requirements like cost, size, and performance.
Most technologies have a current sweet spot where returns diminish rapidly. Based on your understanding of your industry, estimate these sweet spots and then form a picture of what the all-encompassing design looks like. Backfill the requirements and take some WAGs.
To be clear, this is the bass-akwards way of doing it, but it is still something and it is based on a legitimate viewpoint. Then call a meeting and share your conclusions. If you are way off, it will still hopefully start a dialogue or raise a flag. Plant the seed that maybe, Maybe, MAYBE might start an organizational shift where requirements become valued and implemented from the top down.
To be honest, I’m stumped. I wish there was a better way. Management, if you are reading this, please hear our plea.
An open letter within a letter:
Dear Esteemed Product Managers,
We want requirements, so we know how to focus our efforts. We realize there are limited resources and want to utilize them to their maximum potential. We view requirements as the minimum, and once we trust the rationale behind them, we will go way above and beyond to exceed them. It is frustrating to invest significant time and effort in a project only to discover it has no external value. Particularly, when we can clearly see that all the necessary information was available, and with foresight, could have been reasonably compiled to create a smarter path. If you can put your trust in the system and provide the required inputs, then we promise to deliver the goods.
Sincerely,
Dedicated Designers Everywhere
“You want it, you got it. You want it, baby you got it.”
Now bust a move!
