Image Credit: © Zsolt Biczó – Fotolia.com #80480923
The Docklands Light Railway (DLR) is an automated light railway system that helps people transit around the bustling metropolis of London. Unlike the underground “tube” and the main rail network, the DLR is driverless. The trains shuttle about their duty, computer controlled and remotely monitored.
The fact that they are automated and driverless means that you can sit right at the front—and more than once I’ve seen a kid at the front pretending she or he is the driver. In fact, I’m pretty sure I’ve seen some adults doing the same! Of course, the reality is that however much they pretend to control the train, however much they pretend to pull levers and look at dials, nothing they can do will affect the journey. The only way they could immediately affect the journey is to pull the emergency stop handle (which would be a very bad idea on a busy commuter train!).
As I watched someone playfully “pretending” to drive the DLR, it struck me that far too many projects (and organisations) are run this way. There is someone in charge—perhaps because they have been given the role, or perhaps by virtue of their level of seniority—and they spend time looking at reports, enquiring as to why things are “red” and “amber” and seeking to steer the project (or organisation) in a particular direction. The challenge is that organisations are not always “wired” to ensure that the “drivers” get the feedback that they need, when they need it—meaning they can’t make the corrective action that they need to make. They only see things when it is too late, their options are limited and so often they have to take drastic and sudden action. The only control open to them at this point is to pull the emergency brake.
Nested Feedback Signals
Presumably, the DLR functions because a computer keeps a constant eye on speed, obstructions on the track and other vital signs. The location of each DLR is monitored, and if anything unexpected happens, presumably someone in a control room is paged to work out what action to take (and whether it’s necessary to re-route trains). I’d expect that feedback signals are monitored at varying levels—carriage, train, network etc. Of course, if all else fails, there is a big red handle that anyone can pull in an emergency—if something so unexpected happens that it hadn’t been foreseen, there is still a way of halting the train. Although the train system in the UK is far from perfect, in some ways it is amazing it works at all given the complex mixture of routes, rolling-stock and resources that are needed to make it run.
This is similar to projects in an organisation. Projects, like trains, run around gaining momentum. Yet does feedback really get to leaders and decision makers quickly enough? Or are there projects that are “green with a desperate shade of red”? And even if each project in isolation is being managed well, who is managing the “rail network” of projects? Or are we all just individual train drivers reaching a (totally predictable) bottleneck proclaiming that “our train (project) is the most important”?.
Good analysis enables timely decision making
As business analysts, we have a crucial role to play here. We can ensure that the right types of metric are defined and collected during the project and once the change goes live to indicate successful and functional operation of the change. We can help people decide in advance what would cause them to slow down, halt or change direction. So often, we are in a position to see risks that others can’t, and it’s crucial that we articulate this. We can build in “emergency stop handles” at different levels in the project. Sometimes a stakeholder might just need to stop a particular piece of work as they feel it is going off track. This can be as simple as raising a red card in a workshop. Other times, we might need to collectively “put the brakes” on a project because something externally has fundamentally changed. This might be a painful conversation, but nowhere near as painful as delivering something that is functionally fantastic but now totally irrelevant. By ensuring subtle signals are conveyed first, we aim to avoid this type of more drastic action.
So, do the decision makers in your organisation get the data and feedback they need to make informed decisions and subtle corrections? Or are they “driving the DLR”, with only one option: suddenly hit the emergency brake.
What are your views? Please add a comment below, and let’s keep the conversation flowing!
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
Interesting post Adrian! I wonder if I might ask a cheeky follow-up question? Once a BA has identified that there is a problem or issue, how would you go about raising that/challenging the status quo in a way that would make your stakeholders or decision makers take notice? Sometimes it can feel like we BAs are waving flags like mad but no-one is watching!! I’d be interested to hear your technique for making a point…..
Thanks
David
Hi David, great to hear from you and thanks for your comment. You raise a very good question, and one that I suspect there is no easy answer for. It is a fine balance between being the “squeeky wheel that gets the grease” and “that annoying car alarm that is always going off and everyone ignores”.
One good piece of advice a very inspirational leader once gave me, it to “choose your ‘battles'”. Ignoring the war metaphor, I think this advise has stood me well. Escalation is more meaningful if it is only occasional.
I suppose it is also about empathy, and thinking “what is in it for them” and “where are they coming from”. I find elements of the “soft systems” techniques useful here… Perspectives, worldviews etc.
Perhaps a working assumption should be “everyone is acting logically, based on their goals, experience and perspective”. If they are ignoring a risk it’s either because (a) they don’t see how it relates to their perspective of the world and)or; (b) we’ve projected our own perspectives on to them and have misjudged the situation.
All of which is a very long winded way of saying it is all about understanding people, finding the ‘hook’ and empathising.
What do you think David, do you have any other approaches?
Thanks again,
Adrian
PS– this is such a great question, if other readers have ideas, techniques, experiences to add, please *please* do add them. I’d love to hear them!
Hi Adrian, sorry for the delay in replying but here’s my thoughts. I agree with your point completely about assuming everyone is acting with the best intentions and I think BAs should always assume positive intent when you find yourself with a challenge relating to requirements or a particular stakeholder as to do otherwise will risk souring the debate. I also agree that you sometimes need to choose your battles carefully. In fact to continue the military analogy, sometimes you need to avoid it completely. I still remember one particular meeting long ago that I attended alongside the project manager I was then working with (not for). We were meeting with a particularly truculent (and expert) stakeholder and the meeting became a near-literal ‘butting heads’ session as the PM and Stakeholder doggedly held their entrenched positions. Afterwards I asked the PM whether they had heard of the Maginot Line? When told “no” I explained how prior to WW2 the French built a huge wall of fortifications along the border with Germany which they confidently sat within thinking it was impenetrable. Which it was, FROM THE FRONT. So the Germans dropped paratroops behind it and also skirted round it through Belgium whom the French regarded as an ally thus didn’t fortify that border. So the great wall came to nothing. The point I was trying to make to the PM was, if you can’t go through it, go round it. As it turned out, there were other more powerful stakeholders who had requirements that were of higher priority than that of the truculent colleague and this precipitated a more open debate.
One final point I would offer is that always challenge off the back of a Fact Based Discussion (FBD – I may trademark that acronym) rather than blind intuition. Whilst the latter may be correct the former is easier to prove!
Fantastic points David, and if I could add that (as illustrated by your very interesting example) there is a place for storytelling in all of this too.
After all “Facts tell, stories sell…”
Thanks again David, really interesting!
Hi Adrian, really interesting read for me. I’m not actually a BA yet, however i’m involved in project work for my company and am learning the ropes of BA work as i go in a developmental sense. I’ve come to the world a little late but i’m truly loving every moment of it. Your posts are a really good part of my on-going research. One thing i have noticed is that stake holders/PM’s/Product Owners sometimes have such a wide view that its often a “Can’t see the trees for the wood” situation. Therefore, trying to make them aware of potential pitfalls 3 or 4 moves down the line can be a challenge. However, i’m slowly picking it up i think! Again, thanks for the posts and i look forward to the new ones!
Ian
Hi Ian,
Thanks so much for your comment, and I’m so glad you find my posts interesting/useful, and even more glad to hear that you’re enjoying making the transition to the BA role!
In case you weren’t aware, I also run webinars. There are a whole series of (free) recordings available here: http://www.blackmetric.com/webinars
This might prove useful in your ongoing research too!
Thanks again, stay in touch & reach out at any time.
Adrian
There is always a train operator on board every DLR train. Just so you know 🙂