Simple K2 Requirement Gathering Questions

Here is a list of questions that you would ask business users when gathering requirements to estimate the level of effort to build a K2 process. My first thought is that I like to craft questions that are somewhat technology agnostic such that we can capture the business requirements. We want to avoid boxing the questions specifically to what a tool can so a Use Case can be captured. I do admit it can be difficult to follow every rule for writing effective Use Cases, but just make your best attempt at letting the requirements drive the solution and not letting the technology drive the requirements. Remember K2 processes can to automate more than just SharePoint.

Luckily many of the abstractions within K2 align themselves well with defining a standard business flow definitions. Here is a quick list of questions I would ask to the business users?

• Can a business flow diagram be constructed?
  
  • What are the steps in the business process?
  • What are the decisions a user can make for each step of the process?
  • What role must the user have to make that decision?
  • What stakeholders are there for each decision?
  • What must occur when a decision is made?
  • What should occur when a step is not completed?
  • What are the success criteria for a process to complete? How should a process complete if success criteria cannot be met?
  • What data must be available for a user to make a decision? Are there rules for the visibility of displayed or captured in the business process?
  • Are there rules that affect the routing of the business process?
• What views/dashboards are required to assess that status of the business process?
• What reporting is required for business processes (in flight, completed, user performance, etc.)?
• What is the user experience desired? Where do users go to complete tasks? How should users be notified when a task has been assigned?

Note that:

• Process = K2 Process
  
• Steps = activities/events
  
• Decisions = actions
  
• Roles = K2 roles/groups/destination users
  
• Stakeholders = users or systems that are affected by a decision
  
• Success Criteria/Rules = succeeding or line rules
  
• Data = SmartObjects :-)
  
• Views/Dashboards = task lists (K2, SharePoint, custom), reports (reporting services, etc.), web pages, web parts, etc.

As you can see activities, events, destination users, roles/groups, external systems, SmartObjects, data integration points, escalations, etc. are all captured. Asking questions about reporting will answer questions about whether the data can be stored in K2 or whether it needs to be stored externally.

Some of the questions asked at the end violate the technology agnostic theme I suggested above but it just cannot be avoided. This is not all encompassing but should start you in the right direction.

One thing to take away is how closely K2 is when building your business processes. You can see how the implementation is directly mapped to the business process and less information is lost and not up to as much interpretation.