Problem Domain to Solution Domain: It's all about communication.
Why is a good understanding and clear communication of the business need so important?
Communication is the foundation for a formal agreement between a customer with a need (problem domain) and a developer with a solution (solution domain).
For better or worse, a shared understanding of the business need affects the development of fit-for-purpose solutions.
Customers are responsible for describing their need and developers are responsible for proposing a solution. Interaction between a customers and developer is inevitable and managing this relationship is crucial. The hand-off between a customer's problem domain and a developer's solution domain is so important that we rely on specifications to formally support the agreement between them. These specifications establish the contract between a customer and a developer. It seems straight forward, but this arrangement can get quite messy in practice.
"Problems" in the Problem Domain
The customer's enterprise often lacks the skill to sufficiently analyse and describe the need. The skill to do so may not form part of a customer's core competencies.
This can lead to the following issues:
The value of addressing the problem, or specific aspects of it, is not made explicit.
Who the stakeholders are remain unknown and, as such, the affect a solution may have on them cannot be taken into account.
"Pre-solutions" in the Solution Domain
Developers need to remain competitive in a dynamic marketplace. They need to be proactive; continuously looking for business opportunities. Most engineering firms push existing solutions to customers with dedicated marketing and sales teams, rather than waiting for a customer to request development of a new solution. If an existing solution can sufficiently address a customer's business need, the transaction is merely the transfer of existing technologies from a supplier to a customer with very little development, if any. Systems Engineering won't be necessary. However, customers would also like a competitive advantage, and this often translates into a need for novel capabilities.
This is where it gets messy
When combining a customer's limited skill to sufficiently describe the problem domain with a developer's offer of existing solutions, it can easily lead to a toxic mix of poor requirements and a pre-constrained solution.
The Role Systems Engineers can Play
It is common for a customer to select a development partner based on product offers and reputation. This, if anything, increases the danger of pre-constraining development with detail design descriptions of existing solutions. When an agreement between a customer and a developer unnecessarily specifies a particular design, the opportunity to understand the underlying need and the value associated with addressing that need is lost to both parties. There are two things systems engineers can do to prevent agreements pre-constraining solutions and to ensure the underlying need is well understood.
Describe existing solutions in terms of behaviour, instead of the physical implementation.
Apply requirements analysis techniques to determine the rationale for every customer and stakeholder requirement.
Form follows Function
Systems engineers can translate existing solutions and capabilities into logical descriptions for their marketing team's slicks and glossies. They have the behavioural modeling toolkit for it. Through marketing a functional capability, rather than a detail design, customers are more inclined to express their real need and identify additional areas of value by recommending changes to the proposed capability.When systems engineers can cost the development and delivery of functional capabilities, it becomes easier for customers to share the value they associate with respective capabilities. It also leaves the development team with more freedom to investigate alternative designs that may be more appropriate to the particular problem domain.The Operational Concept Description for an existing solution is well suited to initiate the marketing and sales conversation between a developer and a customer. Project Performance International offers an excellent - and free - Data Item Description for an Operational Concept Description.
Use Root Cause Analysis to Capture and Validate Requirement Rationales
Sakichi Toyoda developed a simple, but very effective, technique at the Toyota Motor Corporation. The 5-Why's is a question asking technique to explore the cause-and-effect relationships underlying a particular problem. Capturing a rationale for each customer requirement through upfront requirements analysis will allow the development team to make much more valuable design decisions and trade-offs later in development. This gives the developer a much better chance to come up with a fit-for-purpose solution that can give the customer a competitive advantage.
Marketing and Sales makes the Bottom Line
Great agreements empower customers to describe the problem domain and developers to develop appropriate solutions.Systems Engineers should support their marketing and sales team so that they can negotiate great agreements with customers. Systems Engineers can describe existing capabilities in functional terms and rely on requirements analysis techniques to better understand a customer's business need. For any successful development, both the customer and the developer need to fully understand the business need. It is the only way of developing a solution that can address the need and create value for everyone involved.