|Español - Italiano|
Solutions development determines the best way of satisfying the requirements for an output. Its goals are to:
- evaluate baseline requirements and alternative solutions to achieve them;
- select the optimum solution;
- create a specification for the solution.
Requirements management produces a clear set of stakeholder requirements but does not explain how to meet those requirements. Solutions development investigates the technical options for meeting the requirements and will work in conjunction with investment appraisal that investigates the financial implications of the different options.
Just like any other function, solutions development needs to be planned and initiated. Since the solutions development steps follow on naturally from those in the requirements management procedure, it would be unusual for it to have separate planning and initiation steps. However, some contractual circumstances may make requirements management and solutions development the responsibility of different organisations, in which case the procedures would be separate.
Evaluation looks at alternative approaches and assesses how well they will perform against stated criteria, such as capital cost, speed of delivery and degree of risk. The techniques involved range from simple make or buy considerations to the full blown modelling and simulation of innovative solutions. A value management approach can be used to help select the best value options.
Verification of products is part of quality control and configuration management. Validation is similar to the continuing confirmation that the objectives remain justifiable as defined by the business case.
As one solution emerges from the evaluation and is selected as the optimum solution it will be developed into a specification. In some cases the detailed elements of the specification will only cover the early stages of development, with later stages being refined as the work proceeds. The development of value-improving proposals can occur at any stage of the delivery process.
The solution should be regularly checked against the requirements (which may themselves be subject to change). This takes two forms. ‘Verification’ is the term used to ensure that the solution is being built right; ‘validation’ is the term used to ensure that the right product is being built. Verification is against specifications; validation is against requirements.
Projects, programmes and portfolios
The great majority of projects are designed to deliver an output and no more. Where the requirements are relatively simple, and use tried and tested technology, the type of solution will be implicitly understood by the stakeholders and management team, e.g. my requirement is to keep my car dry and off the road – the solution is to build a garage.
Solutions development then simply becomes the production of a specification without the preceding consideration of options such as rent a garage or sell the car and travel by bus. The project manager will need to judge the degree to which stakeholder assumptions should be challenged and more radical solutions suggested.
Traditional projects describe the output in a specification. This is contained within the definition documentation and submitted for approval at the end of the definition process. The specification may be supported by additional information such as a product or work breakdown structure.
Agile methods place much less emphasis on the detailed specification of a solution early in the life cycle. Instead, they focus on prioritised functions that are delivered incrementally in a series of time boxes or sprints. The detail of the output evolves during the iterations and addresses the typical problem of IT projects where it is difficult for a stakeholder to accept components of the system until they actually see it in action.
The equivalent of the specification for a programme of business change is the blueprint. This describes the cumulative effect of change on the organisation. It is a picture of all the outcomes created by the programme.
Each project within the programme is aimed at delivering an output that contributes to the blueprint. In most cases the degree of detail in the blueprint will leave ample space for project management teams to consider alternative solutions for the required outputs. However, the programme management team must co-ordinate project solutions and review proposals. There will be elements such as common components and technology platforms that are transferable between projects and the compatibility of solutions proposed by different projects should be checked.
Solutions development is predominantly a project and programme matter but the portfolio management team may set guidelines about innovation and risk that constrain the types of solution considered.