How to Avoid Issues by Using Your Radar Effectively

Often within projects, people talk about specific risks or issues being “on their radar”.  This normally means that they are aware of the risk or issue, are tracking it, but have made a conscious decision not to take any immediate action.  On large and complex projects it can become increasingly challenging to keep track of everything that is a potential problem.  It can be difficult to know which issues are material, and when to take action.  Often things get forgotten, and something that is “on the radar” today, might cause a severe issue tomorrow if it isn’t addressed.

Image of a RADAR station

Keep track of issues by using your RADAR

As Business Analysts, we play a crucial role in flagging and resolving issues throughout the project lifecycle. This might mean risks to the likely benefits that the project will deliver, or it might be a requirements conflict.  We need to keep a firm eye on our radar screen!  But how can we decide which issues are the most important, and which deserve our attention first?

You need a RADAR

In order to effectively track and manage the issues, we need to put some conscious thought into how we use our RADAR system.   With all the pressures that come with our day-to-day duties, it is sometimes tempting to rely on memory alone.  Don’t do this!  Projects are complex, and sooner or later you’re bound to forget something.  In the same way an air-traffic controller wouldn’t try to remember where all the planes under her control are located purely using memory, we shouldn’t try to remember every single issue without some form of record or memory aid.

Project level risks and issues should be recorded on a central issues log, and should be managed by the Project Manager.  However,  it is often useful to keep a less formal list of issues, risks, constraints, dependencies or problems which affect the BA deliverables.  You might also want to keep an informal, personal RADAR of all the issues that are important to you.

Luckily, the BABOK gives us a useful suggestion on how we might create our radar (see section 9.20 “Problem Tracking”).  Our RADAR could be as simple as an organised problem log:

But once we have our radar, how do we use it?

Using your RADAR effectively

1. Monitor proximity

On a RADAR screen, the distance of a particular item is important.  An air-traffic controller will need to know how far away a particular airplane is to determine whether they need to take immediate or preventative action.  In project, the significant thing is the proximity of the issue in terms of time.  It’s fine to make a decision to “do nothing” right now, but it’s essential to record a date when the issue will need to be revisited.

2. Monitor direction

Another significant piece of information that can be gained from a radar screen is the direction each airplane is traveling – are they moving closer or further away?   On projects, we need to know whether a risk or problem is becoming more or less likely.  If circumstances have changed, and a risk is now much more likely, we might need to take immediate preventative action. So keeping an eye on the likelihood of an event occurring is important.

3. Monitor impact

The severity of potential impact is also an important consideration, as it will help to prioritise our responses.  Clearly, if an air traffic controller had two airplanes heading for collision, that would take their absolute priority!  In projects, we may occasionally find that an incident arises that is so urgent it could significantly affect the amount of business benefit that the project delivers (or it might even threaten the delivery of the whole project itself).  These are the issues we should address first.

4. Monitor regularly and take action

A RADAR screen is only useful if somebody is looking at it. The same is true of any kind of risk, issue or problem log – if it isn’t being regularly revisited, then it has become a pure paperwork exercise.   Having a team problem log and reviewing it regularly can be a great way to ensure that all the issues are surfaced and dealt with.  You might not like what you see… but at least you’ll know!

>>Get Your Issues List Template

Laura’s issues list template, including embedded guidelines for managing the list effectively, is included in the Business Analyst Template Toolkit. The Toolkit also includes my requirements specification templates and business analyst planning and work aids. All of the templates in the Toolkit are fully editable and annotated, giving you a great starting point for your next project. And all come with accompanying work samples so you can see what a filled in template would look like.

Click here to learn more about Business Analyst Template Toolkit

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

your details are safe with us

Books and Courses You Might Be Interested In

Comments

  1. I like the RADAR analogy on managing risks – it was a good reminder to me that I need to re-consider these aspects of risks on a regular basis.

    I think those who love to analyze (like BAs) like to find risks, but often communicate all of them equally (the world is going to end!) without considering the likelihood, severity, impact, etc. When we bombard our stakeholders with a firehose of risks without adjusting for these attributes, our stakeholders end up becoming risk numb…and we often look like Chicken Little.

    When we digest the risks more as you describe, our stakeholders end up greatly appreciating our ability to be their RADAR for the project, as it helps them manage the project effectively.

    It’s one of the great ways BAs can add value to projects.

  2. Hi Adrian, Great analogy RADAR! I feel that BAs are ideally placed to engage people to own, identify and manage risks and should do more in this area than I see happening in practice.
    Mark, good point about the human side – we need to be savvy about people and their responses.

    You both might like my new book ‘A Short Guide to Facilitating Risk Management’, which came into existence thanks in part to a group of UK IIBA chapter members’ work once night early in 2010. The work we did together on ‘risky requirements’ forms a large part of Chapter 6. It’s now out on pre-orde at Amazon. Perhaps this is the first book to acknowledge the IIBA UK chapter as contributors?

    Cheers, Penny

  3. Hi Mark,

    Many thanks for your comment.

    I agree completely, sometimes as BAs we can be seen as “pessimistic” because we flag up risks and issues… however the truth is we are being “realistic”! As you have quite rightly pointed out, the important thing to do is to consider the likelihood/severity, to ensure we don’t flood our stakeholders with warnings that aren’t really material.

    I think a good RADAR can be a useful bridge between the BA and PM community, and can help us to speak the same language.

    Thanks again or your comment, I hope you found the article useful!

    Adrian.

  4. Hi Penny,

    Thanks for the comment, glad that you enjoyed the article.

    You are absolutely right in that there is a huge opportunity for BAs to do this in a more visible and structured way. Often the “day job” gets in the way, and we’re too busy to manage our RADAR… which leads to more work in the long run. It takes discipline to step back and vigilantly monitor the RADAR screen.

    With regards to your book, I remember the IIBA meeting well, and look forward to the book being released!

    Thanks again,

    Adrian.

  5. Great article Adrian. Being aware of whats on one’s radar is a crucial component of keeping the project out of trouble. This is one area where synergies of the team come to play as well.

    The BA/PM synergy – Sometimes, PMs keep a running log of issues, and outstanding items that get addressed on a regular basis. I tend to tap into those they sometimes span across different projects. It is also a good idea to keep a private list of issues / follow-up items that will keep the project healthy.

    The BA/QA synergy – QAs provide critical project issues towards the validation and verification phase(well, sometimes all along) of the project. Having regular touch points with them to know their list of issues is a good way to be cognizant of various risks to the project.

    As a BA, sometimes you need to act as a project whisperer and learn to extend your RADAR by tapping into others. :)

    Great article, and analogy!
    Yamo