Setting product objectives

In the business case for a project, the key stakeholders must agree the objectives for the product or service to be created, that is, they must define exactly what the new product or service wil do for the organisation that’s creating it.

From there it should be a short step to identifying the benefits that this product or service will bring to the oganisation.

Product objectives clarify the value to be gained from completing the project. This value statement should link, directly or indirectly, to the organisation’s strategic objectives, i.e. how will the product or service contribute to achieving the strategic objectives?

Project objectives

We can usefully separate product objectives from project objectives. Project objectives identify the,

• Product to be created
• Constraints such as budget and timescale

Product objectives clarify the reason for undertaking the project and the creation of a particular product or service.

Project and product objectives feature in the terms of reference for the project. Clear product objectives can help to minimise the project’s scope. Reducing the scope increases the chances of project success. The initially simple product or service can be enhanced iteratively over a period of time.

Stakeholders

In establishing product objectives at any level it is essential to get the viewpoints of key stakeholders. The skill of the facilitating business analyst or consultant is not only to obtain these individually but to obtain a consensus of opinion. This may well involve considerable negotiation skills on their part.

Discovering the objectives

We can establish the product objectives with interviews and facilitated workshops that involve the organisation’s executive and senior management. It is important to identify conflicts between the objectives of different stakeholders. A  team effort to achieve an agreed and consistent set of objectives will be repaid many times over. On the other hand, failure to agree on objectives at this level is a guaranteed way of having a troubled project. If the key stakeholders cannot agree on what is to be built, the project is in trouble.

Goal analysis – who does it?

Goal analysis is often a role for the more senior and experienced business analysts and architects. The analyst will draw out the viewpoints of the stakeholders, highlighting areas of agreement and discord. A skilled negotiator can help stakeholders to avoid backing themselves into corners from which they cannot extricate themselves without losing face. Although business analysts must identify conflicting requirements; the optimal time to deal with conflicts is right up front, with goals and objectives.

Goals and requirements

In his book, Requirements Styles and Techniques, Soren Lauesen refers to product goals as ‘goal level’ requirements. They justify the investment in the project. Some people might call them, ‘business’ requirements. For a single goal level requirement, there will typically be multiple,

• User requirements (Lauesen calls these, ‘domain level requirements’)
• Functional requirements (Lauesen calls these, ‘product level requirements’)

Testability of product objectives

Like other levels of requirements, goals must be written in such a way that they are testable, although typically the testing will not be possible until the products created by the project have been delivered to the business.

Never lose sight of the product objectives

We must ensure that the goals are kept permanently in view. It is important that all members of the project understand what the goals are. A change to the goals is likely to impact many aspects of work already undertaken