Project size is a big factor in determining what tasks you undertake as a business analyst and how long you take to complete them. Factors to consider are the number of features you need to deliver, the number of people you’ll interact with, and the number of people that will use the solution. Eliciting requirements from 1 stakeholder is less time-consuming eliciting than from 50.
How to handle small projects as a business analyst
These typically are much smaller in scope and may even be considered maintenance projects, or tickets (enhancement requests entered into a tracking system). Typically, they have a minimal amount of risk and exhibit the following characteristics:
They require small amounts of effort, low cost, and touch only one or two systems. This limited reach makes the scope small.
They involve a minimal number of people — sometimes just a developer and the business analyst — and don’t have many interfaces with other systems.
They’re generally maintenance projects, designed to enhance an existing system, rather than implementations of new systems to support a business process.
When you plan for a small project, you don’t need to produce the same number of deliverables (or level of effort) as you do for a large project, but that doesn’t mean you don’t have to make sure you’re addressing the right business problem with your plan.
Small projects can be motivating because you can see results in a fairly short time, but you can’t skip critical steps in the planning process.
When planning for small projects, consider these aspects:
You may participate in both formal and informal processes, communication, and deliverables. Some really small projects are often discussed in a hallway or drawn out on someone’s whiteboard.
Even (or perhaps, especially) on a small project, you still need to understand the scope. Without an understanding of the boundaries of the project, you can get distracted, off track, and lost in various streams of the work effort quickly.
Defining scope is the most critical step, even for simple requests. If you don’t understand the scope, you may opt for what appears to be an easy and obvious solution, rather than the right solution.
You must establish a clear purpose and objective. Doing so ensure that you’re spending the organization’s (probably very limited) resources in the right place.
How to tackle large projects as a business analyst
Large projects are sometimes referred to as monster projects. They typically have high business risk because more is at stake. If the projects fail, the business can lose a significant amount of money and/or lose out on an opportunity. Large projects exhibit the following characteristics:
They require large amounts of effort, have a high cost and large scope, and last a long time.
They involve lots of people.
They can contain features with many dependencies — that is, one feature may be linked to others, meaning a change to it results in a change in many.
They’re mission-critical.
They’re complex.
Planning for monster projects is usually formal and may involve significant resources. New development efforts also have a high technical risk because the enabling technology may be unfamiliar to the business and internal IT resources or have complex system interfaces. These development efforts need the following from you:
Formality in process, communication, and deliverables
Full discussion of the project with stakeholders, regardless of type
Adequate time to formally plan the project with the project manager, an established methodology to guide planning tasks and deliverables, and collaboration with a lead IT/developer in the planning of the effort
A clear purpose and objectives to define the scope and clear communication of scope boundaries to all stakeholders
Break the scope into multiple smaller projects that can each deliver business value and be more manageable to reduce risk, rework, and costs and to capitalize on lessons learned.
A feasibility study (a study undertaken to uncover the strengths and weaknesses of the project, the environmental opportunities and threats the project poses, the resources required to create the project, and the project’s success criteria) and prototype
Thorough investigation of the business problem or opportunity and completion of all requirements categories (business, functional, transition, and so on)
Thorough stakeholder analysis and communication plans