Hi Craig,

Interesting question - can you give a little more context?  What is the goal of the project?  Is this an 'IT driven' project that has already defined that a computer solution is required?  Or is this a 'Business driven' project that has a stated problem with some thoughts given to possible solution but the sponsors don't have set in their mind what needs to be done.

If your sponsors already believe that a 'system' must solve the problem, then understanding the current process is important but not as crucial to document and analyze.  By that I mean as a BA you'll become familiar with the process as you develop requirements around the system, but you may not explicitly document processes or think about them too deeply beyond how they translate into features and screens that are desired  by the client.

If you have an open minded steering group then in my opinion performing business process analysis prior to solution analysis is essential.  As a BA I would not suppose that an IT solution is required in every case.  I need to understand what's going on now, what problems the clients have with current state and what their needs are.  I would then use the documented processes to look for process re-engineering opportunities, which may or may not be dependent on the implementation of a IT solution to arrive at future state.

Hi guys

In my example presume we are moving to a new system and along the way replacing some old legacy systems and plugging in a bunch of manual or spreadsheet/outlook workarounds.

This is a fairly common scenario, don't you think?

A particular interst I have is how do you manage the need to turn things arund quickly - to be seen to be doing something - and to minimise delivery risk.