Hello,
Picture a large CRM project which envolves IT and process reigeneering. A bunch of business analysts and another bunch of business process analysts. What do you tackle first ? Requirements or Processes ? Which one feeds the other ? Also, BA and BPA want to get information form the same user community. Is combined workshops (requirement elicitation and process analysis and documentation) the solution ?
I would greatly appreciate any thoughts or experiences on this.
JM
jmessih wrote A bunch of business analysts and another bunch of business process analysts. What do you tackle first ? Requirements or Processes ? Which one feeds the other ? Also, BA and BPA want to get information form the same user community. Is combined workshops (requirement elicitation and process analysis and documentation) the solution ?
A bunch of business analysts and another bunch of business process analysts. What do you tackle first ? Requirements or Processes ? Which one feeds the other ? Also, BA and BPA want to get information form the same user community. Is combined workshops (requirement elicitation and process analysis and documentation) the solution ?
Wow... it sounds like a project with a role identity crises.
I think I've mentioned this in a recent post but a BPA (Business Process Analyst) is a BA (Business Analyst).
So... regardless of the title, everybody needs to be on the same page as to the goals and vision of the project. The business has decided to spend lots of $$$ to achieve some result or to solve a problem - make sure everybody is on the same page as to what that is since, on the same project, the BA & BPA should have the same goal - perhaps slightly different responsibilities. How is going to do what and in what order will depend on the type of project, the goals, the current state, stakeholder availability, etc.
Here are some thoughts (I'm assuming that the BA vs. BPA distinction must stay in your project - even though I'm not so sure):
- Adrian
I agree with Adrian's thoughts - this needs to be a coordinated effort between all pre-development personnel. Also don't jump to conclusions about what needs to be business process change versus system requirements.
In general I see the process for such an endeavour as follows:
JM,
My take on this is:
1) Requirements come first. Why? Because process (or behaviour) is governed by requirements. This point is made by Fowler (of UML distilled fame) in his earlier works and its still true today!
2) BPA normally wants to know HOW things work, so that the process can be "improved" etc. BPAs can sometimes focus too much on solution; which is akin to design. BPAs can get you into serious trouble as its gives you an SMEs perspective of how, he or she for example process an invoice. Process improvement falls into the design category, which is a HOW.
3) The BA wants to know WHAT processes are required. If you have time consult Yourdon's essential modelling technique - those of us familiar with DFDs know this intuitively. However, have a read of the first few sentences at http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_17#THE_ESSENTIAL_MODEL. How to get from HOW to WHAT.
All the best JM
warm regards,
K
My thoughts:
How can the BAs gather requirements if they have not identified a process for gathering those requirements?
My answer is process first,
then requirements,
then more process,
etc ..
then the final requirements.
I do not see any point in defining process after all the requirements have been documented.
Leslie.
brought to you by enabling practitioners & organizations to achieve their goals using: