Wednesday, January 28, 2015

How to Design and Develop a Smarter Workflow

This blog is the first in a four part series about how to make smarter, better, faster, and stronger workflows. Each post will focus on a certain area. In this post, it's how to be smarter with your workflows.

How many times have you sat down to develop a workflow, where it's described to you like this:

clip_image001

But in actuality it's really this:

image

The second image is what I call "requirement surprise." To avoid requirement surprise, you need to be smarter about your workflows. And to be smarter, you need to ask the right questions. This post goes through some of the questions that you should ask when gathering workflow requirements.

For clarity going forward, I'm going to refer to who you're developing the workflow for as the client.

When gathering requirements there's one thing to be very cognizant on, and that is focus on the current state. As developers and architects, it's often difficult to contain our enthusiasm when you hear the requirements and start developing a solution in your head. Stop. If you start doing this before the requirements are defined, you're in for more difficulties later. Plus, you don't want to derail the conversations you're having with the client. Focus on the current state and solution later.

I believe the best way to gather requirements and avoid requirement surprise is to go through what I call “a day in the life” of the process in its current state. What I mean by day in the life is end-to-end scenarios, across every role, all the while you take copious amounts of notes. This may require sitting side by side with the client. In some ways a day in the life is like what Atticus Finch told Scout in To Kill a Mockingbird: "

you never really know a man until you stand in his shoes and walk around in them."

While you're taking these copious notes, you should gather, but not dwell on pain points. Reminder, in this stage you're getting smarter about the workflow; not making things better.

The next section here focuses on the kinds of questions you should ask when doing workflow requirements. You don't need to ask the questions in the order I presented, these are merely idea starters. When asking questions, visualize a funnel and ask your questions like you're feeding the process through a funnel. Ask broad questions first, and then narrow down to specific questions.

image

In addition to narrowing the questions down, if you hear a requirement and you don't understand it, repeat it back to the client for clarification or ask them to elaborate.

Who

In a workflow context, who can be a group or an individual. When talking about who, it's best to identify all participants at a high-level, then get granular. For example, talk about "HR Manager" instead of "Dave from HR."

  • Who owns the process?
    • This might be the most critical question. From a process perspective, it helps identify the owners for clarification and accountability. From a SharePoint perspective, it helps "who owns it in this realm" whereas the realm is SharePoint.
  • Who/what starts the process
  • Who participates in the process?
  • Who participates in this task?
  • Which account performs this action?

What

Asking questions that begin with what help put some form around the process. Asking things like "what is the start and end state" also help define the vocabulary of the workflow. What I call approval, you may call completed. These questions help to eliminate some semantic disparities. Don't go overboard with asking what too early because you may get too deep in requirements too fast and have little context for the rest of the workflow.

  • What happens in this process?
  • What is the beginning state?
    • Draft/submit
  • What is the end state?
    • Approved, Finalized, Published?
  • What occurs in this step?
  • What are the outcomes of this action?
  • What if there's no data?
  • What if the approver is out of the office?

Where

You may not think there's a lot to ask about where, because you're thinking it's an online process and there's one domain, but that's not true. Workflows may reside online, but there may be an offline component. Additionally, where helps identify where the various pieces of the workflow reside. They may not all live in a list or library.

  • Where does the process live currently?
  • Where does the thing go after the workflow completes?
  • Where does the workflow get data from?
  • Where do users complete their tasks?

Why?

I had a neighbor growing up who would incessantly ask "Why?" no matter what I was doing. Because we're adults, I'd like to think we can restrict our why's to not annoy our stakeholders, but asking why often allows you the ability to question logic and process structure. You may be the first person to ever ask why. This may make the client think critically about their own process and help identify efficiencies for the future state. Remember, at this stage you're only concerned about the current state, so fret not if you don't get a lot of traction out of your why questions.

  • Why does the workflow do XYZ?
  • Why does it take 5 business days to complete?
  • Why are there 3 outcomes?

When

When helps parameterize date and time context for the process.

  • When does the workflow run?/When does the workflow start?
  • When are users notified about the workflow?
  • When should XYZ expect ABC to happen?
  • When everything is working correctly, how long does this take end to end?
  • When does this use case occur?

The last question, when does this use case occur, is a very specific question but a very important one. Remember that you're getting smarter about the process. You'll take this newfound wisdom and turn it into a technical design. Because we're not dwelling on pain points here, you may find that certain use cases are major pain points. But ask how often the scenario occurs. It may be a 1/100 or 1/5. Asking for the frequency will help you decide how to incorporate the use case into your technical design.

These questions aren't comprehensive by any means but should help you guide the conversation around the current state of the workflow. By asking them, and structuring an effective requirements session, you'll be smarter about the workflow and that'll help you make the workflow better. In my next post I'll talk about how you create better workflows.