10 reasons for using Business Analysts at the early stages of a project or pre-project

By | 18/02/2018

There are many reasons why Business Analyst involvement doesn’t happen until much later on in a project.  Examples are:

  • The business often feels they can sort out the early stages on their own.
  • Not enough known about how a business analyst can help.
  • There isn’t the money to fund the resource if additional cost.
  • Not always possible to get business analysis involvement early on particularly as there is often a waiting time before resource can be allocated.

There are many reasons why there is value in engaging business analysis before project initiation and at the early stages.  The early stages are one of the most important stages as if the project is built on poor foundations it is likely to fail encountering common issues such as scope creep, solutions that do not meet business needs, project rework and user resistance.

The accountability of the Business Analyst which adds value are the following:

  1. Ensure the root cause of the problem or opportunities are understood.
  2. Facilitate a consensus on the required scope and possible phases.
  3. Ensure the objectives are agreed and relate back to the scope and problems / opportunities identified.
  4. Identify the business needs. Business needs may require more than just technological solutions.  This is a reason why a mature business practice will not tend to be part of an IT department because Business Analysts are valuable for all types of change.  This avoids the problem around IT delivering a solution which then doesn’t resolve the bigger picture.
  5. Ability to take unstructured information from stakeholders and organise the information into concrete specifications which break the project down and group the needs into areas which can be managed more easily, ensures everyone has a common understanding and consensus.
  6. Not being restricted to IT solutions and having an understanding of the problems, objectives and needs will enable the business analyst to help identify a range of solutions and evaluate them. They will have a complete vision of the solution taking into account people, processes and technology.
  7. Continuity through the whole project ensuring traceability to design and delivery are in line with the original aims and problems / opportunities identified. It will be an easier transition for Business Analyst involvement through less handovers and reduced risks of rework if involved from the beginning.
  8. Will represent the business but will be closer to what is being designed and the additional detail required. They will be able to ensure the business has a voice throughout the project life cycle.   They will help to ensure firms do not spend time and money on projects which do not meet business needs.
  9. The project managers role focuses on getting the project delivered on time, the business analyst role helps ensure the business will be able to live with the solution being implemented and that it will meet their needs. The business analyst therefore needs to ensure they have a strong understanding of the objectives from the beginning.
  10. Will ensure quality, by capturing non-functional requirements early on along with success criteria. This will make it easier to measure the project’s success and ensure the solution is built to meet what is required.  Non-functional requirements can have a big impact on cost and solution so getting agreement between the parties involved is essential.  See What are Non Functional requirements, why they are important and common mishaps (part 1) for further information.

Traditionally Business analysts have added value supporting a project and defining the lower level requirements.  This article aims to set out the value that can be added by early engagement.  In summary their involvement can set out the problem / opportunity statement, indicative scope, business needs, success measures and potential solution options.  These can all contribute to the business case to ensure the project sets out in the right direction from the start.

Thoughts? Questions? Please share in the comments.

Author: Helen Winter

An Management Consultant responsible for structuring programmes, success criteria, mobilisation, management of scope, budget, timely delivery, benefits realisation and stakeholder satisfaction. Helen has led on large transformation programmes to execute delivery along with strategic business outcomes. Helen is also a global business author with publisher Kogan Page where her first book “The Business Analysis Handbook” was a finalist for 2 major industry awards. One was for contribution to project management literature with PMI and the other was the Specialist book category for the business books awards. She is an active member of the APM programme management group. She is currently involved in a focus group sharing examples of good programme management practice and is an established speaker for project management forums. In her free time, she loves sharing her knowledge on her blog BusinessBullet.co.uk which is followed by over 5000 visitors a month.

5 thoughts on “10 reasons for using Business Analysts at the early stages of a project or pre-project

  1. Richard Clough

    Really good article Helen. I’ve often had to come in late and drag the business back through why they are doing this in the first place. Can be very rewarding but soooooooooo frustrating.

    Reply
    1. Helen Winter Post author

      Thanks for your comments. It’s also good to hear about other peoples experiences. I know exactly what you mean rewarding but frustrating.

      Reply
  2. Gaurav

    I totally agree with the points mentioned by Helen. Making developer or programmers understand the requirement of a client at the early stages helps in smooth functioning of project. I also helps developer get better understanding of what the clients want. Saves a lot of rework for everyone.

    Reply
  3. Ajij Henderson

    Helen –

    I like your articles, I morphed from a QA Analyst to Business Analyst and I have discovered if you don’t involve the BA upfront the developer designs things that are incomplete, then when it comes to QA the wheels come off. They are forever sending different versions of a rollout (“ATT-MSRH-0091A-Z) trying to get the solution right.

    Reply
    1. Helen Winter Post author

      Hi Ajij,
      That’s a great practical example. Thanks for sharing.
      Regards,
      Helen

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.