All right stop! Collaborate and listen (Sharing Points)

June 14, 2006

Workflow Step 1

Filed under: Captaris — stephenmuller @ 11:38 pm

It has been sometime since my last post, but I have been busy getting several Captaris based workflows running in a large Australian Government Agency.

It has been largely helped by very proactive Project Managers. I would like to write up some things I stumbled over and things that worked, and didnt.

First point – requirements gathering

Gathering requirements for workflow is very very different to getting requirements for a normal system I have found. It is often tricky to get people to rationalize what they do when they receive a bit of information or document.

There are so many processes that go through peoples heads when they review some information, and all of that needs to be captured. What I did notice is, in the end a lot of it can be very simply broken down to small, concise steps.

I tried the approach of only giving people access to the data they required for them to action their task. I was (and so were the users) keen to eliminate information overload and unnecessary and potentially confusing clutter.

People seem to be reluctant to give away, and to, I dont want to use the word trivialize,(simplify perhaps) their work. But I found that this evaporated as they could see many current roadblocks and frustrations they have with the current process could be eliminated. There would be a greater sense of empowerment and freedom as they knew that certain steps must be done before them and all work that has been done is now audited so they have security and proof of what has happened.

Drawing lots of pictures really helped, after the meeting I developed what was discussed and went back to show and create a pictorial reference what was agreed upon (easy to do in Captaris). I think this was a good step as they could see the results of their inputs and see some good structure developed.

Once the structure and flow had been agreed on my next job was to focus on each individual task with the responsible person or group. This is where the real documentation kicked in. It was a matter of describing the UI and what was expected and where the data was sourced from.

A long process but it was worth it in the end. It allowed me to cover as many bases as possible, involve the users so they felt part of the process and the ‘magic’ of the technology is explained, which I think helps the users feel more comfortable in using the technology if they can at least understand some of it. Without the users willing and accepting of technology it will be hard to achieve successful outcomes. They are a massive component in a system and can not be overlooked.

Anyway I will post the rest of this story later.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

Blog at

%d bloggers like this: