Guest Author: Daniel Dunne

I was listening to someone recount a business process the other day, (you know, the sequence of actions that result in providing value to the customer,) and something they said made me stop and ask them to repeat themselves. The sequence they described is something they do often, (more than three or four times a day,) and was probably outlined in some ISO Work Instruction somewhere. The sequence began with an incoming call or message from the customer, then they referred to some system or application for additional information, then they sent an email message to someone asking them to approve an action- that’s where I stopped them, “You do what?” “I send an email to an individual or sometimes a couple of people in order to get approval to take the next action.”

(Pregnant silence.) I added a few more questions:

“What happens if the recipient doesn’t respond to your email?” – “I email them again.”
(No meaningful escalation path to ensure responsiveness.)

“Do you know how many requests you receive in a week?” – “I’d have count them in my email archive.”
(Can’t identify velocity of the process, no way to gage current resource utilization.)

“At any one time, do you know how many requests are unanswered?” – “I used this little follow-up flag (colored aqua-marine) to remind me” (I didn’t’ ask what the mauve or chartreuse colored flags meant.)
(No meaningful ability to gage current work outstanding.)

“Do you know (on average,) how long it takes to approve the customer request.” – “No.”
(Can’t identify trending in potential key customer responsiveness metric.)

I often see the email rat race used as a broadcast communication tool (ouch) or a default knowledge repository (yikes!) but among the greatest of house-of-horrors exhibits is email as the vehicle of a business process (regardless of its importance or relative urgency!) The moment that any recurring sequence of a value chain includes emailing someone and expecting an email response in order to continue, it becomes untraceable, immeasurable, and effectively out of control.

What does this have to do with SharePoint?

If in that same sequence, rather than sending emails: there had been a Team or Project Site with a List:

• To which a new entry would be contributed as an incoming request arrived
• Which generated an alert for a target audience
• Who with one or two clicks could edit the item to change a column value to “approve” or “reject” (along with some brief remarks.)
• Which generated an alert for the author of the contribution
• Who could continue to the next required action.

…things might work a little better.

Creating a list to achieve this action takes less than 15 minutes and could easily be built by the end user. Coaching a small audience of participants into using the list would take a few interactive sessions, but would be operational in a day or two. The resulting base of information (the accumulating list items and their date/time information,) would enable an assessment of the current velocity of the sequence, and provide a basis to gage trends and track progress toward organizational goals.

“Why was it in email in the first place?” (I’d refer you to my previous posts about why users cling to email with a death grip, and why mobile device’s affinity for email frustrates SharePoint implementations.)

Guest Author: Daniel Dunne

Dan is a Mechanical Engineer who has a 20 year career in product development, including product design, (US Patent holder,) program management and consulting Mechanical CAD, PDM and PLM-related software implementations. Dan has lead SharePoint implementation teams (as a direct employee) in several different corporate environments, including his first which emerged from a server he setup under his desk in engineering. Dan has consistently championed and evangelized the user-driven SharePoint implementation as most aligned to Lean Methodologies and does everything he can to promote the Spirit of Continuous Improvement. Dan can be reached at [email protected]