When Project Objectives Don’t Yet Look Like Work
Part 2 of a 3-part series on the Lead Analyst role
In the first article in this series, Nicole Chapellaz explored the transition from Business Analyst to Lead Analyst and the role that Lead Analysts often play alongside Project Managers at the start of a project.
One of the first challenges that a Lead Analyst faces is translating high level project objectives into work the team can actually deliver.
Most projects begin with documents that describe what the organization hopes to achieve. A business case may outline goals. An RFP might describe the capabilities a new system should provide. Stakeholders often have a clear vision of the outcome they want to see.
What those documents rarely contain is a clear picture of the work required to reach that outcome.
Within Paradigm’s Business Analysis practice, analysts frequently encounter projects where the intended destination is known, but the path to get there has not yet been mapped. This is where the Lead Analyst begins to play an important role.
The first step is not writing detailed requirements. Instead, the Lead Analyst works with the project team to begin understanding the shape of the work ahead.
This often starts with reviewing the documentation that already exists for the initiative. Business cases, RFP responses, initiative briefs, and project charters all provide clues about what the organization is trying to accomplish. These documents rarely contain everything the team needs, but they help establish an initial view of the problem the project is trying to solve.
Conversations with stakeholders and subject matter experts quickly follow. These discussions help clarify business goals, identify major capabilities the solution will need to support, and uncover assumptions that may not be obvious from written documentation.
At this stage, the goal is not to produce detailed specifications. Instead, the Lead Analyst is looking for ways to organize the work into logical pieces that the project team can begin planning around.
From Paradigm’s experience, this often involves identifying high level work packages that represent major areas of functionality or capability. Some of these pieces of work can be identified quickly. Others require additional conversations with architects, developers, or subject matter experts before the team can fully understand what is involved.
Once this initial structure begins to emerge, the project team can start addressing another question that inevitably arises early in a project: how long will this work take?
Estimation at this stage is rarely precise. Early estimates are often based on limited information and will evolve as the project progresses. However, they still serve an important purpose.
Project Managers need early estimates to begin planning schedules, identifying dependencies, and understanding the scale of the effort required. Even rough estimates allow the team to start shaping a realistic delivery plan.
Lead Analysts often facilitate this estimation process because they have the clearest view of the work breakdown that has been developed. They can walk the team through the work packages that have been identified and provide context gathered during the preliminary analysis.
These discussions typically involve several members of the project team. Developers, architects, quality assurance specialists, and analysts all contribute perspectives that help refine the estimates.
As the work becomes clearer, another planning activity begins to take shape: determining what analyst resources will be needed.
This is where the Lead Analyst must think beyond individual task estimates. Planning analyst work requires understanding how different work packages will progress over time, which activities can occur in parallel, and when analysts will transition from analysis work to supporting development or testing activities.
In many projects, analysts complete their initial requirements work and then continue supporting the team by clarifying requirements, assisting with testing, or helping resolve issues as development progresses.
Thinking about these transitions early helps ensure the right number of analysts are assigned to the project and that work can move forward without unnecessary delays.
By the end of this early planning phase, the project team usually has something they did not have at the beginning of the initiative: a clearer view of the work required to achieve the project’s objectives.
The work will continue to evolve as the project moves forward, but the team now has a structure that allows planning, coordination, and delivery to begin.
Once that structure is in place and analysts have been assigned to the work, the focus of the Lead Analyst role begins to shift again. Instead of defining the work, the Lead Analyst becomes responsible for supporting the analysts who are delivering it.
In the final article in this series, Nicole will explore how Lead Analysts mentor analyst teams, monitor progress across multiple work streams, and support Project Managers as projects move from planning into delivery.
Paradigm’s Business Analysis practice includes experienced analysts and lead analysts who support organizations across Canada in bringing structure and clarity to complex initiatives. If you would like to learn more about Paradigm’s Business Analysis practice, connect with the Paradigm team.