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.

The Praganalysis team (Joe da Silva, Phil Bailey and Adrian Reed) are pleased to are pleased to announce details of their new project – a completely free requirements management tool.

We’re conscious that we’ve been a little bit quiet recently, and we wanted to take this opportunity to provide you with some information on our current project. We’re extremely excited to announce that we will be releasing a completely free requirements management tool.

We’ve probably all worked on projects where the capturing, prioritising, tracing and managing of requirements becomes difficult.  With a plethora of Word, Excel and Visio diagrams, version control becomes difficult and there is a danger that different stakeholders may be referring to different versions of documents.  In addition, a traditional template based can make it difficult to capture all the necessary requirement attributes, and in particular creating sustainable links between requirements and artefacts can be difficult.

There are many commercial requirements management tools on the market, but all of these cost money.  We have set ourselves the challenge of creating a new tool designed for BAs by BAs.

More information will follow in the coming weeks and months, but our vision is to create a requirements management tool that:

• Methodology neutral: Whether you use Scrum, Waterfall, DSDM or Kanban, our vision is that the requirements tool will add value.
• Intuitive: The tool will be intuitive, and easy to use.  It will be supported by online help where necessary.
• One-button reports: A variety of reports will be available.  It will be possible to create a dashboard report at the touch of a button.
• Requirement capture: Requirements will be held in a database, along with requirement attributes such as source, owner, priority.  It will be possible to link to other artefacts (e.g. Visio diagrams) where necessary.
• Requirements groups: It will be possible to assign requirements to “groups”.  Perhaps you might want to sort requirements by release, iteration, or even by a functional split.  Requirements groups will allow you to do this, and will allow you to report on each group separately.
• Requirements Catalogue Report: It will be possible to export the requirements catalogue as a standalone file, so it can be circulated to stakeholders for review.
• Risks, Issues, Assumptions, Constraints, Dependencies: It will be possible to log and track issues and risks.
• Linkages: The tool will allow linkages to easily be created between items, so that impact of change can be assessed.

Most importantly, the tool will be completely free.  We’re incredibly excited about this project, and we hope you are too. 

Watch this space for more information!

It's been a while but, back with a bit of a bang, here are 3 new pieces of content.

Firstly, here's a written up version of the presentation I made to the European IIBA conference last month. As anyone who's seen me present knows, my slides on their own are next to useless so I thought I'd turn this into an article. This will also be published on ModernAnalyst.com shortly.

Secondly, here's something I've been working on for a while - namely a Business Analysis Maturity Model. Whilst there are other BA maturity models out there on the web I've never been satisfied with any of them as they seem a bit lightweight. This is an attempt to give a more comprehensive model to be used for departmental planning. Work out where you are, and where you want to be. I will blog more extensively on the use of this shortly.

Finally, here's a JPG version of the postcards I left lying around at the conference - they're intended to give an elevator-pitch style summary of the role of a Business Analyst.

All comments and suggestions on the above welcome - hope they prove useful.

P.S. keep watching, the whole pragnalysis team has lots more stuff coming soon. And good stuff too.

Things may have been a bit quiet on pragnalysis for a while but I can reassure you there has been lots of activity behind the scenes...

First up will be a new community section for people to contribute ideas as well as collaborate on specific content. The first example of this will be up and running very soon.

Secondly we have a very exciting project on the cards that Phil Bailey has been working very hard on over the past few weeks - this will be something that will benefit a lot of BAs and that we are likely to need some additional help with, so again, watch this space! Can't give any more details at this point but it will be worth the wait.

Next, I am currently working hard on my presentation for the IIBA conference in London on 27-29th September. The topic will be "Nobody knows your business like your own Business Analysts".

And finally, we are pencilling in a refresh of the site towards the end of the year so would really appreciate your feedback on what works, what doesn't work and what else you'd like to see on pragnalysis. Email us or add comments below!

Most BAs are very strong logical thinkers - which is probably why they end up as BAs. I tend to find that this logic tends to lend itself to a certain amount of detachment, and again this can be viewed as a strength of the BA; the ability to stand back from a situation and assess things logically rather than get distracted by an emotional response to events.

But do these characteristics sometimes hold us back? Are there situations where it would be better to get emotionally engaged with your stakeholders?
(Obviously I'm talking about a professional situation; it tends to be beneficial to get emotionally involved with your "stakeholders" outside of work...)

The preference that BAs tend to have for logical thinking means that we often want to "get down to business" when meeting with stakeholders; to us, this seems (of course) logical - we're at work, they're at work so we should get down to work. Right?

But what if the person you're meeting is someone who is more concerned with building a relationship or engaging on an emotional level before they get down to work? It's quite unlikely that you'll be meeting with a BA, so the chances of you meeting with a non-logical thinker is probably quite high. The attitude that we tend to take could make them uncomfortable.

I'm going to come back to this subject shortly once I've formed some more ideas but in the meantime, I'd be interested to hear the thoughts of some other BAs? Has anyone else come across problems because of their logical approach?