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.
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.
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.
“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.”
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:
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.