Early BA Engagement: “Earning” Pre-Project Work
Last updated: February 02, 2024 Read in fullscreen view
Recommended for you
- 18 Oct 2020
How to use the "Knowns" and "Unknowns" technique to manage assumptions 21/989 - 01 Oct 2020 Fail fast, learn faster with Agile methodology 13/973
- 10 Nov 2022 Poor Code Indicators and How to Improve Your Code? 7/213
- 19 Oct 2021 Is gold plating good or bad in project management? 7/754
- 06 Feb 2021 Why fail fast and learn fast? 6/375
- 01 Mar 2023 Bug Prioritization - What are the 5 levels of priority? 6/207
- 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M) 4/789
- 11 Jul 2022 Cost benefit analysis for software development 4/662
- 08 Oct 2022 KPI - The New Leadership 3/557
- 31 Oct 2021 Tips to Fail Fast With Outsourcing 3/375
- 18 Aug 2022 What are the consequences of poor requirements with software development projects? 3/242
- 10 Dec 2023 Pain points of User Acceptance Testing (UAT) 2/416
- 13 Dec 2020 Move fast, fail fast, fail-safe 2/292
- 17 Jun 2021 What is IT-business alignment? 2/343
- 23 Sep 2021 INFOGRAPHIC: Top 9 Software Outsourcing Mistakes 2/411
- 17 Feb 2022 Prioritizing Software Requirements with Kano Analysis 2/280
- 28 Dec 2021 8 types of pricing models in software development outsourcing 2/417
- 19 Apr 2021 7 Most Common Time-Wasters For Software Development 1/525
- 26 Dec 2023 Improving Meeting Effectiveness Through the Six Thinking Hats 1/205
- 05 Jan 2024 Easy ASANA tips & tricks for you and your team 1/180
- 11 Jan 2024 What are the Benefits and Limitations of Augmented Intelligence? 1/434
- 14 Mar 2024 Why should you opt for software localization from a professional agency? /117
- 12 Mar 2024 How do you create FOMO in software prospects? /127
- 06 Nov 2019 How to Access Software Project Size? /236
I suspect most people reading this article would agree that business analysis is hugely valuable throughout the business change lifecycle.
Whilst some stakeholders might perceive business analysis as primarily being related to the definition of ‘requirements’, the reality is that the discipline is much, much wider than this. As well as being involved in the important detail of defining requirements, there is much valuable BA work to be done before the project starts.
One of the most effective ways to ensure that projects achieve the outcomes stakeholders expect is to use proven project management techniques when planning projects. Pre-project planning is mostly used for large projects. In doing so, it lists two reasons for integrating planning into pre-project activities and describes the significance of using a project implementation plan (PIP) to ensure that the deliverable coincides with the owner's objectives and expectations.
In fact, in my experience it is often the embryonic ‘pre-project’ phase where initiatives start to show problems and start to go off the rails. It is very easy for stakeholders to push ahead without a full understanding of the problem or opportunity that they are looking to address, often being blindsided by a solution that looks so perfect! Of course, without having undertaken sufficient analysis we’ll be unable to determine whether that expensive and shiny solution will actually achieve the outcomes that the stakeholders desire. We risk getting caught up in the perfect storm where a project becomes about delivering a particular solution or IT system rather than focusing on achieving a set of business outcomes.
Pre-project problem analysis is a crucial discipline to help avoid these situations occurring, and there are a range of useful tools in our toolkit to enable us to engage with, and understand, ‘messy’ problem situations. From rich pictures, to multiple cause diagrams, fishbone diagrams and many, many, more—we can work with stakeholders to understand root causes prior to shortlisting potential solution options. This work needn’t slow things down—in fact, if it is done well it is often an excellent way of clarifying scope so that the detailed work can accelerate off on the right track (as opposed to stalling at the start line).
Of course saying pre-project problem analysis is useful is one thing, getting the remit to actually do it is quite another. This can be exacerbated by organizational structures and processes that do not necessarily (yet) recognize the value of early BA engagement. However, if there is one thing about us BAs, we are very tenacious! Given the right tools and forethought no brick wall is completely insurmountable.
Earning The Right
One relevant expression that I’ve heard some practitioners say is “credibility comes through delivery”. This succinct statement is at the root of our early engagement challenge—if people haven’t seen the benefit of having a BA engaged up-front, then why should they believe it? This creates a ‘chicken-and-egg’ scenario—without up-front engagement, we can’t prove its value. Without proving its value, we can’t get the engagement. However, with some stakeholder rapport and some selective risk-taking, this is a situation that we can build upon.
Firstly, it’s really important that we get our foot in the door during those early discussions. One way of approaching this is to put ourselves in our stakeholders’ shoes: Ask “what would worry me?”, and “what type of service would help me?”. Often, executive stakeholders are busy, and they’ll find meetings a real bind (they might even have a mug which says ‘I survived another meeting that should have been an e-mail!’). This is one area where analysts can really help: We can offer facilitation as a service for their ideation and strategic meetings. Imagine this from the stakeholders’ perspective: They get an expert facilitator who lightens the load, works with them to come up with a compelling agenda and brings a ‘scribe’ along to write up the output of the session. They get a high quality meeting output with very little outlay. From our perspective, we get to use our facilitation skills (which, let’s face it, is really fun), but more importantly we are there when early pre-project discussions are being had. We can introduce a range of techniques throughout the workshop to encourage both ‘divergent’ as well as ‘convergent’ thinking so that there isn’t an early fixation on a single solution.
If the initiative goes ahead, we then have the relationships with the key stakeholders and we’re the natural change partners to help our stakeholders accelerate forward. We’ve shown them the value of utilizing BA skills in a single meeting—if we’ve ‘wowed’ them there, imagine what we can do in a whole project. Over time, the reputation of the BA team will grow internally and more and more people will see the benefit, and early engagement will eventually become the norm.
Of course, this is a long-term game, but it can start with a single conversation and a single meeting. And it’s well worth while considering!
Explore more on these topics
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!
Recently Updated News