I’m pleased to say that my most recent blog article has been published on “Bridging-the-gap.com”, where I have contributed as a guest author. I’d love to hear what you think, so please feel free to make a comment on the site, or contact me directly. Here is an excerpt and link:
“Working with stakeholders to prioritise requirements is an important part of the BA role. Often, prioritisation can be a difficult exercise, with stakeholders asserting that every single requirement is a ‘must have’.
When this happens, it can be a sign that insufficient attention has been paid to the project foundations.
Prioritisation should be based on a measure of relative business value, and therefore it’s essential that there is a shared understanding of what the project is aiming to achieve before the requirements are captured and prioritised……..”
Read the rest of the article by clicking the link below:
Asking the right questions and framing problems carefully is an important part of project definition and organisational change. Often organisations frame problems in a way which constricts or constrains potential solutions, and this can lead to a poor outcome or the wrong tactics being employed. Spending time consciously defining a problem can pay dividends in the long run and can increase the likelihood of successful change.
Take a theoretical example: Many companies conduct staff engagement or satisfaction surveys. These surveys are designed to measure how engaged, satisfied or motivated their employees are. If an organisation has “bad” results on its staff survey, leaders and managers are likely to want corrective action to be taken. After all, nobody wants unmotivated employees.
The first step to addressing the issue is to define and frame the problem. Often this framing process happens unconsciously, but it is significant as it impacts the way that people interpret and respond to it.
The two questions below are ways of framing the problem described above. These two questions look similar on the surface, but they are actually incredibly different:
1. “How can we improve the staff survey results?”
2. “How can we make this a great place to work?”
In my experience, organisations ask question 1, which focuses on the symptoms. In the staff survey example above this might involve identifying key themes, and perhaps corporate communication is one of them. The organisation responds by starting newsletters, having “open door management” policies, but the culture doesn’t really change. The executive team look at the metrics “How can we move from 10% on the satisfaction scale to 15%?”. They apply palliative measures, and the root cause is never even investigated, let alone resolved. The objective becomes about improving the figures not improving the organisation.
Organisations really need to ask question 2. They need to investigate the systemic cause of the issue – accepting that the symptoms might only be the tip of the iceberg. This might require a change in the organisational culture and will certainly require observing the organisation as a complete system. Question 2 opens a can of worms. It requires stepping back from the metrics, and that’s an uncomfortable thing to do.
This is just one (albeit complex) example. Problems are defined and framed every day in organisations – perhaps in an operational context, or perhaps in a project context. Thoughtful and robust problem definition and framing change the way people think about the problem, and open up new solutions. As Business Analysts, we should encourage and facilitate this kind of thinking – asking challenging questions can be incredibly valuable!
How do you go about defining and framing problems? I’d love to hear from you- please feel free to contact me directly or add a comment to this post.
This article was originally published by Adrian Reed on the TAP University Blog, a site which provides instantly usable and helpful information for business analysis, project management and lean – six sigma practitioners. It has also appeared on Pragnalysis.com, a site dedicated to Business Analysis in the real world, and more importantly, home to an entirely free requirements toolkit.