3.6 Steering Projects Toward Success: Large Projects

Large projects can benefit from the involvement of more than one analyst. Orchestrating the efforts of many analysts and consolidating their work to produce coherent effective results require some additional considerations to pay attention to.

What is a Large Project?

Projects can be classified as large projects based on different factors. The most obvious is the number of man days involved. A project over a year (or even more than six months in tight scheduled projects) are considered large projects. A project can be also considered large if the number of processes, affected organization units, systems, or stakeholders is significantly larger than the usual projects that the team usually assumes. A project that involves more than one domain (for example, a project that combines telecommunications services in a governmental environment, or banking services combined with real estate projects. Even a sensitive project that involves high public exposure can be considered a large project.

In such projects, it is sensible to consider involving more than one analyst. Sharing the responsibilities can have multiple benefits:

1. It reduces the load of work and stress on one person. As a team, analysts can draw value from thinking together and capitalize on other members diverse viewpoints, insights, and ideas.
2. It is a cautionary measure in case one analyst leaves or runs in emergencies. In large projects, onboarding new members midway may not be an easy task, considering the load information they will have to consume quickly and the politics that may be involved. The presence of another analyst who understands what is going on and can take over quickly can mitigate that risk.

When you make a decision on how many analysts to involve, make sure the lines of division between the work of each of them are clearly drawn. Consider what is an optimal number of resources for the project, more is not always better. Sometimes, too many people get in each other’s ways. Coordination between their efforts and consolidation of their outputs become an unnecessary overhead that defeats the whole purpose of sharing to optimize.

You also have to think how they can be divided. There are a few ways to do that:

• One common way is to divide them by user groups. Each analyst is responsible for the requirements of a set of users that share similar needs of the system. For example, an analyst covers the fraud department requirements, and another assumes the responsibility of the tellers’ team.
• Another possible line to divide along is the systems modules, related sets of functions, or process groups. For example, one analyst takes over everything related to order management or calendar management, while another focuses on profile management or reporting.
• Perhaps you like to put the more senior analysts in contact with the customer executives or in the more complex parts.

You will have to experiment and see what works best for your team. Many factors can affect your decision, such as the analyst’s skills or domain knowledge, the type and number of stakeholders they will deal with.

A word of caution: Without defining the complete high-level requirements, it may be challenging to make sound decisions about the divisions or even to make judgment about the work progress. You need this high-level requirements phase to have a zoomed-out map, so you can understand where the work stands, and how it fits with other components. You then have to divide work and responsibilities along the components.

The next few paragraphs outline specific activities that you can do to steer the project to success. I will divide the activities that you can use to run this orchestration in three parts: Project beginning, execution, and closing.

At Project Beginning

1. Before anything, all assigned analysts must meet with you and each other to understand the plan. In this meeting, you should cover two areas:
   1. The available information about the project: Stakeholders, business objectives, whatever requirements already known to the team, documentation, and any other element that can help them learn about the project itself.
   2. The execution plan: Who is doing what, how each of them fits in the bigger picture, how to seek or provide information as they go. If you cannot come up with all this information from the start, focus on the next step, and plan for more meetings until the picture is clear. Encourage them to ask any questions they might have before they start.

Tips:

• Communicate structure and responsibilities clearly and transparently to ensure everyone knows the boundaries of their responsibilities to avoid duplicate work and frustrations. Let the team share its views and give input in the decision. They might have more information about the project, or even personal preferences. It is fine to accommodate their personal preferences to a reasonable extend, as long as it is not unfair to some of the team. Compromises will have to be made. Keep your eye on the soundness of the distribution as the project moves along. See if the division is serving the project or causing issues. If the latter happens, you will have to rethink the responsibilities distribution without causing too much disturbance to the project, the team, or the client.
• If you sense that a couple of analysts do not seem to get along very well, try to assign them to areas that do not heavily overlap.
• In your plan, allow time for peer review. It will help avoid overlaps or conflicts, and help find intersections. It is important to allow them to see each other’s work and spot any conflicts or duplications, or benefit from each other work. They might see requirements coming from another team or in another set of functionality that can be beneficial for their own stakeholders or area. They can take this information and discuss with their stakeholders, add to it, or raise a flag if it is not acceptable to their stakeholders.

During Requirements Elicitation, Analysis, and Communication 

The most important point during the execution phase is to make sure everybody shares one complete view of the project, that everybody is on the same page. There are a number of useful methods to do that. Consider the following:

1. A shared knowledge management tool, such as a requirements management tool, is an excellent way to guarantee everybody has an up-to-date view of what is going on. The more robust the tool is, the more benefit you derive.
2. Conduct regular (typically weekly) one-on-ones and group meetings with the team, when needed.
3. Be yourself or appoint someone who is responsible for coordination. This person will have to look into deliverables, compares them, point out commonalities and inconsistencies, and draws synergies.
4. In addition to that coordinator, let the team audits itself. Get the team members commitment on peer review and ensure it is happening.
5. At major clients’ demos or walkthroughs, involve all the team, not just the analyst assigned on the part being demoed. 
6. Setting clear milestones and reviewing where things stand, and if there is a need to revise the strategy or make changes is obviously a good practice in large projects. The project as a whole will most likely have its own milestones. You can use those to set your sub-checkpoints or set your own separate checkpoints specifically for the business analysis component. One straightforward checkpoint is when the high-level requirements part is complete (assuming you do split the analysis work into high-level and detailed-level phases. Refer to the Requirements Development Guidebook to learn how you can make that distinction). This checkpoint is, however, not enough. During the detailed-level requirements phase,
7. Finally, understand and accept that every team member will get carried away with their day-to-day tasks; and that it will be your responsibility to ensure that coordination and consistency are maintained.

After Sign off/development start

Some projects are complex or high-stake enough to warrant the allocation of all the analysts beginning to end. It is not always the case however. If one analyst can manage the requirements, you can re-allocate team members to other projects, and keep one person on the project to own the requirements. S/he she can consult others when needed.

There is a chance that this one person may not be able to do the complete UAT activities, so make sure the others time allocation caters for that task.

Finally, your Involvement:

Plan for some extra overhead on your schedule to coordinate the work of the team, mitigate risks that may come up due to conflicts or efforts duplication. Orchestration of efforts in projects that involve more than one analyst is vital. You want to make sure personal conflicts or frustrations are minimized or to the least managed.

You could also get involved personally. It is not a bad thing for you to stay hands-on and practice the work first-hand every now and then. Large or complex projects are a good opportunity for you to do that. If you can not do the whole project on your own, think about partial involvement.