At bpmCamp we had a great session on BPM Requirements led by Zelda Durden.? Often the answer to the question "How much is enough?" is "I know it when I see it" - but we wanted to go deeper, and Zelda offered to help shape the discussion. How can we tee things up so that we know how much is enough as part of our requirements process?
She broke things up into two phases for consideration:
- Exploring - no budget approved yet, no Project Manager either.
- Strategy - what needs to be improved from 50,000 feet, and what are the business priorities and goals.
- People - who and how much commitment from the business?
- Process- scope, SIPOC
- System - What is the current system?? Current state of the process?
- getting people commitments is difficult at this stage
- using this information to help prioritize projects - along with ROI and other tools
- scope management is difficult once users see what is possible.
- Discovery - a real project is on the books, with budget.
- Strategy - Critical Success Factors (CSFs), ROI calculations if necessary, alignment with corporate objectives
- People - current skill set of process users versus new required skill set?? Change management: figure out the influential people and engage with them.
- Process - full process audit/investigation.
- System - plan for legacy systems, determine the extent of Teamworks (BPMS) in the solution.
- Development Starts
First playback drives a lot of requirements changes.? Not planning for that level of change is just kidding yourself.
- Iterative development - iterations range from 3 weeks to quarterly - which keeps the lifespan of requirements to some reasonable level.
- Initial "onboarding" of process focussed on keeping it very simple (no integrations, or as few as possible) - get the process right first.
- Best process information comes from the end users - have to get in front of them and get feedback.
- Blueprint could be used for initial process modeling / analysis - but has the disadvantage of forcing you to consider licensing issues (unless you have a site license, etc. )
- Some people don't get flowcharts: figure out the tools that work to communicate with them.? Draw on the whiteboard, for example.
- Teamworks as a process document repository (even for processes that are never intended to be TW apps).? While this isn't the primary use of Teamworks, there was general support for this idea.
- "BPM Document" like a mini-BRD
- BRD still developed for interfaces / web services, etc
- Plan to develop process for project selection/kickoff
There was much more discussion than what we've captured here - but that is the nature of these things - you get into the conversation and you forget to take notes!? A few related thoughts come to mind for me, which I'll share here.? Our CEO, Lance Gibbs, has some great common sense yardsticks that he often communicates to people on BPM projects who aren't familiar with how to think of requirements:
- Does it affect ROI?
- Does it impact business objectives?
- Does it impact customer service?
- Does it impact throughput?
- Does it impact quality in a measurable way?
You can think of similar questions.? If a requirement doesn't address any of these concerns, it should probably go in a secondary bucket to "come back to later" after you've first dealt with requirements that DO affect these criteria.
We applied a similar approach to documentation:
- Does it reduce work?
- Does it reduce waste?
- Does it reduce risk?
- Is it required for regulatory or other legal reasons?
It turns out we as an industry turn out a lot of doc that does none of these things.
More to come from bpmCamp 2010 @ Stanford...