Project Objective section, Terms of Reference (slide 5)
To provide a feasibility report that documents:
- a high level view of the required system processes
- a high level view of the required system data
- the phasing of delivery of IT system functionality and changed business processes
..that will incrementally improve the efficiency of operational processes and provide them with the IT systems support needed. It will do so in a manner that minimises the impact on the ability of operations to meet their present sales targets.
At the end of this feasibility study it is expected that a full study will be carried out for the selected Business System Option, as approved by the Board. Approval will mark the start of the next stage, to take the project through to implementation via a number of sub-projects, sequence to be determined, controlling each incremental business change.
For Agile advocates, note the following.
A wide-reaching business change project is far more than just the software and workflow that Agile excels at. It's extremely risky, almost to the point of certainty, that if you run a big project using the Agile discipline you'll come unstuck. You have to have the big picture before picking away at the problem piecemeal.
That's not to say you can't be 'agile' (with a lower case 'a') in your approach as a business analyst.
That's what I've opened the door to in this case study. Notice the wording about incrementally phasing in the changed processes and IT support.
Having the big picture from the Feasibility Study work makes it easy to deep dive the area of the business that is to change each time, without adversely affecting the others.
You'll need to have a high level logical solution architecture to guide you in this, though. That's so you can see dependencies, spot synergies and compartmentalize. If your solution provider is internal, involve a solution architect to get one. If not, you'll have to create one yourself (because an external solution provider won't have been selected yet).