A key skill within business analysis is the ability to define and set goals and objectives. It might not always be referred to as “goal setting,” but every time you help the business determine the business value that would be achieved for a particular initiative, you’re really helping them to define goals and objectives. When defining acceptance criteria and non-functional requirements, you’re also setting quantifiable objectives that a solution should meet.
A common way of approaching business and project goal setting is to use the SMART technique. This technique encourages the setting of goals that are specific, measurable, achievable, realistic, and time-bounded. The SMART approach has many uses within projects and beyond. But is SMART enough?
I was recently fortunate to attend a useful and inspirational training course where I was introduced to a new technique (and acronym) for goal setting. This technique, designed for setting personal goals and objectives, is designed to be used in coaching. However, with some subtle adjustments, it works equally well in a project or business environment.
The acronym is PECSAW, which stands for:
Positive: What is it you want?
Evidence: How will you know whether it’s achieved?
Context: Where and when?
Self-achievable: Can it be achieved with the resources you have?
Advantages and Disadvantages: What does achieving the goal give you? What does it take away?
Worthwhile: Is it worth doing in the first place?
I highly recommend reading the original article about PECSAW to fully understand it. The model was developed by Pegasus NLP, a UK-based training company.
Although there are similarities to the SMART technique, there are a few significant and useful additions in PECSAW.
Advantages and Disadvantages: It’s easy for stakeholders to set ambitious goals or objectives for an organization or project, and as business analysts we can help them to define these objectives in a SMART way. However, it’s easy to forget that achieving one objective might restrict what the organization can do in other areas.
For example: “Achieving x% additional market share in xyz market” might have significant advantages but it might mean that the organization gets “pigeon holed” into that particular market. It’s better to consider this up front and check that it’s in line with the overarching strategy. Being a niche player is a great strategy, but it’s important to check that this is an intentional choice.
Worthwhile: Goals, objectives, and indeed requirements should all be aligned to deliver business and/or customer value. It’s easy to set objectives at a high or a granular low level that sound sensible but are actually dubious when you scratch beneath the surface.
An area where this can be particularly prevalent in the world of IT is in the definition of non-functional requirements. Stakeholders often have an understandable desire for 100 percent availability of systems. That’s an easy target to set using the SMART framework, but it’s likely to be an extremely expensive requirement to deliver.
In cases like this, it’s worth understanding whether it’s truly worthwhile. What additional benefits are delivered if 100 percent availability is achieved over 99.99999 percent? or 99 percent? Are there core hours where high availability is critical?
As business analysts, we instinctively ask these types of questions, but having a handy acronym to remind us is beneficial.
