The other day I witnessed a major misstep when a vendor serving my own employer recommended a solution to us which was incompatible with one of our key business constraints. Fortunately we caught the problem, and the proposal was scraped.
But not everyone is so lucky. Insane sums are spent on rework for systems which were built with bad or missing information. As someone who builds and implements these systems myself, I can’t say that there is a foolproof method for uncovering every constraint, assumption, requirement, and interface which might affect the solution I propose.
But I can say that there is a process of due diligence which must be systematically followed to try and fully understand the target business. I decided to sketch a brief list of things which the project manager, business analyst, and technical lead should look at when building and implementing a solution:
- Corporate objectives. The suits might be leery of sharing the three or five year plan with a vendor team, but the more information you can get about the organization’s strengths, weaknesses, opportunities and threats — the better! Is the organization growing, innovating, changing, and/or trying to cut costs? If so, how are they accomplishing these things?
- Competitors. Who competes with this organization? What does market share look like and how have these competitors designed their systems? How can they be outdone?
- The Industry. Checkout the trade journals, attend a conference, and join any industry organizations. You need to become a kind of insider who can help lead the customer to a solution which they never even considered.
- Org Charts 2.0. You need to take the plain old org chart and dress it up with some key details for each department or entity: mission, function, and current initiatives.
- Infrastructure Charts. How do the existing systems communicate with each other?
- Location Models. Geographically, where does everything sit? And what laws, cultures, and locale-specific variables change from one location to the next?
- Business Events. What events drive the business? Do they come from customers, partners, suppliers, regulators? Who springs into action when these things occur? Do they occur on a regular schedule?
- Process Models. Workflows and interactions.
While so many customers (and providers) want to dive directly into the requirements gathering phase, there are huge benefits to first researching these domains. It can mean the difference between a well conceived proposal and an expensive disaster. But more than that, it can lay the foundation for a customer-provider relationship which goes beyond this project.
Imagine if you (as a provider) noticed a trend in your customer’s industry which led you to design a solution for a problem which your customer didn’t even realize they had!
