Doing by Design vs. Design by Doing

Post by
Scott Francis

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim's intent):

  • Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.? It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.? This works if the process is predictable.
  • Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.? Since you can not predict it, you have to elaborate it as you go along.? You design it, as you are doing it.? There is no development life-cycle.? This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for ?design by doing? and that is Case Management ? particularly a newly enable technical approach known as Adaptive Case Management.? By having a clear label for ?design by doing?, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don't know, why not just call it "design by doing" and use that as the tag-line for your product offering... ACM doesn't quite have the same ring to it, and it isn't nearly as easy to relate to.? Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith's blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won?t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:? a bunch of companies have already acquired one or two BPM software vendors.? How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?? Would you rather be the "XYZ" software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?? Of course!? (well, as Max says, he doesn't care about the labels for his product, Papyrus, so I don't mean to personalize this to Max, by any means!).? And if you're a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle - RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.? But like some others (Anatoly for example), I'd like to keep BPM separate from BPMS (method from technology).? There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn't benefit customers or practitioners.?? I see managing unpredictable work as still being "process-driven" even if others don't.? Design-by-Doing sure sounds like a process to me, folks.? Maybe a meta-process, but a process nonetheless.

I'd like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings - explain why your software is just the right socket wrench for the job, rather than a screwdriver.? Educate the market on why the software fits the problem definition.? As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

More From Blog

You Might Also Like

Driven Day 5: The Final Day of Automation Goodness: Enterprise UX and Design
Read More
Driven Day 4: Application Modernization
Read More
Driven Day 3: Process Automation Day
Read More
We Work With Companies Just Like Yours
Are You Ready?

Let’s Work Together

BP3 gets you there fast. Contact us today to see how we can bring more focus, foresight, and follow-up to your projects.