Define success measures at the start

Programmes need clear targets showing what a solution needs to do and what positive effects it has to provide. They also need boundaries within which it must operate. It is only fair to share the factors that will be used to judge success before people do the work.

If this aspect is poorly executed then the risk of going off track is high. Things go wrong. The problem is not recognised. The real targets and boundaries only become clear to he team when work is exposed to end users and found wanting.

Specification challenge

Unfortunately specification practice in this space is not well developed. Defining an envelope, rather than a solution, is something people find difficult. When it is attempted the definition can turn out to be superficial, having no real value as tool to influence the outcome, or it can start to be a solution specification, too restrictive and soon left behind as things move on.

Early exposure, the Agile way

There is a trend to early exposure of work in progress and incremental delivery as a way to reduce the risk, approaches heavily promoted in the Agile delivery community. These are excellent practices but they are not a panacea, they cannot solve all the problems. For example their contribution is spread across the duration of the programme and their focus governed by what is being built at that time. Discovery of critical factors can be delayed or completely missed if the route taken does not encounter them or the assessment approaches do not surface them. Agile choices also need to be guided, they cannot be relied on in a vacuum.

Programme outcome specification

Clear solution agnostic programme outcome specifications are invaluable. Being solution agnostic they are durable. They retain their value and effectiveness as the solution evolves and changes. They are a stable frame of reference within which work can be planned and executed.

Our concepts, approaches and experience can help an organisation recognise and capture the essence of what a programme must deliver to be successful. Find out more about our approach in this section on programme outcome specification.

Challenges

Technical teams can struggle to step away from the concrete things they know to express outcomes. Business teams often do not know that “the obvious” needs to be stated nor how to express the qualities they require. Operational issues are generally forgotten.

How we can help

We operate in the “what does it have to do” space and we can help tailor a specification approach to your needs. Whether for commercial tendering purpose or as a programme control we can help establish a much clearer definition of what is needed.

We can develop the scope and vision of your solution with you. Our experience at looking at solutions from multiple perspectives and as layered constructs, practice around process around technology, mean we can step into the shoes of different parties and express the vision in terms relevant to each group.

We can develop your understanding of and expression of quality criteria. On many occasions we have had to “reverse engineer” the quality criteria for solutions we have assessed, to establish a frame of reference for assessment. We can show the importance of explicit quality criteria and help you to establish and maintain them to provide a firm foundation for your work.

Our interest in requirements runs very deep. They are a fundamental frame of reference for assurance. The absence of high quality requirements has been a source of great pain. Many times we have had to go out an elicit the requirements ourselves. From this perspective we have learnt how truly high quality requirements need to work. We can help establish effective continuous high quality requirements practices that integrate with and bolster your chosen delivery lifecycle.

We lead and deliver a lot of non-functional assurance and to do this we have learnt to tease out real non-functional requirements by analysis. Rarely do we get anything useful in a non-functional requirement specification. We can apply this experience to help you provide this insight to you design and development teams, rather than waiting for your test team or end users to figure out what the true non-functional requirements are.