Project lessons from the Great Train Robbery: Familiarity breeds contempt

UK history was made on the 8th of August 1963 when £2.6 million in cash was stolen from a Royal Mail train. The “Great Train Robbery” has entered the collective consciousness of British culture as a daring heist executed by cool criminals, many of whom stayed on the run and evaded capture for years.

 

The facts behind the Great Train Robbery are astonishing.  The cash (equivalent to about £43 million today) was carried in an unguarded compartment, and was stored in sacks (rather than a safe).  Looking at this arrangement in the cold light of day, it’s easy to ask why the risk hadn’t been foreseen.  I’m no expert in rail security – but if I was transporting over £40 million, I’d make sure it was locked and guarded!  In many ways, it could be seen as a robbery waiting to happen.

Continue reading Project lessons from the Great Train Robbery: Familiarity breeds contempt

The PM and BA debate

Man in a suit with boxing gloves
PM and BA: Friendly rivalry?

I recently came across an extremely interesting and lively debate in the BA Times LinkedIN discussion forum, where the perennial discussion of the relationship between the Project Manager and Business Analyst was discussed.  A number of views were stated during the discussion, and it’s clear that in some organisations, a view exists that there is a natural career path from senior BA to PM.  Some take this view further, and in her 2007 article entitled “The Yin and Yang Of Project Management and Business Analysis”, Juliet Alters argues that interested BAs should be “groomed” for project management roles. 

 

I’ve always found this view curious.  Whilst there are certainly some overlap between the roles, the disciplines of Business Analysis and Project Management are distinctly different.  As Elisabeth Larson quite eloquently points out in her article “Can You Be Both PM and BA on the Same Project”:

 

 “The PM’s role is to meet the project objective (PMBOK® Guide Fourth Edition Section 1.6). The BA’s role is to help organizations to reach their goals (BABOK® Guide 2.0 Section 1.2). This is a subtle but important difference”.

 

There may be similar shared competencies, but there is a very different focus.  To draw an analogy, an Electrician and Plumber may share similar core competencies (dexterity, ability to read schematic diagrams, ability to communicate with customers), but I can’t imagine anyone arguing that an Electrician should expect to “progress” to a Plumbing role.

Continue reading The PM and BA debate

Can your organisation quantify acquisition cost?

Model of businessman walking along ruler with briefcase
How much does a customer “cost”?

If you’re a regular visitor to my blog, you may remember that I’ve previously written about the hazards that can occur when organisations measure the wrong things.  Today, I’m going to outline a similar (but subtly different) danger: What happens when organisations don’t measure the right things, by using one specific example.

 

Continue reading Can your organisation quantify acquisition cost?

The Forgotten Art of Document Analysis: 8 Documents That Can Help You Ask the Right Questions

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 take a look and add a comment on the site.

 

Excerpt:

Documents spilling out of a filing cabinet
Documents often say a lot about a process…

“Elicitation can be a tricky activity. Often when needing to understand the requirements for a particular project, the temptation is to jump straight into facilitating a requirements workshop or holding stakeholder interviews. The challenge, of course, is getting enough stakeholder time, and knowing which questions to ask with the limited time available. Understandably, business stakeholders are often too busy running the business to attend meetings, workshops or interviews.

It’s important to come prepared with as much information as possible, and the technique of document analysis can be extremely useful.”

Read the rest of the article by clicking below:

http://www.bridging-the-gap.com/the-forgotten-art-of-document-analysis-8-documents-that-can-help-you-ask-all-the-right-questions/

 

Benchmark and simplify before you automate

Picture of rusty metal machinery gear
Automation without analysis compounds existing problems…

A common challenge for businesses of all sizes is the necessity to do more with less; to deliver greater benefit with less investment.  Understandably, there is often a focus on ensuring that the business operates as efficiently as possible.  Eliminating waste and re-engineering business processes so they are quicker and slicker is certainly one way of saving money whilst also continuing to deliver value to the end customer.

 

A logical extension of business process optimisation is the introduction of technology to automate (or semi-automate) business processes.  The word “automation” often brings in images of robots in a car assembly line, but there is a parallel in just about every industry—whether multi-national or mid-size.  It’s often associated with growing and successful mid-size organisations that are looking to scale up or expand their operations.  In the service industry, automation often relates to the provision, processing or delivery of information rather than a physical product.  For example, a call centre may provide responses to their most regular query using Interactive Voice Response (IVR) systems and recorded messages, rather than keeping the customer on hold.  A bank may automate its retail loan applications process, rather than relying on manual underwriting.

 

However, automation is not without its pitfalls.  Before any organisation considers automation, it should undertake three key activities:

Continue reading Benchmark and simplify before you automate

Upcoming Speaking Engagements

As many of you know, I’m enthusiastically believe in the value of Business Analysis and Business Improvement, and I love speaking and presenting on these topics.

I have two speaking engagements in the next couple of weeks, one of which you can tune into virtually (for free!).   It would be great to see you at either of these events:

 

ReqLabs conference, Kyiv, Ukraine:  9 November 2012.

My presentation is entitled “Enterprise Analysis: The importance of the ‘why’ and the ‘what’”

BA SummitVirtual conference (free to register): 12 – 19 November 2012.

My topic is “How to show sceptics the value that business analysis brings”

 

I hope to have the chance to catch up with you at one — or both — of these events!

All the best,

Adrian

 

PS – If you enjoy my blog, please feel free to reach out and connect with me on Twitter (@UKAdrianReed), by leaving a comment, or by subscribing.  Thanks!

Cutting through the requirement prioritisation nightmare

Pair of scissors
Prioritisation doesn’t have to mean cutting out requirements

Requirement prioritisation can be a difficult exercise.  Often, stakeholders will insist that every requirement is essential and prioritising or de-scoping requirements can feel like asking colleagues to part with their most treasured and sentimental personal possessions!  In this article I’m going to outline three considerations that make prioritisation significantly easier.  I’m going to refer to the MoSCW prioritisation framework throughout the article.

 

1. Get the foundations right

When prioritisation is difficult, this suggests that there isn’t a shared understanding of the business value and the customer value that the project will deliver.  This suggests that the foundations of the project are shaky—perhaps insufficient enterprise analysis took place.  In these cases, it’s worth taking a step back and asking “What problem or opportunity are we trying to address here?”.  If that isn’t clear, then make sure this is resolved before moving forward.  Jeff Patton touches on this in his article How I Stopped Worrying and Learned to Love Prioritization and he underlines the fact that business goals must be explicitly stated.

 

Continue reading Cutting through the requirement prioritisation nightmare