How to Explain Big Data to your Grandmother

Solink recently published an infographic with the title “How to Explain Big Data to your Grandmother“.

It was put together for The Grandma prize, at Montreal’s Internatonal Startup Festival. To claim this prize, you have to break your idea down to its fundamental parts, and pitch it to a group that will not be up-to-date on the latest jargon and technological advances.

The infographic does that quite well. What do you think of it?

Big Data Infographic


8 tips from Paul Newman on being a Business Analyst


Paul Newman, – actor, film director, entrepreneur, professional racing driver, auto racing team owner, and auto racing enthusiast, and … Business Analyst guru.

What?!! BA Guru? 

Yep…draw closer and I’ll tell you why…

Paul Newman was president of “The Actor’s Studio” from 1982 till 1994. In the second ever episode of “Inside The Actors Studio“, Paul Newman was the guest. He spoke clearly and passionately about his career, and his craft.

And what he said can be applied to the profession of Business Analyst…

1. Working with others gave him the opportunity to join The Actors Studio – It was because he was helping someone audition for The Actors Studio that he as invited to join himself.

Translation: Working with others can be invaluable, and can create new opportunities.

2. He learnt a lot by observing others. – Paul picked up a lot about his trade from watching others, and learning.

Translation: Every Business Analyst can learn from other Business Analysts. We all have skills that have come from unique experiences.

3. He goes back to the Studio to continually improve, and to work on his faults. -He is not an intuitive actor. Paul is always concerned about his own performance. He considers himself as “just tenacious”, and keeps on trying.

Translation: Continual learning, and improving is essential. Being able to identify your weak areas, and work on them is important.

4. Did a lot of work identifying his skills.

Translation: look at yourself, and asses where your strengths are with regards business analysis. You might be better at eliciting requirements from stakeholders through interviews, and workshops than you are at creating business process models. Don’t be afraid to use your strengths (while working on improving other areas).

5. Rehearsal is important to him. – Paul likes to prepare for the scene. He always wants to ensure that the team works smoothly and efficiently.

Translation; Preparation ensures that things go smoothly. If things go smoothly, it means a happy Project Manager, and a happy client. 

6. Good Communication skills – During the interview Paul was very engaging. His communication style was very good.

Translation; Communication skills make the difference when engaging with stakeholders from all levels. Use a simple language, and be clear, Be engaging.

7. Started off with no real “him” - Paul stated that, in the beginning, he was just a collection of “bits of characters” – it was through a series of experiences that he was able to “define himself”.

Translation – A strong Business Analyst is confident in his, or her, capabilities. Don’t try to be something that you are not. Clients want conviction when talking with a Business Analyst.

8. Developed a short-hand with Directors he had worked with for a long time. – Paul claimed that he had worked with some Directors for long enough that they knew what each other wanted without having to explain it.

Translation: Get to know the members of your team, or at lest the Project Manager. The better you understand each other the better the communication.
So – there you have it. While discussing his craft, and his career, Paul Newman made several good points that can be applied to the profession of a Business Analyst. In fact, not just a Business Analyst. They can be applied to almost anything…

Simple advice – How to Make Ugly Slides Beautiful

This slidedeck presents some fantastic tips on turning slides from dull to wow. I really like this one.

Collection of interesting infographics for those touring the world

In a slight diversion from my usual subject matter, here’s a collection of interesting infographics that has made about the following popular travel destinations:


London Infographics by Accorhotels
go back to top of page


Paris Infographics by Accorhotels
go back to top of page


Amsterdam Infographics by Accorhotels
go back to top of page

New York

New York Infographics by Accorhotels
go back to top of page


Guide to Rome by Accorhotels
go back to top of page

Brazil Carnival

Brazil infographics by Accorhotels
go back to top of page


Dubai Infographic
go back to top of page


Moscow Infographics by Accorhotels
go back to top of page

The BA is the least knowledgeable about Agile

most knowledgeable

According to VersionOne’s 2013 State of Agile survey, Business Analysts rank as the least knowledgeable about Agile.

I sort of understand this, but it really shocked me when I saw it. As you can see in the image above, the ScrumMaster is judged as being most knowledgeable. That makes sense to me. The Project Manager is ranked as the next most knowledgeable. More so than the Developer. That was news to me. From what I have seen, its the Developers that have been embracing the Agile concept with passion, and a lot of this is filtering upwards.

To read that the BA was at the butt-end of the list had me break out in a cold sweat. I can imagine that, because the Business Analyst has been traditionally involved in the big “document it upfront” way of doing projects (aka Plan-driven), that there is quite an adjustment to move into a change-driven approach.

Also, a lot of the Business Analysts knowledge is very BABOK 2.0 -based. And the BABOK 2.0 didn’t even mention Agile until they published the “Agile Extension” in 2013. (Fortunately, IIBA will be releasing version 3.0 of BABOK soon that takes a completely new look at the Business Analyst and how it fits into the real world).

But is this a valid excuse for being listed way down at the bottom of “most knowledgeable”? I think not. There are plenty of resources out there that help even the most documentation-addicted Business Analyst become a little bit more knowledgeable about this philosophy.

Why do you think Business Analysts know so little about Agile? What else can be done to improve this situation?


CASE 1- CATWOE & Value Proposition


Having recently “discovered” CATWOE, I found this to be an excellent article.

Originally posted on The science of enterprise—and doing good.:

This is a real life example (has to be anonymous) that shows how defining the core-purpose of your business enables you to define and understand the essence of the value proposition. First up is what the owner described as a manufacturer of coated parts, but what was the value proposition? You’ll need to remind yourself of what CATWOE is here, and my interpretation of what must comprise the value proposition.

1. Hermann Engineering Ltd
Herman Engineering Ltd (HEL) was founded in 1890 by two partners James James and Robert James. It  started its long life near Cardiff in South Wales. It was set up originally to provide a service to the local steel industry, which started to go into heavy decline at the beginning of the 1970s. The company’s principal activity had always been the surface treatment of metal components. Surface treatment involved a variety of processes including, simple…

View original 540 more words

Don’t forget’s! when designing for the Web

HQ have put up a great presentation on Slideshare, It that encapsulates some very important factors that must not be forgotten when designing for the web.

I encourage you to have a look…

Is Agile a Cult?


Agile: a set of software development methodology principles in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Agile software development is very popular at the moment. It offers a responsive way of developing, and companies are adopting it at a rapid rate.

I’m not going to talk about the benefits of agile – a simple Google search will tell you more than you need to know.

What I do want to touch upon is a comment that someone made to me -Agile is too much like a cult“.

So, let’s have a look … is Agile a cult?

Definition of a cult

  1. a small religious group that is not part of a larger and more accepted religion and that has beliefs regarded by many people as extreme or dangerous
  2. a situation in which people admire and care about something or someone very much or too much
  3. a small group of very devoted supporters or fans

- Mirriam-Webster

Which applies?

Looking at the above definition, it is obvious that Agile does not fit into the first explanation. What about the second one? (Or the third?)

The Cult Checklist

Michael D. Langone, Ph.D. published an article in which he describes patterns found in cultic environments. Let’s see how Agile measures up…

  • The group displays excessively zealous and unquestioning commitment to its leader and (whether he is alive or dead) regards his belief system, ideology, and practices as the Truth, as law.

I’ve got to admit that I have met lots of Agilist that are of the opinion that anything non-Agile (aka: Waterfall) is inferior and wrong. In fact, any discussion on “Agile vs Waterfall” can turn quite heated with those supporting Agile to be very … passionate about the “truth”.

  • Questioning, doubt, and dissent are discouraged or even punished.

Refer to my comments above.

  • Mind-altering practices (such as meditation, chanting, speaking in tongues, denunciation sessions, and debilitating work routines) are used in excess and serve to suppress doubts about the group and its leader(s).

Umm…haven’t seen any evidence of this. (Unless you can consider the “weekend Hackathons” that are often held by ‘self-organising teams’, as a debilitating work routine.)

  • The leadership dictates, sometimes in great detail, how members should think, act, and feel (for example, members must get permission to date, change jobs, marry—or leaders prescribe what types of clothes to wear, where to live, whether or not to have children, how to discipline children, and so forth).

Nope … 

  • The group is elitist, claiming a special, exalted status for itself, its leader(s) and members (for example, the leader is considered the Messiah, a special being, an avatar—or the group and/or the leader is on a special mission to save humanity).

Hmm … I have detected a certain “elitist” tone when Agile supporters talk about their passion. I’ve even hear someone say “We are Agilist – we don’t believe in …”. How well this fits the description…you decide.

  • The group has a polarized us-versus-them mentality, which may cause conflict with the wider society.

Definitely a polarized us-versus-them mentality. primarily when discussing non-Agile development methodologies. But, to the best of my knowledge, this does not cause conflict with the wider society.

  • The leader is not accountable to any authorities (unlike, for example, teachers, military commanders or ministers, priests, monks, and rabbis of mainstream religious denominations).

It’s is true…. However, not even relevant.

  • The group teaches or implies that its supposedly exalted ends justify whatever means it deems necessary. This may result in members’ participating in behaviors or activities they would have considered reprehensible or unethical before joining the group (for example, lying to family or friends, or collecting money for bogus charities).

I burst into laughter when I thought how Agile could fit this description …

  • The leadership induces feelings of shame and/or guilt in order to influence and/or control members. Often, this is done through peer pressure and subtle forms of persuasion.

Laughter again….

  • Subservience to the leader or group requires members to cut ties with family and friends, and radically alter the personal goals and activities they had before joining the group.

Nope …

  • The group is preoccupied with bringing in new members.

Umm… Not really

  • The group is preoccupied with making money.

Aren’t we all … ?

  • Members are expected to devote inordinate amounts of time to the group and group-related activities.

See my comments above on Hackathons.

  • Members are encouraged or required to live and/or socialize only with other group members.

If this is happening, I feel that I have missed out. No one every encouraged me to live and/or socialize with other group members…

  • The most loyal members (the “true believers”) feel there can be no life outside the context of the group. They believe there is no other way to be, and often fear reprisals to themselves or others if they leave (or even consider leaving) the group.

Well…I know that the Agile “true believers” are unwilling to consider anything that is non-Agile. To even mention the phrase “fully documented requirements upfront” would result in being feeling the true wrath of the Agilist. (Note – this is not something that I am even recommending. It can be dangerous). However, most Agile supporters that I have met do not fit this description. (There is no fear of reprisals.) 

So – is Agile a cult?

Yes … and … No.

Looking at the Mirriam-Webster definition, Agile is something that people admire and care about very much (or too much). True Agilist are very passionate about the Agile methodology, and often have disdain for anything that isn’t Agile. You see more Agile “groups” than with Waterfall (for example). And there seems to be a need to identify with each other, and promote Agile to both “non-believers’, and well as to those who already are followers.

However, Agile certainly does not have all the characteristics that Langone describes in his essay. There is no “mind control”, or strict, unquestionable, rules.

All-in-all, I think we can all sleep safely in the knowledge that our children are not going to be dragged off to some Agile compound somewhere.

In fact – just to make you feel even safer, here is a picture of a cute kitten.


What do you think?

Do those promoting Agile seem a little over-enthusiastic (albeit zealous)? Or is it just healthy passion for something that is a good idea? Leave a comment below.

Back from the Darkness

I'm Back

Time: Friday evening, 23 August 2014

Place: Here

I clicked on the link to my blog to discover ...

24-08-2014 21-35-21

Aarghh … Wordpress had suspended my blog due to a breach of their Terms of Service.

I went through the terms with a magnifying glass. There was nothing that I seemed to have blatantly ignored. Maybe there was something that I had accidentally infringed…

I quickly found their response form on their site, and asked for more information. 

And … it turns out that it was a mistake



Asking the question: GOOD; asking it over and over: BAD – where social engagement in the workplace fails.


Using social tools within the enterprise is a valuable thing. It lets people ask questions to a bigger audience than just those sitting within hearing distance of their desk.

I’ve discussed this in earlier posts (ESS (Enterprise Social Software) – user adoption, and Let’s share!). It’s incredibly valuable to be able to draw on the knowledge of others. That’s why it’s good to be able to ask questions. The answer given helps not just the asker, but can help others, and at the same time, others can add to the answer creating even more value.

Where I feel this all falls down though is that, often, there is no real way to capture that knowledge that came about from the questions asked. And so, what happens, is that the same (or a similar) question is asked again. Maybe a year later, maybe two years later. And often because new participants in the conversation appear, and the original participants move on to new things.

End result – same question, asked again. 

Is this bad? It certainly has an up-side…asking that question can create a whole new conversation, the outcome of which can enrich (once again) the knowledge of the participants, and allows for the building of new relationships, but this is not efficient. Essentially there has been no “forward momentum”.

What’s needed?

Simple – a way to “capture” the knowledge. But further to that, a way to easily allow the knowledge to be retrieved. And not as part of a silo, but in a way that allows people to easily surface this knowledge in a “serendipitous” way. And by this, I mean, in a way that the individual doesn’t really have to think about. One central place where a click on a keyword, or the typing in of a natural question, will draw this information to the individual’s attention.

Has this already been done?

I think, in fact, that this has already been done…by Google. But this is outside the firewall. Now to get the same effect inside… And this is something that many large search companies (MS, HP Autonomy, etc) are working on. I’m curious how this will work out. The sooner we can grab answers to questions that people ask (and even the ones they don’t ask) we’ll stop asking the same question.

What’s your opinion? Are there already solutions that solve this problem? Do they work?


Now this is the right way to do it – webinar times in a big world

Kudos to ProjectTimes.

The Internet is a global thing. This means that anything that you publish on it could be read by pretty much anyone in the world. As a result, it is incredibly valuable to offer times, dates, et cetera, in a way that can be easily “localised’.

Project Times promoted a webinar, and were good enough, with the time, to add the offset to GMT. This meant that I could easily calculate what that time was in my time zone. (Rather than having to try and google a translation.)

webinar instructions

My only grumble with this, is that UTC should be used rather than GMT.
However they are both aligned so it’s not that bad.

Understanding the Frustration of a PM


So there he was. Charlie had been assigned as lead BA on a project with an external client. “Cool” he thought, but still felt a bit nervous. There were others in his department that had been in the game longer, and he was still reeling from having the proverbial  “slap in the face” in an earlier project that had turned slightly pear-shaped..

As such, Charlie decided to ask some of his colleagues for help. They were most forthcoming, and decided to hook in other expertise. “All fine” he thought, “the more experience available in this, the better.” 

Charlie drew up a elicitation plan, and scheduled several high-level interviews with the various stakeholders from the upper echelon of the company. On the agreed upon day, he headed on down to the client. He was joined by another BA (with a different skill-set), and the lead designer. Charlie was confident that, together, they would be able to get a deep understanding of the business objectives, business drivers, and expectations of the client. 

The interviews went extremely well. Because there were the three of them, each with a different background, and understanding, the notes gathered during these sessions were richer, than if Charlie had been on his own. Charlie was really chuffed. “This knowledge and understanding gathered today will be really valuable, not just for understanding the client and their expectations, but also when holding the lower-level elicitation workshops.” Charlie thought to himself. It was all good…

Until he got back. In his enthusiasm, Charlie had not actually thought about telling the Project Manager that there would be three people involved. The PM was furious. The two extra people meant that the man-hours used had just increased by a factor of 3. The project had already gone over budget. Charlie tried to explain that this meant better requirements had been gathered, and that it was going to help in the future, but this didn’t really help. The PM ended up having to have a very uncomfortable meeting with the client, and the project ended up coming in way over budget.

This story was inspired by a post on the ProjectTimes site titled A Business Analysts’s Best Friends: The Project Manager The key points from that post are:

  • The PM wants timely information from the BA.
  • Top-notch BAs
    • keep the PM informed.
    • ask for help when they need it
    • stay connected to other BAs
    • build great relationships with stakeholders,
    • build trust and ease users into changes.
  • Top-notch BAs have a broad vision. They can focus on the detailed requirements, but they understand how their piece of work fits into the larger project and organization at large.
  • PMs need to given firm estimates and implementation dates.
  • Successful PMs deliver projects on time and within budget.

Looking at Charlie’s story, you can see that he did do some things right. He asked for help, he focused on detailed requirements, and he worked hard to see how they fitted into the customer’s larger goals, and objectives.

At the same time, Charlie made some big mistakes. He didn’t keep the PM properly informed. And the consequences of this were quite serious.

What are your thoughts on this? Did Charlie really screw up royally? Or was he actually doing the right thing?


Is this a sign that the PMI’s BA certification is of more value?

Venus and Mars

In a recent ProjectTimes articleKiron Bondale described the oft-seen misalignment between Project Managers and Business Analysts.

In his article, he lists some comments made by each about the other…

From the business analysts, common complaints about project managers include:

  • Appear to be focused solely on cost or schedule constraints without also embracing the criticality of having good quality requirements
  • Demonstrate an unwillingness or inability to provide assistance in ensuring that stakeholders are attending and contributing to requirements gathering or review sessions
  • Don’t bother to read or understand high-level project requirements documents
  • Support or initiate scope change decisions without proactively engaging the business analyst

On the other side, I’ve frequently met project managers who complain about business analysts who:

  • Appear to have no sense of time or cost constraints when producing their deliverables or appear unable or unwilling to provide effort or duration estimates for their work
  • Produce requirements documents which are unusable by other project team members or which don’t address the customer’s stated and unstated needs
  • Appear to forget that the second word in their job title actually implies the task of analyzing, distilling and refining requirements as opposed to just parroting what’s been received from stakeholders
  • Become unavailable for the remainder of the project’s lifetime as soon as their requirements documents have been signed off

A lot of these comments see very familiar to me. As a Business Analyst, I have often felt that the interests of the Project Manager weren’t always in the interest of the customer. More or less exactly what the comments above describe.

I guess because, often, the BA is the one that is talking with the various stakeholders (from Management level through to the people performing the business tasks each day), that it the BA feels that they “really understand” what the real users want, as well as understanding their pain points.

As a professional, also, the BA wants to ensure that they have correctly, and thoroughly captured the users needs, and business/technical requirements, so that these are reflected in the final outcome. This sometimes takes more effort than planned for, or expected. And this can cause issues with the PM’s expectations who, while also wanting to provide a good solution, is also concerned with things such as costs, ongoing impact, etc.

Does this “misalignment” occur because PMs are from Mars, and BAs from Venus? That because they come from different “worlds”, they have different views on reality? If so, realising that the PM is the one that is “in charge” of the project, would it mean that a BA with a better appreciation of the world/ideology/background of the PM be of more value to the project?

And … does this mean that the BA certification offering from the Project Manager Institute, is going to play a bigger part in projects in the future?

Your thoughts … ?

See also:

Look Down

In a recent post (“Is being Socially Connected online really that damaging?“), I discussed a response to a video on YouTube that preached the sadness of the way people are constantly online.

I’ve just discovered another response to “Look Up”. This one is called “Look Down“.

And here’s the link to another good one:


How To Say “This Is Crap” In Different Cultures

Originally posted on HBR Blog Network - Harvard Business Review:

I had been holed up for six hours in a dark conference room with 12 managers. It was a group-coaching day and each executive had 30 minutes to describe in detail a cross-cultural challenge she was experiencing at work and to get feedback and suggestions from the others at the table.

It was Willem’s turn, one of the Dutch participants, who recounted an uncomfortable snafu when working with Asian clients.  “How can I fix this relationship?” Willem asked his group of international peers.

Maarten, the other Dutch participant who knew Willem well, jumped in with his perspective. “You are inflexible and can be socially ill-at-ease. That makes it difficult for you to communicate with your team,” he asserted. As Willem listened, I could see his ears turning red (with embarrassment or anger? I wasn’t sure) but that didn’t seem to bother Maarten, who calmly continued to assess Willem’s weaknesses in…

View original 808 more words

Customer Complaints Are a Lousy Source of Start-Up Ideas

Originally posted on HBR Blog Network - Harvard Business Review:

Consider this situation. A good friend of yours calls you one day to pick your brain about an innovative business idea. He’ll only consider pursuing this opportunity if you give him a positive review. This particular friend is unemployed at the moment, and he plans to invest most of his savings in the venture. So there’s a lot at stake for him.

On what grounds would you base your opinion? Would you trust your gut? Your past business experience? Look for examples of similar ideas you’d seen elsewhere or that have worked in the past? Try to find parallels from other industries that might also work in this case? Maybe you’d start by digging into a ton of data to confirm or refute your true opinion about the venture.

Clearly, there are many ways to evaluate an innovative business opportunity. But at the end of the day, whichever way…

View original 769 more words

Hah! My first data scrape


I’ve just finished Module 2 of the MOOC Data Journalism course (that I mentioned in an earlier post).

The description for this module is:

This module deals with the range of skills that journalists use to obtain data. This includes setting up alerts to regular sources of information, simple search engine techniques that can save hours of time and using laws in your own and other countries.”

And (like all the other Modules) is made up of four parts:

  1. Setting up ‘data newswires’
  2. Strategic searching – tips and tricks
  3. Introduction to scraping
  4. Data laws and sources

In Part 3, I learnt to do some basic data scraping. This, essentially, is a way of grabbing content from lists, and tables, on web sites.

We covered a few tools that make this possible. The one that did surprise me was that you can use a spreadsheet created in Google Drive.

The command is IMPORTHTML(url, query, index)

Just as a practice I used it to scrape the list of Titanic passengers from Wikipedia.

Here’s the Wikipedia link:

And here is the Google spreadsheet that I imported the data to:

It was my first scraping, and nothing fancy. Also the data does need a bit of cleaning (in one case, there was extra info in the HTML that the scraping pulled in).

Also, this functionality is not just available in Google Spreadsheet. I have read that Excel can also do this. If you know of any more, please let me know.