Throughout my schooling (two degrees in IT) and career, I’ve been taught both formally and through on-the-job coaching to always let the business problem drive the solution. Let the business strategy drive the budget. Never allow technology factors and constraints to interfere with requirements gathering. While this somewhat myopic vision can be a valuable exercise, it’s my opinion that these practices have a negative effect on Federal agencies that need to make effective use of tighter budgets.
Technology products and services have come a long way in offering compelling utility without drastic customization. At AIS, nearly all the solutions we build for our clients are based on building blocks provided by product or service companies. This approach drastically reduces the costs, risks, and time often associated to custom application development. You can find countless examples on our website of how AIS uses products (such as SharePoint and Dynamics CRM) to create custom applications for our clients. Our developers use the products’ robust web services and object models to reduce code complexity. Rather than developing custom implementations of commonly required features, we simply utilize the products’ existing capabilities and program our solution to call a series of actions to complete a business process.
Put succinctly, if we allow requirements elicitation to occur in a technology vacuum that does not take into account what the building blocks offer, the result is often overcomplicated and overpriced implementations.
By tailoring the wants and needs of the business to the available building blocks, we can simplify the implementation while still delivering the desired functionality. It’s well accepted in the IT industry that commercial-off-the-shelf (COTS) products and services reduce cost, complexity and risk. When building custom applications based on COTS building blocks, these efficiencies are realized without sacrificing custom solutions for your line of business needs. By introducing how these building blocks work and then tailoring the business requirements to simplify our implementation, we can often deliver more features in shorter time…and with a smaller budget. And if that isn’t enough, the resulting software is more maintainable and less prone to contract transition risk — particularly for Federal projects.
By tailoring the requirements, we can craft very unique, custom line of business applications that use rather mundane, common industry approaches in our code. This approach to our coding gives the government greater choice and flexibility in future contracting to maintain the application because the implementation is less specialized, is easier to explain in a future follow on RFP, and has a wider audience of companies and individuals who are capable of enhancing, maintaining and operating the solution.
Unfortunately, all too often in Federal contracting, the acquisition process includes a predefined set of system requirements that must be addressed as provided, without tailoring. Companies must respond as instructed to win the work, and cannot propose more innovative solutions that adjust the requirements to a proposed technology. Loading up a proposal with assumptions and proposed changes to detailed requirements provided by the government is not usually a winning formula. By allowing the technologists from the implementation team to be equal partners in the creation (or at least the tailoring) of the requirements, we can create faster, cheaper, more maintainable solutions that achieve the business objectives.
This problem is not just an acquisition process challenge for Federal agencies; it’s also a failing of our industry to adjust how we serve our clients. We need to be full partners who are capable of tailoring requirements to the productivity enhancing, building-block technology that vendors have provided.
With respect to “requirements,” I don’t simply mean the documented system requirements, but the deeper meaning behind each need…and why it exists in the greater context of the business objective. [pullquote]We must engross ourselves in our clients’ domain as if it were our own business.[/pullquote]To achieve this, we must be dedicated technologists who not only understand the tools and techniques we use to implement solutions, but we must engross ourselves in our clients’ domain as if it were our own business. In my experience, the IT team (both contractor and government alike) often understands remarkably little about the business needs outside of the system requirements. As full partners to our line of business colleagues, we must invest more time, energy and enthusiasm into learning the challenges of the business users of our systems.
By introducing the technology into the requirements planning phase of a project, well-rounded technologists can vastly improve the business requirements’ compatibility with the selected technology. The resulting solution will achieve the business objectives and goals while being less costly, less risky, and easier-to-maintain software. Federal IT budgets can do far more with the same (or even less) funding by bringing the technology and well-rounded technologists into the requirements process and breaking the “rules” and the classic approach of separating these concerns.
