SharePoint Workflows: The Swiss Army Knife

Skills:  Business Analysis, Process Modeling, Information Architecture

I often receive requests from clients who have identified the basic process flow and then need a workflow to send email notifications to a variety of users based on a status or field change.  Though a workflow sounds like a great solution, it often requires ongoing long-term maintenance as business requirements change over its lifetime.  These changes often require IT Support if the workflow is not architected properly.  This additional support can easily bog down the SharePoint Support Team; especially, if the Team consists of only a few members (which is usually the case). 

As more processes are implemented as workflows, the percentage of time required for support will eventually restrict the amount of new development.  Not a good position to be in.  To head off these conditions, teach and train employees along the way so they understand the importance of their engagement and how they are empowered to manage their own content, workflows and processes within the platform.  Don’t fish for them, give them the pole and teach them the techniques to bring in the catch.

Employee engagement, and eventually adoption, comes into play when each user (both Business and IT) realize the breadth and depth of the platform and that the majority of the workflows can be implemented with OOTB configurations consisting of a Status column, custom Views for each Status and Filters and Alert Me’s for each custom View.

So, when is a workflow needed versus simply configuring a list or library with a few more columns to provide custom view filters and alert me functionality?

Let’s go back to my original client request that consisted of a simple Bug Tracking list for a specific product.  The concept is that as the bug request moves through the process, email notifications are sent to various audiences until the process completes.  The basic process flow resembles these steps …

  • any company employee may enter a request
  • the request is reviewed by the support team
  • after analysis, the request may be certified as a ‘bug’
  • the bug will then be assigned to the Development (Dev) Team
  • the Dev Team develops a fix and completes testing
  • the fix is sent to the Quality Team to thoroughly test
  • the fix is then rolled into Production
  • the Quality Team verifies Production and marks the bug as Complete

As SharePoint has workflow capabilities, the normal response from IT and Business users is that “we need a workflow”.  This is similar to the analogy that when everything looks like a nail, here’s the hammer.  When IT receives these types of requests, we need to ensure that we provide more value than just someone taking orders at say Burger King or McDonald’s.  We need to review the request thoroughly first “to understand” and second “to be understood”. We need to apply business analysis techniques to ensure we understand what the real problem is, what the real symptoms are, the audiences involved, the handoffs along the way, etc and in the ultimate end result of the whole process. 

“Proper due diligence is critical to adding value. “

A workflow may or may not be the answer. 

Here’s a few thoughts to consider before jumping on the “we can do that with a workflow” …

  • Complexity of the process
    * how many steps are involved
     * how many people are involved
  • Physical distance between process users
     * are the users on the same team
     * are the users spread across town
     * are the users spread across the country
  • Duration of the process (start – finish)
     * does the process need to be completed the same day
     * does the process evolve over a number of weeks
  • Type of process actions (ie; approvals)
     * bug fix process
     * conference approvals
     * PTO/Vacation approvals
     * library check in/out
  • Context of the Audiences
     * are the users on the same team
     * do we have a matrix of users across roles, teams, locations, etc

Potential Solution Options

  • Workflow
  • Configuration Option
    * create a Status column with options for
        + Submitted
        + Assigned
        + Tested
        + Ready To Implement
        + Complete
    * configure multiple Views related to each Status option
    * configure multiple Alert Me’s related to each View
  • 3rd Party Web Parts
  • Dashboard with OOTB Web Part Filtered Connections

The Solution Option you choose will vary.  What makes sense for one audience may not for another.  Consult all audiences involved, prototype, test and test.  The best option will bubble to the top.

How has SharePoint affected you?

Advertisements
This entry was posted in SharePoint, User Adoption. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s