Search This Blog

30 December 2012

Chess and the Art of Business Analysis Part 1

Over the last 12 months or so, I have spent a lot of my of time learning to do two new things. These are; learning to be a student again, for a doctoral thesis, and learning how to play chess (for fun).

I took up chess because I assumed  that playing a game, being quite a different thing to software development (my day job) and the rigours of academic research, might form an interesting distraction from the intensity of most of what I do.
Well it seems I was wrong, and I have come to realise that not only does playing chess use the same thinking skills I need to be a business analyst, it gives them a great work out.

The BABOK Guide (IIBA, 2009) identifies 6 knowledge areas in which the business analysts must demonstrate both understanding and the application of techniques.  These knowledge areas are supported by a number of underlying competencies. The game of chess has something to teach us in each of these knowledge areas and is also underpinned by exactly the same underlying competencies.  

This article will look at each of the knowledge areas in turn and attempt to demonstrate alignment between the skills you use as a business analyst and the skills you use to play chess.

Knowledge Area 2: Elicitation
Knowledge Area 3: Requirements Management and Communication
Knowledge Area 4: Enterprise Analysis
Knowledge Area 5: Requirements Analysis
Knowledge Area 6: Solution Validation and Assessment

Many comparisons can be drawn between the underlying competencies identified in the BABOK and those required for success in chess, but that’s another series of posts, yet to be written.

Knowledge area 1: Business Analysis Planning and Monitoring

This knowledge area teaches us about using our experience to apply foresight, especially to consider the different kinds of tasks and activities that need to be performed at different phases of a project. It’s about understanding what phase a project is in and communicating this to the team. Monitoring progress and knowing when the focus of your attention needs to change, whilst not losing sight of the bigger picture are key activities throughout the project.

Chess teaches us that every game has multiple phases and the objective of each phase is different. Being able to identify when a game has shifted from one phase to another is a critical skill. Missing the point at which your opponent moves from the opening phase to the mid game leaves you exposed and at risk of finding yourself engaged in an end game you weren't ready for.

Like the chess player, the business analyst needs select the right skill from their kit-bag at the right time, regardless of methodology; in the project planning phase this includes making sure you understand the domain in which you are working, what threats and opportunities are present in a given situation, as well as  identifying all the project stakeholders (in chess this is about understanding which pieces are really in play), In both cases these are not always the obvious ones (stakeholders who are not really on board, or who have different priorities). This is the time at which you will make an initial selection of the techniques which will allow you to assess and communicate the progress of your project.

In chess these skills are analogous to identifying your opponents skill level and any strategy they may be employing.  Next you must focus on developing your pieces towards the most powerful squares, setting up a strong defence and ensuring that the most valuable resources are going to be available to you before you need them.


20 December 2012

Agile Product Ownership in a Nutshell by Henrik Kniberg

This is a nice encapsulation of what we have been talking about to the local business analyst community. It's a very worthwhile video. I'd be keen to hear your thoughts on the ideas.

Hat tip to Chris Chan.

19 December 2012

The Science of persuasion

Yesterday Julian Sammy shared this video with his G+ network.

How to Persuade people? Here's the quick summary;
  • Reciprocity: Do things for other people before you ask them to do things for you
  • Scarcity: Scarce correlates to valuable. If it is always available and always free you are going to have a hard time charging for it. On the other hand, if it is only available to a select few, you encourage demand
  • Authority: Nobody comes to me and asks my opinion on fishing. Nobody.
  • Consistency: Creates a sense of reliability and encourages trust.
  • Liking: If you like me personally you are more willing to work with me for mutual gain. Are we similar in some way? Do we have shared interests? Do you feel valued and respected by me?
  • Consensus: The thing we are talking about has value for both of us.

14 December 2012

The frustrating thing about the label "business analyst"

Put your hand up if you want more fun at work!
For the last several years the business analyst role has been hyped as one of the most in demand roles in industry; the pathway to better It solutions, improved business processes and untold wealth. At the same time Linkedin has been telling me that interest in the role has been declining for t least the last 2 years.

At the same time I have had conversations with project managers, hiring managers and recruiters about what we are calling the 'two tier' business analyst market. At one level there are people who are capable at drawing flow charts and other diagrams, and can create lists of requirements, but are not particularly useful, and often decried and an imposition applied by 'head office' that need to be paid for at the expense of someone else who would make a better contribution to the team's goals.

At the other end of the spectrum there are these renaissance characters who are able to do the above, but also manage people through change, do a good job of product and project management, coach project and stakeholder team members, act as scrum masters, create and deliver training and just generally get stuff done.
Pete and Ed running a UX workshop for our local community
The later are often consultants and contractors that find the limits that hierarchical corporate cultures impose frustrating. They gravitate to projects where there is a sense of urgency and where the stakes are high enough for the organization to allow them to transcend the notional boundaries of the job description.

The term "business analyst" gives a pretty clear indication of the focus of the role; analysing businesses so that  people can better understand how they work and how they should be changing (often in the course of IT, product or process improvement projects.) This implies that the role is most valuable where people who operate the business today don't understand it sufficiently to plan for the future.

A fish and chop shop won't be needing a business analyst in the near future. At least not at the going rates.

But is this enough? And are there better ways to understand the business? Knowledge management, internal social media, organisational designers, more mature IT platforms and good old fashioned management are all conspiring to deliver better access to information, in competition to the BA.

Another consideration; Is understanding how the parts of the machine interact enough to plan for the future? We are in an age where transformational leaps need to be made frequently and sometimes with little certainty about whether they will work out.

Analysis is not enough. Synthesis is required. To synthesize knowledge and use it in a truly valuable way you need to work from values and principles and you need to be considering things like your mission and purpose. How often do things like this get addressed when analysts perform their role? Not frequently enough I expect.

We don't need to have a corporate mission to do this. You as a human being have values and principles which are probably already guiding the way you do work. You may or may not be aware of them but they are there. The same applies to your personal mission and sense of purpose. Take a moment to reflect on what is important to you and when you are comfortable with it start letting yourself be more confident in doing the work you do do in the way you think is most valuable for the people you care about.

When I started working as an analyst I used to describe my job as a 'customer advocate'  because I felt like my job was to go in and advocate the customer's needs and perspective when we were on business improvement projects. I am still doing the same thing, although I have expanded my view to include staff and community advocacy.

I wonder if Customer Advocate will ever catch on as a job description?

10 December 2012

An Estimating Story

Image from
Group estimates are often called out as a way of addressing individual biases in estimating.  If five people make an estimate the outliers can be removed and the three in the middle probably form a sufficient indication of the real size of the work.

But what if four of the team are naive optimists and one is a grizzled veteran? What if you are dealing with new technology that only one person on the team is familiar with? What if no-one on the team has ever dealt with this type of work before?

How will group estimates help you to find accuracy rather than drive you off track with wild guesses?

I worked with a lovely bunch of people for about 4 years ago (Hello Gosford!) and I got radically different results depending on how I went about gathering estimates. In the end I found the approach that gave me the best results was to use historical data and estimate based on evidence. I thought I might draw on this experience and share some reflections on software project estimating.

Here is what we did with some commentary;
Firstly, there was already an expectation about the project budget given its general attributes importance to the organisation. That put some boundaries on the project’s potential budget, which was probably useful.

Also, some initial business analysis work had been done and there was a view on how the architecture models surrounding the service should look. So again, there was some deep thinking and subject matter expertise on hand to support estimates.

We gathered a handful of people from the project team including the lead business analysts, architect, tech team leader a junior programmer and tester and went on a 2 day workshop where we broke the product concept down and then worked up a model for how to size the work. 

Part one of the estimating workshop involved creating a framework.  This was done iteratively as we investigated and estimated a couple of modules in detail. 

Factors we talked about looked remarkably like Function Point estimating, but it was a home grown tool that was based on number of inputs, number of internal processes and rules in the module and the outputs. This gave us a technical complexity score.

We then created a business complexity score based on the dynamism of the environment, the number of stakeholders and aspects of stakeholder alignment and organisational maturity. We then multiplied the two models to come up with an overall complexity score.

Once we broke down the target solution into modules we also had our first couple of examples estimated into elapse weeks for ‘N developers.” We had also notionally discussed the Dev-Test-BA ratios and had planned the team into rough cells. These could now be reference models for the rest of the solution modules.

For the rest of the estimating workshop we simply rated each module against the criteria, which was quick and easy to do, and then we just called the module based on its relative size to the initial examples.

That got is a budget, a team size and a schedule.  It was also about 2 weeks short of what the actual project took!

And the estimates for the individual modules looked nothing like the actual performance.
Once we had a budget and a team we began work and then created an agile backlog and then began estimating the releases and stories. The team all participated in estimating using Planning Poker.

What we found was that different people had different estimating capabilities, and often they were about perspective. 

4 December 2012

Where do good ideas come from?

In the 1990s I was studying where creativity comes from. As far as I can tell not much has changed in the area. It's the introduction of different ideas to each other to generate new insights. This video does a nice explanation of the idea.

The question for you and me, people in the business of designing business; how do we build this into the systems we design and influence?

Holy Quests

I discovered a new website (Limebridge) full of business comics. Here is an example that tickled me. There is a whole page of them so click on through and have a look.  My favourite is the 'Holy Quest.'

Correlation v Causation

2 December 2012

Over a million page views at Better Projects

Somewhere in the last few days this blog passed the million page views milestone!

Well done us, eh?  Thanks to everyone who has helped along the way.

Four Quadrant Models: Comparing and Contrasting

I joke that you aren't a real consultant until you have made up your own four quad model but in reality we are probably all doing this all the time.

Four quadrant models are used by consultants and change agents because they provide a visual way to introduce new ways of thinking.

For example; people might be very focused on cost so you can leverage that by making it the X. You as the change agent might want people to think more about value, so you can introduce it as the Y axis.

Now you have a way to connect your ideas around value to people's ideas on cost. Perhaps this added dimension can help bridge the two mindsets.

Another thing to be aware of is the notion that creativity is essentially the introduction of existing ideas in a way that generates new insights.  The X-Y grid provides an easy to access tool to generate creative new ways of looking at the world.

I'll throw a random example at you;

When you look at these two axes you get a opportunity to compare and contrast two different ideas, and hopefully generate some new ways of thinking.  I'll admit my example isn't that innovative, but I hope you see what I mean.

We might start with some assumptions that disciplined application of modelling processes makes for good value contribution.  We might start thinking about collecting data points or units of measure, and that might lead us to question other ideas or assumptions.  We might ask ourselves whether we have the right axes in the first place.

Which leads me to another point; when you get presented with a model by someone else; academic, consultant or just someone you work with you should challenge the underlying assumptions.

For example, in the BA model above we could ask whether there is any relationship between disciplined processes and value. Or we could argue that the relationship is so well proved that we shouldn't waste our time on thinking about it. (I personally have no idea about whether this is true, and think it's worth exploring.)

So, do yourself a favour and try creating some compare and contrast models and see what you come up with.  

And while you are exercising your mid try deconstructing a few famous ones as well to see if they make sense or are valuable for you.  Here are some examples;