3.1 Steering Projects Toward Success: Planning

Planning the business analysis effort in a project is crucial and would with no doubt benefit from your involvement. You are likely the most (or one of the most) experienced members on the team, and putting plans is an area where an expert eye can go a long way in defining a strategy or spotting potential problems. Therefore, it is going to be especially valuable if you support your team members in planning their business analysis effort in a project. Most of us appreciate the availability of another mind to brainstorm with, especially at a time when we know so little about what lies ahead. Your input will give them confidence if they are heading the right direction.

Consider the following factors:

1. Your involvement in the planning phase will help you assess the analyst’s strategic thinking skills. This is important information to make future decisions about the level of autonomy you can grant them in the future, to promote them to more senior levels, or to assign them to more complex projects.
2. Later as the project proceeds, you may need to steer the project back towards the original plan, or identify areas where the plan itself should change. Having been involved in planning will help you better see the picture.
3. Assuming you treat the plan as a living artifact, not as a one-time artifact used once and forgotten later, understanding the plan will help you assess which decisions made sense, and which did not serve their purpose as originally perceived, and compile the lessons learned for future projects.

How to Plan?

1) Assign the Suitable Resources

The first step is to decide which resources should be allocated to the project. How many resources are needed. Who is both available and has the right skills, abilities, and culture fit? Analysts will need to build a rapport with the client and the team, this would be a lot easier if they are a good match. Do they need to travel? Do they have enough experience?

Good resources allocation takes many factors in consideration including the following:

• Client and stakeholders nature and complexity: If this is a particularly challenging client, you might need to assign a more senior or diplomatic analyst. What about the solution team? Is there an analyst who will better fit with them?
• Business domain or technology knowledge: Do they need to be versed in a certain technology or domain?
• Project complexity: Complex projects need more senior or skilled analysts. Complexity may be caused by a project’s high-sensitivity nature, unfamiliar technology, number and dynamics of stakeholders, to name a few.
• Location, language, and communication methods of stakeholders. Do the stakeholders speak a foreign language? Do you have an analyst who speaks that language? Do they need a more (or less) formal approach? Is the analyst to be assigned more skilled at one more than the other?
• Experience with similar projects. Do you have an analyst who worked on a similar project in the past. This could be a reason to assign them to the project, or not. Perhaps, you like to diversify your team experience, and ensure you do not eventually depend on any one person for a particular type of projects.

2) Assess project readiness for requirements activities to start

Once you have the analyst assigned to the project, the first thing you want them to note is whether or not the stage is set, the ground they are embarking from should be understood and ready to support their first steps. Think with them about the following:

1. Are the right stakeholders identified and accessible? Are they ready to get involved in requirements activities? Do we have their commitment? Do they have the needed information?

You want the analyst to coordinate with the project manager to make that preparation. If needed, use your position to demand and facilitate access to the stakeholders. This is one of the privileges you have as a team leader, you have that authority; and as someone who does not directly working on the project, there is less chance there is conflict or sensitivity with the team members (hopefully).

2. Is the scope well-defined and agreed on by the different stakeholders? Undefined scope can lead to frustration and re-work once requirements work begins. Do not wait for this to occur, if the scope is not well-defined, address the issue first, direct the analyst to focus on filling the scope gaps before diving into details.
3. Be attentive to signs of trouble. Examples:

Questionable Strategic Alignment: Projects started by IT without a clear business drive can be tricky. Try to understand why are we doing this project? What is the business value?

Inadequate Focus on Business: Project starts to fulfill a need but business drive stops there. Ask:Did we involve the right business stakeholders? Are the developers aware of the business context and industry standards?

Poor Requirements: Ask: Is what needs to be done clear? Do we understand the entire process? Is the scope clear?

3) Work with the analyst on creating a requirements plan

Let them prepare something first

The previous steps were mostly of a preparatory nature, now you get to the core of your work.

• Think about the analyst involvement throughout the lifecycle. Cater for some left-over work after sign off.
• Brainstorm with the analyst to define a roadmap with the analyst: Include the activities that seem more fitting for the project and the stakeholder at hand. What artifacts they will need? Do they need a Risks Sheet, a template, a… the deliverables that should be promised, the time estimation (this is particularly important because inexperienced analysts find it especially difficult to make estimates).
• Use historical data and best practices to come up with ideas.
• Tailor your approach to project nature and lifecycle. For example: Sensitive high profile, or agile projects.
• Review the order of objectives of the requirements discovery activities. This is another particularly important point.
• If needed, help the analyst schedule their appointments with the client or other team members.

4) Obtain commitment from the analyst, project manager, and stakeholders

Possibly have separate meetings with clients and other stakeholders such as PMs to educate them on the process, such as the analyst need to separate appointments to allow time for analysis and documentation.

Finally, motivate the analyst and assure them of support!

Working in Agile Environment?

Planning is still an important … It will only mean that you will have to divide the plan on smaller pieces, and sit with the analyst more often.