Project Initiation

There is a common antipattern which states that analysis is strictly an initial project phase. Although it can be structured that way, it can also be the other way around. Analysis can be carried out independently of any project and, what is more, it can even serve as the trigger for a new project altogether.

Scenario #1

A project may start immediately after a business problem has been identified. For example, if a bank must implement a new regulatory requirement, there is usually no dedicated department to drive the implementation. Even though a specific department (such as Compliance) is responsible for ensuring that all regulatory requirements are met, they only understand what the bank must do to comply with the law. They generally have no idea what impacts it will have on people, processes, or systems.

This is a frequent scenario in large enterprises where numerous business changes with significant impacts are constantly underway. Such changes require an extra initial phase to thoroughly understand the problem and map the current state. In this case, the project is launched right at the beginning with the explicit aim of finding the best solution and implementing it.

Scenario #2

Following the previous example, a regulatory requirement can also be pre-analyzed by a business analyst outside of any project context first. The actual project would then only be launched after a specific solution has been selected. Consequently, the project itself is responsible solely for delivering the chosen solution, not for identifying it in the first place.

Scenario #3

In some cases, there is no overarching project to deliver the entire solution. Instead, there are only smaller sub-projects tasked with implementing individual solution components. As a result, each sub-project performs its own solution analysis, and these projects can be executed either in-house or outsourced to external vendors.