If you don’t have any goals, you’re not going to achieve them
As part of pre-programme or pre-project activity, it is vital to ensure that goals for the product or service to be created have been established. The business case or project charter should explain the need for the product or service, tying it back to the goals or objectives for the organisation; how will the product be of value to the business? The problem statement, providing a root cause analysis of the problem or opportunity for which the proposed product or service is a solution, is input to the business case preparation. The product goals will be reflected in the vision statement for the product and for the project.
Project and product goals
We can usefully separate product goals from project goals for the project that is to create that product; project goals may be formulated in terms of creating the desired product within certain constraints.
Project and product goals feature in the terms of reference for the project. Clear product goals can help to focus and minimise the scope for the project.
In establishing product goals 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 goals
We can establish the product goals with interviews and facilitated workshops involving the organisation’s executive and senior management. This is the point to identify conflicts. The effort to achieve an agreed and consistent set of goals is repaid many times over once the project or programme starts – a guaranteed way of having a troubled project, drifting and fire fighting, is to skimp on this work. If the key stakeholders cannot agree what is to be built, the project is in trouble. We can use techniques such as iterative prototyping to help people refine their understanding of what is needed, but at some point there must be agreement. Ian Alexander and Ljerka Dukic have done much interesting work in this area; see their book, ‘Discovering Requirements’.
If the organisation has a target operating model and / or an enterprise architecture, the impact of these need to be considered at this stage. We may also consider the impact of other views such as supply chains, value chains and customer journeys.
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. The skilled facilitator will help stakeholders avoid backing themselves into corners from which they cannot extricate themselves. We often read that we should identify conflicting requirements; the optimal time to deal with conflicts is right up front, with goals and objectives.
Goals and requirements
Product goals can be considered as high level requirements, In his book, Requirements Styles and Techniques, Soren Lauesen refers to these as ‘goal level’ requirements. They may also be considered as ‘business’ requirements. For a single goal level requirement there will typically be multiple user (what Lauesen calls domain level) and functional (what Lauesen calls product level) requirements.
Testability of goals
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 project has delivered and the product has become operational.
Never lose sight of the goals
We must ensure that the goals are kept in easy view as the more detailed requirements become clear through workshops and other means.
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