Goals are the first foundation stone of our methodology. For many years we have loosely practiced what we called 'Goal-driven Development'. What we decided to do was to formalize this practice into a solid foundation for this methodology.
For this practice we adopted the concept of 'SMART' Goals. Essentially, these can be defined as Goals that are (and definitions do differ):
These attributes are discussed in detail in the Methodology itself. Here we describe the use of these Goals.
Firstly, and most importantly, every Feature added to the specification must support one or more Goals. If it does not, the only options are to add a Goal that it does support (with the associated agreement by stakeholders), or to add it to the 'Wish List' of Features.
The main purpose of this exercise is to prevent scope creep. If any new features are requested after Design has started, each Feature must support a Goal. This is a very effective mechanism of forcing Business stakeholders to consider why they want Features, and how valuable they really are.
Given that most of these Goals will contain some financial metrics, it is also quite possible to assess the value of Features against the expected savings or gains once the Estimation phase is underway. This in itself allows a firm Business Case to be formulated or refined with quite accurate figures. It is far more effective to have specific and detailed calculations within a Business Case than loose or necessarily vague composite totals.
For this reason, we believe that the requirements gathering phase should ideally be undertaken prior to a Business Case being fully developed. We have seen several Business Cases fail approval merely because the suggested figures were both too generalized, and also not accurate enough. We had enough 'gut feel' experience to know that the figures would probably be approved if expanded, detailed and justified clearly.
One of the most important attributes of these Goals is that they are measurable. This is essential. The reason is not just that they can be measured, but because our methodology requires that the metrics are actually built in to the system right from the beginning.
This may at first seem onerous, or even wasteful. We do not think it is at all. In fact we believe that time is ultimately saved. If the metrics are built into the system right from the very start, this ensures several things:
* The Goals are definite and precise
* The measurement is never forgotten
* The Goals and metrics are (often) continually visible
* Time is saved when metrics need to be gathered
This in itself may not seem essential. We believe it is, however. This is because the Return On Investment (ROI) measurement is paramount to the continuation of any Process Improvement initiative.
All too often we have seen Business Process Management initiatives fail over time because they lose impetus. This can be described realistically as the momentum of the entire project. If each mini-project has a proven demonstrable Return On Investment, this can be used as an effective argument for continuing with the next phase, or starting new projects.