Know the Flow

Many times, we start a project thinking we know how things work, who does what and why they do it. We take what we know in our heads to be true, and use this as the foundation when looking to implement a technology solution. Truth is we may in fact be enhancing a problem that we do not realize exists.

Before you begin any technology program, it is wise to walk through the underlying business processes that take place in order to accomplish specific tasks. In the eighties, many vendors talked about how document imaging would have minimal impact on the work environment and would enhance the workers activities through faster access to information. While the latter part of this statement is true, reality was that document imaging dramatically changed the ways people worked. The process had to change because we were moving form a physical paper world to electronic files stored on a computer. File rooms and clerks slowly gave way to imaging managers and scan operators. People could access information from their desktop without the need for some to assist in finding it. The process also had to change in how they shared or passed the information from one to another in review and approval cycles.

Today we still see similarities in that projects are begun without a clear understanding of what is going on in the business environment. In many cases, this is the cause of unanticipated issues and potential project failure. Most work processes or flows are the result of need and happen serendipitously rather than through a conscious design effort. Something has to happen, someone makes it happen, the result is the expected result and it stays in place as the way we do things. No one really knows why or how it began but id did and we do it that way today.

Start at the process and look at the what, how, and why of a process then ask if there is a better way to do it. Once you have made the changes and refined the process, look at enhancing it with technology that supports the process and opens the door for further refinement because, you guessed it, this is not a one-time thing it is a continuous practice and one that should be part of the overall culture.

Bob Larrivee - AIIM

. 

Comments

[Ben Tremblay]

Just a thought in the moment: in the background as I was reading, a TV item about autonomous submersibles, and the designer was saying how "Everything starts with the ability to go straight, because it has to compensate for weight and currents and various forces."

Really, isn't the best we can do come to a strong understanding of where we've been and what brought us from there to where we are, and then to project that forward? I'm imagining a trajectory extrapolated forward through a complex phase space; hardly a step into the unknown since we can ready ourselves to perform appropriate mid-course corrections.

--bentrem

[Ben Tremblay]

I've relied on the rubber-chicken dance as much as any and have had it bail me out more often than most, but that sort of desperation tends to leave me feeling hungover.

So your "Start at the process and look at the what, how, and why of a process then ask if there is a better way to do it." strikes me as a recipe for home-baked bread: almost fun to make and definitely worth the effort.

I'm reminded of something I wrote recently in Boxes&Arrows, about how we really can at least establish a firm base and extrapolate a likely trajectory before lifting off into the realm of unanticipated influences and cross-currents.

Arno Penzias … head of R&D at AT&T, researcher (discoverer?) of dark background cosmic radiation … prolly a good poker player … anyhow: he had this idea of “setting up for failure” where projects were tested with minimum resources and (consequently?) no ego investment. Just how they fell over or burst into flames was, when properly conducted, very telling.

It seems to me that agile should perform wonderfully in a near chaotic situation when invisible variables might arrive in flocks.