As a Capture or Proposal Manager for a government contract bid, eventually someone will call for a technical “solution architecture.”
Unfortunately, most do not know what one is, what it looks like, or the difference between a good one and a bad one. There is no commonly accepted definition or measure of merit for what constitutes a technical solution. Moreover, even experienced writers fail to realize that, for most proposals, there is usually not a (single) solution architecture, but many.
What is a technical solution? Simply stated: it is your answer to one or more of your customer’s pressing needs or significant challenges.
There are many ways to approach your solution. Here is one, proven to work.
Describe the Technical Challenge(s). What is the problem in need of a solution? How do we demonstrate that we “get it”? What are the risks? What are the consequences of failure to fix the problem? Demonstrate we understand the scope and complexity of the problem. Describe the “as-is” state, and why it is not optimal or could be improved.
List Your Assumptions. What, if any, prudent, reasonable, necessary or desirable assumptions must be made to bound or support our plan below?
Describe Your Plan or Solution. How do we solve the technical challenge(s)?
Provide the a) who (organization or key personnel, responsibilities and authorities, labor categories and skill mix); b) what (system, technology, process, procedure, policy, steps, activities); c) when (timeframe, schedule, milestones, dates or phases); d) where (location(s) where the work will be performed); e) why (rationale for why our solution will work; and f) how (methods to measure our solution’s effectiveness—metrics, performance measures, success criteria, and relevant benchmarks).
Identify potential risks of our plan…and eliminate or mitigate them.
Provide Your Experience. What is our relevant experience and past performance that demonstrates the credibility and effectiveness of our approach? Where has our solution, (or something closely akin to it) , been successful before?
Customer Benefits. How will our customer benefit from our understanding, plan, and relevant experience? Be specific. Think improved safety, enhanced quality, improved performance, reduced costs, accelerated schedule, fewer risks, and increased customer or stakeholder satisfaction.
Vision for the End State. Assume our solution was successfully implemented. What is the end state (or “to be” state)? What would it look like? Describe how activities would be carried out safer, better, faster, and cheaper.
Graphics. Include supporting graphics such as: process flows, charts, milestone schedules, matrices, risk registers, schematics, pictures, customer testimonials, snapshots of awards or commendations, feature/benefit charts, organizational charts, or related visuals.
The key is to demystify the technical solution. Divide it into manageable parts. Always remember that the technical solution must solve a real problem (or don’t bother). Your customer will respect you for it.
