Cultural Differences Matter to Project Stakeholders

I’m pleased to say that one of my recent blog articles has been published on “”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.

An excerpt from the article is shown below:



Man in red with green tie looking confusedIn his recent Harvard Business Review blog post, Peter Bregman describes a scenario where a hopeful employee missed out on a promotion in part because he didn’t say thank you. I can only begin to imagine the employee’s disappointment over what appears to have been such a trivial oversight.

This example highlights the importance of having an appreciation for the corporate culture and the national culture of the organization and the stakeholders with which you are working. This appreciation of culture—including national culture—is of paramount importance on projects too.

Many projects today span organizations, countries, and time zones. Business analysts and project team members will be interacting with multiple stakeholders, potentially distributed all over the globe.

The reality—and this certainly won’t come as a surprise—is that different cultures aredifferent. They have different values, norms, rituals, and expectations. This complex stakeholder landscape raises the risk of inadvertent misunderstandings, conflict, and culture clash.

When working with stakeholders to understand their needs and requirements, it’s essential to build rapport—and this requires empathy and understanding of differences in cultures.

One of the challenges is that while it’s easy to observe the culture of others, it’s often difficult to look introspectively and observe our own culture…


Click on the link below to read more:


Dealing with big numbers

A few months ago, I had the opportunity to travel to Minsk in Belarus to speak at a conference.  I had never been to Minsk before, and I have to say I thoroughly enjoyed it there.  The city was beautiful, and I was fortunate enough to have time to explore the sights as well as attending the conference.


Man in red looking confused with curved arrows and a question markOne thing I found rather confusing as a visitor was the currency.  At the time of writing this article, the exchange rate between the UK Pound and the Belarusian Ruble is 1 to 13,075.  Or put another way, £1 is worth over 13,000 Belarusian Rubles.  As you can imagine, this led to me doing some mental arithmetic every time I went to buy something and it meant that the banknotes were issued in very large denominations!  And with so many significant digits (zeros), it would be easy for a visitor like me to make a simple error – after all, prices like 135,450.00 and 13,545.00 start to look similar if you stare at them for long enough.


Reflecting on this experience reminded me about how it’s often difficult to contextualise large numbers generally.  In this example, I dealt with that challenge by converting the large numbers to something that I understood (£s).  In business, we deal with large numbers all the time.  But do we really understand them?  Isn’t there a risk that a number like a million, a billion or ten billion just looks “large” and without any context it’s difficult to understand how large?


Let’s explore an example.  Back in December 2012, there were a number of news articles explaining how the US Air Force had cancelled a major software project that had cost $1 billion dollars and taken six years.  Clearly $1 billion dollars is a big number – but how big?  Knowing the absolute number is useful, but having some kind of frame of reference for that number is also useful – particularly for people who aren’t familiar with the US Air Forces budget. Otherwise it just sounds like “a lot”.


What about if we considered that number in the context of salaries.  According to information published online a senior airman in the USAF can earn up to $28,840.  That can be used to put the $1 billion into context.  We can expand the headline figure:


“The cancelled US Airforce project software cost $1 billion, to put that into context, that’s enough to pay the salaries of 3,500 senior airmen for a decade.”


That’s a scary and sobering thought.  $1 Billion just sounds like a big incomprehensible number.  When you chunk it down into what it actually means or what else it could have bought, many people will find it easier to comprehend.


Why does this matter?  Within all organisations, whether mid-size or multinational, executives are making decisions every day.  There’s normally a cost associated with adopting a new strategy or initiating a new project, and these costs might be large.  Contextualising raw data and raw numbers in terms of how many products you have to sell to fund it, or how many new customers you have to convert, can really help.  Clearly in a project environment a business case is a key input into this process.  It’s also important to consider whether your organisation knows the cost of client acquisition, as this can be a very useful metric to compare against.


In summary, large numbers can be made more comprehensible by comparing them with something that is readily understandable.



This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.


IBM Logo


tumblr tracker

Cast the Net Wider to Build Quality into Projects

I’m pleased to say that one of my recent blog articles has been published on “”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.

A short excerpt is shown below:



Green fishing netIn his recent article “What You See Depends Upon Where You Look,” Steve at describes how change agents can often get different views on whether there is support for their initiatives depending on where they look.


For example, asking individual direct customers whether they support a project to change the billing procedure may yield different results compared with asking the sales team. Both of these scenarios might yield different results from holding a focus group, where customers are interviewed in a group.


It’s important to find a strategic path that takes into account valid individual views and concerns as well as considering the bigger picture. This is certainly true, and while reading Steve’s article, it struck me that there is a direct parallel relevance for those carrying out business analysis on projects too. The stakeholder landscape on projects can be extremely complicated, with dispersed stakeholder groups potentially spread all over the world. In fact, sometimes there might be a few political landmines too, which are best avoided.


As well as having different attitudes towards the project or change that is being pursued, stakeholders will also have different views over what should be included in the scope of the project. They are also likely to have differing views over what requirements need to be included, the priority of those requirements, and perhaps even which solutions would be acceptable.


This reinforces the need to cast the net wide early on in projects…


Click on the link below to read the rest of this article


What business advice would you give your younger self?

People holding up paper showing a question markTime really does fly.  I can still remember my last day at college like it was yesterday.  I can remember the sense of achievement, purpose and an overwhelming feeling that anything was achievable.  As I walked through those college gates for the last time, I remember feeling that I could change the world. And, if I recall correctly, my first step to changing the world was to celebrate at a nearby bar with a beer…


Sadly, this was rather a long time ago now – longer than I like to admit.  But I recently had cause to reflect and think back to those hard but hedonistic college days.  Believe it or not, this self-reflection was prompted by a simple thread in a LinkedIN forum.  One of the contributors posed the question “What business advice would you give your younger self?”, and there are a number of great responses.  If you get the chance, it’s well worth reading the whole thread here.  This is such a simple yet powerful question, and it really got me thinking.


Having reflected on this question I thought I’d share the advice that, in retrospect, I would give myself when I was that naïve, green-around-the-gills graduate that was walking out the college gates.    I wouldn’t for one moment suggest that this advice should be seen as definitive (and I wouldn’t even suggest that it should be taken seriously). It’s little more than a product of my own meandering experience, but I’d love to hear your thoughts.  Perhaps after reading this article, you could let me know what advice you would give your younger self?  Here are my suggestions:

Continue reading What business advice would you give your younger self?

There’s No Such Thing as an IT Project

I’m pleased to say that my most recent blog article has been published on “”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.


A picture of an iceberg, with most of the iceberg submerged below the water-line
Is IT just the tip of the iceberg?


As anyone who has ever read the Standish Group’s “Chaos” report knows, so-called IT projects have a fairly poor success rate. Nick Malik recently built upon this idea in his article “Everything you’ve read about IT Project Failure is wrong.”

Nick argues that, while traditional thinking focuses on looking within the project environment for the root-cause of failure, the most serious root-causes—such as a lack of accountability for success, slow decision making, etc.—are completely outside the project’s control.

I agree with the points raised in the article, and I think it’s possible to extend this analogy even further. I’d argue that there is no such thing as an IT project—there are only business projects that implement, impact, change, or interface with IT. This sounds like a subtle distinction, but it’s deceptively important.

As soon as an organization frames a project as being specifically IT, the project focus tends to shift to the technology. This is rather like the metaphorical “tail wagging the dog”…


Read the rest of the article by clicking the link below:

Make Your Requirements Atomic!

I’m pleased to say that my most recent blog article has been published on “”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.


Atomic symbol in bookExcerpt:

“I have to admit that I have a rather eclectic music collection, with tracks covering almost every conceivable genre. Every time I hit the “Shuffle” button on my MP3 player, there’s a tense moment of jeopardy.


Will the next track be by an epic rock legend, or will it be a remix of some trashy 90′s pop song? The mystery is part of the fun!


After hitting the “shuffle” button this morning I was rewarded with the excellent 80’s track, “Atomic” by Blondie.  In a moment of lateral thinking, this 80’s new-wave song prompted me to think about requirements, and specifically about requirements quality.  Let me explain…


Good quality requirements have a number of characteristics.Many authors have produced guidance around requirements quality, and as an example…”


Click on the link below to read the rest of the article:

Internal Social Media and the Business Analyst

I’m pleased to say that my most recent blog article has been published on “”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.


Picture of a laptop connected to various social network logos, depicting social mediaExcerpt:

In the Harvard Business Review article “Three Examples of New Process Strategy,” Brad Power outlines three fundamental ways that organizations can improve their processes. He mentions one particularly innovative example, where an organization used internal social media to engage with its front-line staff to understand the faults with a particular process and determine how the process could be improved.

This example really resonated with me. I’ve long found that the people who really know how business processes work are those that actually operate them. An informed and empowered front-line worker can often spot opportunities for incremental improvement that otherwise might have been missed. This philosophy of staff engagement is key to the Kaizen continuous improvement methodology made popular by Toyota and the lean movement.

As a BA I’ve spent many hours observing and interviewing front-line staff, mapping processes, and improving processes. Brad Power’s article has made me question whether there is a better and more effective way of reaching out to stakeholders, such as front-line staff…


Read the rest of the article by clicking the link below:



Do too many BA “cooks” spoil the broth?

I’m pleased to say that one of my recent blog articles has been published on “”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.

A short excerpt is shown below.


Picture of a soup bowl with a ladel
Do too many BA “cooks” spoil the broth?

“I recently had the opportunity to attend and speak at the Req-Labs Conference in Kyiv, Ukraine. I love attending conferences in different countries as it provides the opportunity to understand the opportunities and challenges that different business analyst (BA) communities face.

One extremely common challenge described by the attendees related to stakeholder engagement. A number of the BAs at the conference worked for companies that provide business analysis and/or software development on an outsourced basis, often to companies located in a different country. This can lead to a situation where it’s difficult to get direct and unhindered access to project stakeholders.

In fact, one attendee described a scenario where the BA role was duplicated, with one BA team in the client organisation who was feeding requirements to the BAs in her organisation. In situations like this there’s significant room for misunderstandings, duplication of effort, and conflict.

This raises an interesting question: How can a BA best operate when it doesn’t seem possible to get direct access to stakeholders and when there are multiple BAs from different organisations or different teams in the mix?….”


Read the rest of the article by clicking below: