The Case Against Window Dressing

Scott Francis
Next Post
Previous Post
“Window Dressing” can kill your project.  It can even kill your BPM project.  Keith Swenson wrote a humorous but educational piece on an in-house BPM project gone awry.  Anyone who has deployed an internal application can relate to his story, but if you’ve deployed your own technology (or your own BPM technology) it hits especially close to home! My favorite point made in the post is that flashy or pretty UIs don’t add value in-and-of-themselves.  That the focus should start with function and value, and apply the Keep It Simple Stupid (KISS) principle.  The extra UI “features” are break-even, if not value-detracting, from a value proposition. Interestingly, Keith’s very next post was about the same kind of window dressing… but this time on the “back end” of integration/services:
I was asked “What common mistake do people make that causes unnecessary delay in BPM projects?”  The answer: Many projects have a goal to implement too much at once.  Some projects attempt to turn a manual process into a completely automated “straight-through” processes where there is no human interaction at all. It is true that the more you can automate a process, the lower the cost or running the process.  But the cost of automation can vary greatly from activity to activity.
As he points out, integration is expensive.  Wrapping that legacy application as a service, is expensive.  It often makes sense to start with more easily attainable goals as a fallback position – by enabling the process without integrations first.  A technique that we’ve found effective on our projects:
  • Start by modeling the process flow (which includes steps such as process mapping, inputs/outputs, etc.)
  • Get the right level of logical abstraction in the second pass (re-organizing the original process)
  • Get rudimentary UIs in place to allow running the process with as few integrations as possible – fewer integrations even than what the project requirements are.  Make sure the happy path works.
  • Build test services to mimic the behavior of the integrations where possible – this allows you to test the various outcomes, exceptions, etc.
  • Now prioritize and build the integrations that improve the process, based on the value of the improvement as compared to the cost of the improvement.
In fact, a process can be deployed with substantially all of the integrations yet to be completed, if the business users and IT professionals can be pragmatic rather than idealistic.  As Keith himself states:
There is an emotional side.  Some people are shocked when I suggest that we simply assign a task to a user, and have that user manually update the information in the third party system.  It just seems wrong to automate the process so that people can manually do a task.  This group-think often pushes a project to an all-or-nothing stance in process automation.  Striving to automate that last 5% causes most of the delay and cost of a process automation project.
This is best-practice process improvement as enabled by BPM.  It adheres to some of the principles that folks in the Lean school of that would espouse: namely, that you don’t let technology get in the way of your process.  Figure out the process, then use technology to improve it as the process stabilizes.

(As an aside, on one of my recent projects, rather than wrap batch scripts as synchronous transactional web services, we just continued to trigger them the old fashioned way:  by inserting records into their job-scheduling tables and polling for results.  It isn’t a particularly exciting method of integration, but these batch jobs already supported it, and it gave us better velocity toward production deployment. )

Tags:

  • Pingback: Column 2 : links for 2009-07-02()

  • Sandy –

    how right you are about the difficulties of breaking down the v1 / v2 barrier. There is a method to the madness of breaking down those preconceived notions, which are reinforced by the actions of both IT *and* Business.

    This might be fodder for a good post, but here are a few of the ideas:
    The first step, of course, is to fund for more than one version up front! The corollary to this is that if you only have budget for one version, break it up into two versions artificially.

    The second step is to show incremental releases that don’t go to production. Get the business used to seeing interim progress, and get IT used to be accountable for providing progress throughout the duration of the project.

    The third step is to get the business involved in prioritizing what goes in and out of the next incremental release.

    The last step is to actually live up to your commitment to get started on v2 right away. Or even before v1 ships, if you really want to send the right messages…

  • Sandy –

    how right you are about the difficulties of breaking down the v1 / v2 barrier. There is a method to the madness of breaking down those preconceived notions, which are reinforced by the actions of both IT *and* Business.

    This might be fodder for a good post, but here are a few of the ideas:
    The first step, of course, is to fund for more than one version up front! The corollary to this is that if you only have budget for one version, break it up into two versions artificially.

    The second step is to show incremental releases that don’t go to production. Get the business used to seeing interim progress, and get IT used to be accountable for providing progress throughout the duration of the project.

    The third step is to get the business involved in prioritizing what goes in and out of the next incremental release.

    The last step is to actually live up to your commitment to get started on v2 right away. Or even before v1 ships, if you really want to send the right messages…

  • Pingback: Process for the Enterprise » Blog Archive » Breaking Down the Version 2 Barrier()