One of the biggest challenges of software development is aligning technical details with an organization’s business requirements. This is an essential concern if you want to put ideas, applications, and processes into the real world successfully — whether they are virtual in software or physical in hardware. Until we’re able to bend the laws of physics, conjure infinite computational power, or rewrite applications on the fly to do our bidding, technology will pose certain limitations that prevent lightning-fast innovation. Navigating these limits using real business requirements as a guide post is the key to successful outcomes.
If you’ve been involved in any kind of software project management, then you’re more than likely familiar with the infamous tire swing cartoon — which is actually an older analogy relating to general project management, but has since been adapted to all kinds of disciplines from customer service to manufacturing to software. For reference, here is the software version I’m talking about:
(Source: ProjectCartoon.com)
We’ve all had those moments with customers, analysts, and co-workers. You unveil a product feature you’ve been working on for months, and a look of horror starts to spread across their faces. Something has gone drastically wrong. You failed to ensure that your product feature — which is beautiful, by the way — addresses business objectives. This is like a tire swing without a tire attached, or perhaps strung to the tree in an unswingable way. You’re headed for missed deadlines, duplicated efforts, dead-on-arrival deliveries, and unhappy customers who will be deprived of the joys of swinging on a tire. Let’s look at some ideas for how we can avoid this unfortunate disconnect.
Ask yourself: Is it feasible and functional?
The first thing to do is define each business requirement on paper, and make sure that everyone involved in meeting this goal can answer the question “Is it feasible?” Sometimes decision makers want a tire that can swing through the tree, or swing in a direction perpendicular to the direction of gravity, and that’s a clear sign that they need to be re-evaluate their objectives for feasibility. Altering the laws of physics is a tall order for (most) engineers, so requests for impossible situations must be identified and addressed.
In the software world, an impossible requirement may involve pushing the boundaries of computing power or storage. Let’s say that an organization relies heavily on image processing as its core business. If a business requirement is to have an application crunch through an absurdly large number of images in an absurdly large resolution in an absurdly tiny fraction of time, this will simply not be feasible — not yet, anyway.
The second question organizations need to ask is “Is it functional?” Put together a functional requirements document that translates the business requirements into functional requirements. However, this is just a start — remember that even impeccably and explicitly well-written functional requirements can still ruin the spirit of the customer’s request (or need).
For instance, a tire attached to the trunk of a tree could technically still be a swing if you were to uproot the tree and mount it sideways, right? Or attaching the tire to two limbs on either side of the trunk so that it can only swing through the trunk is still a swing — just not a functional swing.
Break it down and make a plan
Now break down the business requirements into a real plan that your engineers can execute on. The process will vary across different products and technologies, but break the requirements down into their component parts and create a timeline of deliverables to plan and schedule the work.
Start by asking some fundamental questions. If we want a tire to swing, it will need to swing from something — what will that be? Will that structure need to be built from scratch, or can we use something that already exists — a tree perhaps? How will we attach the tire to the tree? Should the swinging be initiated manually, or completely automated? Embracing agile is one of the best ways to get the Minimum Viable Product (MVP) in front of the customer as soon as possible, and get feedback in flight. If you take great care to break the requirements down, Waterfall is also a good option, though be aware it can involve a lot of back-and-forth conversation, diagrams, and meetings.
Then, it’s finally off to the races! Create a plan and schedule the work to be done, with a detailed timeline estimating how long each step will take. Be sure to account for the realistic constraints that will affect you — e.g., can you build your tire swing in the middle of winter in Milwaukee? Sometimes the priorities or plans of others will also have an impact, like if your security group is working on a project or your infrastructure team has major changes coming.
Herding the cats of business requirements, technical details, and functional requirements is no easy feat, but proper consideration of feasibility and functionality can help as a first pass. Getting a good understanding of the requirements, breaking things down into manageable parts, and have a game plan can help ensure success.
