Help a BA! How do I prevent overlooked issues and project mishaps?

The following question came to us and opens the door to exploration of communication techniques that prevent issues on projects….

As an enterprise BA, I inquire and engage team members to determine the thoughts behind the project (not just elicit requirements, etc.). In a contract I head with a NY firm, project meetings included those who have worked between IT and business. To address a problem or issue, key members would initiate BA or PM activities based on their perception. Through a side discussion or contact, I would discover that they do not have the understanding of the issue. (Grabbing a cup of coffee and asking ‘what keeps you up at night’ or ‘what are your recent accomplishments’ can reveal an amazing amount of information!) As to the project, usually time and money was wasted. My question is how to prevent these project scenarios and avoid mishaps. What do you think? I look forward to your input.

The reader exposes a common problem by illustrating a situation in which issues are uncovered in the midst of a project.  Is there a way to overcome project issues before they start? Not always, but there is a way to prevent many of them that revolve around comprehension or confusion.

Just Ask!

In fact the reader is already alluding to the best way to get a handle on these hidden monsters….Just Ask! Having pointed conversation in which the analyst directly reaches out to a stakeholder is one of the best ways to elicit concerns and issues that the individual might not be comfortable discussing in a group forum. Once out of the group, there is a problem that these stakeholder concerns might still not be uncovered, because some people don’t want to viewed as “not smart enough to comprehend what’s going on”. By asking, the analyst is implicitly stating that there is a desire to ensure that there is an inclusive environment for the purpose of comprehension on the project.

Additionally, there are, of course, different ways to ask a question. Turning the tables and asking individuals to help you as an analyst with a point of confusion is an excellent way to empower others to help you get answers. In doing so, you enable the stakeholder to actively teach you their knowledge. This will in turn help he or she learn what is perceived as confusion OR it will uncover items that need further collaboration in order to understand.

Good Old Fashioned Relationship Building

No matter the approach in asking questions, remember that by doing so as an analyst, you are building a relationship with the stakeholder through engagement and concern for their success on the project. Try taking this a step further and begin to build the relationship by just asking about the things that might be important to the individual, e.g., “How’s your wife?”, “I heard your son is on his way to college; what’s his major?”, “You mentioned last month that your father was ill; how is he doing?” These are all questions that are personal, yet generic enough to allow people to engage with one another on a level outside of work. They speak to the creation and maintenance of long-term trust relationships, and they pay dividends in the workplace. Why? Because caring enough to ask about these types of things shows that you care about the individual. Hence, you are much more likely to be concerned about his or her success on the project. Try it out! You might even snag a new friend in the process.

Stakeholder Inclusion

A completely different approach, which is really just Standard Operating Procedures for an analyst, is to ensure that ALL pertinent stakeholders are present in early discussions. Maximum inclusion in kickoff meetings may draw people in that don’t need to be part of the project, but it also does a couple of other things. First, it allows those individuals to size up the project scope, determine whether or not there is direct impact and HAVE THE OPPORTUNITY to vocalize that there is none/some. Second, it provides the ability for these individuals to opt out while indicating that a more appropriate person should be included. As we all know, having proper and all stakeholders on a project is a key to understanding issues early and completely. Getting the right people in place is critical to making this happen.

Observation

Finally, you as an analyst can use common observation of business or project environments to observe daily processes. This helps to enlighten the analyst as to what is really occurring and to formulate questions that are used as prompts for elicitation of conversation. Often, it is this type of conversation that produces inquiries that lead to issues and their clarification by forcing people involved to think through their own answers.

How would you answer this reader’s question?

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. This is an interesting question, and it uncovers a number of (potentially uncomfortable) truths!

    In some organisations, there might be occasions where projects are initiated based on incorrect assumptions or an incomplete understanding of the problem domain. This can be a real challenge for a BA, as stakeholders can be fairly reluctant for project objectives to be changed or for projects “de-railed”. However, my view is this is one area where we can add significant advantage by asking probing questions and challenging the status quo.

    The root cause of some of these issues is that sometimes sponsors and stakeholders focus too firmly in the solution domain, rather than the problem domain. A text-book example would be

    “We aren’t responding to our complaints quickly enough, so we need a complaints handling system which enforces a strict SLA. I see that XYZ vendor sells a software package, can we initiate a project to install that…. ”

    This is jumping straight into solution mode, and really needs to be challenged at the outset. In this example, a more appropriate question might be “Why are we receiving so many complaints? How can we change our processes, procedures or systems to improve this?”. The *actual* solution might be to re-train staff, or improve a process, rather than purchasing a new system.

    In my experience, the best solutions are generally achieved by having a firm understanding of the problem, and this is something BAs can definitely help with. A great way of approaching this is to start by defining a “problem statement” at the outset. To do this, it is worth actually getting stakeholders together for a workshop and making sure there is a shared understanding of what the project will be resolving.

    Doing this mid-way through a project can be challenging, but having good relationships and building rapport will certainly help!

    Thanks again for a thought-provoking article!

    Adrian.
    (Follow me on Twitter – UKAdrianReed)

  2. Yes! Define the problem/opportunity BEFORE creating the solution! So simple it’s often completely missed. Asking my favorite question, “Why?” helps the analyst help his or her customer in situations like this. As you mention Adrian,
    ….the best solutions are generally achieved by having a firm understanding of the problem….
    and understanding why the problem is a problem and why it occurs helps to clearly define the objectives of resolving it. It is this information that must be in place in order to guide a viable solution creation.

    Thanks so much Adrian!

  3. @DougGtheBA
    Often the question ‘why’ is seen by project managers as ‘a step back’ rather than a step forward. IMHO this is due to the fact that IT projectmgt. is rooting in the waterfall way of looking at organizing projects. So it is literally swimming upstream to ask these questions. I tend to solve these issues by having small projects with fixed deliverables and a PROGRAM organization as a platform to address these issues. But often this PROGRAM organization is seen as overhead in project scope and project teams need to cope themselves. (with all the frustrations of swimming upstream :) )

  4. Pushpak Bhattacharya says:

    This is a very critical point and if we analyse the failed projects, for most of them this is the main reason for failure.

    As per my understanding, there can be two types of overlooked issues – one that is in defining the scope boundary and other is defining the details of the requirement itself.

    Defining the scope:
    The scope definition can be from a problem statement (like there SLA for the trouble tickets are failing) of from a requirement (like we require a new trouble ticket system). As a BA, one should analyse the reason behind the scope itself before jumping into the elicitation process. This will help the BA to understand the real purpose of the project and help to ensure completeness of the process itself.
    Example:
    Case 1: SLA for the trouble tickets are failing. The BA should identify why it is failing before going into any other details. The reasons can be varied like
    1. The number of people assigned to handle the work is lesser than required – This is a easier part where the BA need to see why the number of resources less (attrition?) and try to find out whether it is possible to increase efficiency of the existing resources through training or providing enhanced lesson learned/FAQ allowing them to resolve repetitive problems faster or recruit new resources.
    2. The volume of trouble ticket has increased suddenly – This may indicate a problem somewhere else if the business of the company also has not jumped in a proportional manner. The BA should 1st do an analysis of the TT to see if there is any trend indicating the problem areas for which the TT are being raised. This may tell BA that one there is some problem in the production or other system instead of the TT system.
    3. The system can not handle the volume – The BA should find out the scope of the TT system in terms of the volume it was projected to handle before thinking about anything else.
    Case 2: We require a new Trouble Ticket system. If this is the starting point, then the BA should look into the rational behind this. Based on what parameters a new TT system is required? It can be as varied as
    1. There is no TT system and manual systems are unable to handle TT in a proper manner
    2. The existing TT system has some problem. The BA need to identify the problems to ensure that the problems are not repeated in the new system
    3. Any of the reasons in the case 1 and some one suggested getting a new system. Here the BA has to study and eliminate each of the arguments in favour of using the existing system before proposing a new system.

    Requirement Capturing:
    The second type of error comes when some areas of the scope is missed out. This can be managed using a few techniques like Traceability Matrix, requirement library etc from the BA side. The SOP, Organization Architecture etc documents if available will also help the BA to identify the missing details. This is less of the BA part, more of project management and work management.
    Also, if all the related stakeholders are included in the meeting where the scope is discussed or finding are presented, then they can help in pointing out the missing links.

  5. Isabella says:

    Maybe a bit of “psychology” could help. Questions like:
    “What do you think will happen when …”
    “What do you mean by …”
    “Please define …”
    “What does it lead to …”
    If the parties at the table are fighting each other with words (hopefully), ask the questions round-robin. It may come out that there are different words for the same thought. In that case, build a “Business Terms Glossary”.
    The answers to the questions are what you are looking for, providing hints on the real problem, the parties at the table feel taken seriously.

Comment

*