If you don’t have any product objectives, you’re not going to achieve them
As part of the project setup, the key stakeholders must agree on the objectives for the product or service to be created. Product objectives clarify the value to be gained from the project. This value statement should support, directly or indirectly, the organisation’s strategic objectives.
The business case for the project must clearly define the product goals and objectives. These should relate to the problem that will be solved by the product or service.
Project and product objectives
We can usefully separate product goals from project objectives. Project objectives identify the,
- Product to be created
- Constraints such as budget and timescale
Project and product objectives feature in the terms of reference for the project. Clear product objectives can help to minimise the scope of the project. Reducing the scope increases the chances of project success.
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. This is the point at which conflicts need to be identified. 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 then 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. It’s often stated that 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 may also be considered as ‘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