We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is it impossible to get a process right the first time?

Vote 0 Votes
Is this forum discussion, Peter Johnston wrote the following:  "The reality is that with the complexity of modern business no-one will get a process right first time, so an iterative, evolutionary process is essential." What do you think?

19 Replies

| Add a Reply
  • If we are talking about a business process then yes, by definition.

    "If it doesn't make three people angry, it is not a process." – Michael Hammer.

  • Yes. By the time you implement the process, something will have changed. Perfection is an unattainable goal and may not even be desirable...

  • It's the core of good managing by process I think.

    Processes must be adaptive to change. The ones that aren't are only right one second.

    Processes are not a predefined set of rules. Most of them need change power to keep delivering what they promise.

    So it is possible to get it right the first time, only the term 'right' will change very fast.

    Being able to cope with that separates the boys from the men.

  • Getting it right first time for that moment is possible but the next day it may be "wrong". It is vital any supporting BPM technology has that flexibity for constant change driven by business users.

  • Peter is right, and it is great to see the BPM community acknowledge the central importance of adaptability.

    Process flowcharts are models > Models are abstractions for convenience. Complex organizational workflows are simplified for comprehension/discussion and execution.

    The assumptions of the model are its 'context', which are encoded. When the assumptions are wrong or don't apply, the Process Model must adapt or else it breaks - that simple :)

    Of course, if 'change' = send an email to a suggestion box, and then, if you are so lucky to be prioritized, you're new requirement will be encoded in six months - then you really are not adaptable at all. "How" matters so customers and the consulting/services firms that support them have to take a hard look at the underlying technologies to separate the wheat from the chaff.

  • I sure hope there's unanimity on this point from the BPM community :)

  • Agreed Peter. If we assume that the only constant in life is change, then by definition in the time it takes you deploy the right solution, the definition of right will have changed.

  • No doubt about it. Not only can one never get it right first time, one should never even strive for that. Too many times projects fail because of analysis paralysis.

    My motto is "don't debate, just automate, then cogitate, and innovate".

    In other words, near enough is good enough and then refine and keep on optimizing using the telemetry you are now getting from the system.

  • Great to see consensus, but how about some play on words.

    It is possible (preferable) to create a process that works first time :-) , however what works the first time is rarely the best process and is probably just the easiest to implement. We can of course then start to iterate and improve the process - assuming that is we did not put in a new automated process and let the staff with all the knowledge go! (in the name of waste removal) :-)

  • It may be possible, but it is not desirable. The perfect, as they say, is the enemy of the good. As Kevin suggests above, don't strive for perfection. Strive for utility, and then leverage the power of BPM technology to successively approximate perfection—all the while keeping in mind that when it comes to business processes, “perfection” is a moving target.

  • Just another thought when thinking about adaptation and change power.

    Most answers above focus on good old 1980's process improvement PDCA thinking.

    No problem for some processes, but those are actually locker room projects looking backwards (after the game has been played) how things can be done better in the future. How long does an average process improvement project take?

    And unfortunately all those 'to be' processes seem hard to implement most of the time.

    Wouldn't it be better if you are able to create a process with such characteristics that it can adjust during the game while the customers are still in the process. Then it is actually always right at the first time.

    In the end customers only care about execution. And if that is gone well for that customer the process was right. (And to make it easy, I forget about the other stakeholders ;-)

    So ACM style processes are actually very right the first time because the processes is 'developed' during the game. Maybe not optimal, but right for the case at hand.

    So again, the characteristics of the process and the desired result define again how right a process must be.

    Unfortunately 'not right' processes are brought often into processes improvement projects, while it might have been better to put improvement power in the process itself so it can adapt during operation.

    The more power you put in the operational (Execute-Monitor-Adjust) cycle, the less often you have to walk through the improvement (Measure, Analyse, redesign, Implement) cycle. And yes, for this you need good people, flexible supporting tools, right information and some guts)

    Being able to act when it matters (when the customer is still in the process) is what real managing by process means to me.

    But there are forces who like to call this flexibility 'dark processes' ;-)

  • Agree with all this.

    The introduction of any technology to an organization (including an automated process) will CHANGE that organization. As a result, their needs change. Thus, the process they needed before the new technology, will not be the same as the process they need after introduction. The organization will learn how to use the process, and in doing so, will discover new opportunities (or problems) requiring the process to change.

    So, yes, because it is impossible to anticipate exactly how the organization will be changed by the introduction of the automated process, the process itself will definitely need to be evolved forward as the organization evolves to use the process(es).


  • The infinite process monkey theorem states that a monkey hitting keys at random using Visio for an infinite amount of time will almost surely create a given process, such as the complete target operating model of a bank.

    In this context, "almost surely" is a mathematical term with a precise meaning, and the "monkey" is not an actual monkey, but a process analyst that produces a random sequence of shapes and symbols ad infinitum. The relevance of the theory is questionable—the probability of a process analyst exactly creating a perfect process is so tiny that the chance of it occurring during a period of time even a hundred thousand orders of magnitude longer than the age of the universe is extremely low (but not zero).

  • I think you can get the process "right" the first time but normally what you get right is only a slice of the entire process.

    Yesterday I sat with a new customer in Bristol, UK. The designer had been working on a comprehensive solution to streamline change requests. I was impressed by his creativity in designing a workflow that captured all types of requests as well as create a comprehensive user experience integrated with the DMS and CRM. He admitted, however, that becuase of time and budget contraints he had to reduce scope, creating a general bucket for many request types that he would later expand into specific change request activities. But he felt very comfortable that his "first take" of the process met immediate requirements and would significantly reduce operational costs and improve sales. I agreed.

    So yes, you can get "it" right the first time, but the goal needs to be continual process adaptation to streamline all areas of the process and of the business.

  • Enjoy discussion, adaptability, flexibility, simplicity all need become key characteristics in process, especially at today's digital dynamic, how to touch customers or engage employees are not just about "right" or "wrong", more about how, where and when, process need continue to improve in those touch points or decision point. thanks.

  • While I agree on the consented need of adaptability, my question would be who and by what criteria would decide if a process is 'right'? The discussion still implies a well-defined flow-diagram as the process base. A process doesn't have ONE right structure and a different one is wrong. In an end-to-end value stream there are many processes embedded and as long each one achieves its goals they are all right. In each instance of an execution there can be many ways such process goals may be reached.

    A process flow-diagram can be right in one instance for one customer and pretty far off for the next. It is now right or wrong? Many people understand adaptability to mean that the process can now be improved to also support the case where it was far off. But who would improve it how and when? In most cases hardly anyone will notice that it was off until some customer satisfaction survey or sales figure at some future days goes badly south. Then the discussion starts what went wrong ...

    Adaptability means that a process can be executed as needed at runtime. It is therefore never wrong. What works well can be reused, but how will you know if it is effective and efficient or not?

    Therefore it is so essential that process goals are explicitly defined as part of the process as I propose for ACM. All process goals must align along the value stream or capability to achieve the defined outcome in the business strategy. To actually make it feasible there must be also the definitions of operational targets for cost and service levels. Now it becomes easy to see if things are right or wrong. Defined goals either achieve strategic objectives and targets or not.

    All that has hardly anything to do with analyzing and modeling flow-diagrams in right way or a wrong way.

  • Having been in the BPM/workflow world in several different capacities over the last 20 years, I agree that it is impossible to get the process right the first time. This has always been a concern of mine. Over the years, I have watched organizations go through labor-intensive re-engineering efforts (and in many cases, it was my job to assist with these efforts) as a first step prior to implementing BPM. In all cases, these re-process efforts are 'blue sky' ideas, not based on actual testing. And while each process is custom developed from one company to the next (which of course means it is probably some improvement over trying to map to a standard process), business changes mean more process changes where again a team of people imagine what the revised process should be.

    So by the time the re-engineering process is completed, which can take months, and the time to implement the BPM system, which can take many months more, and the time to implement analytics (many months more) - bottom line is that you won't know how much you have improved the process using real metrics for some time. Most importantly, how will you really know when you have achieved the optimum process.

    Like Max and Emiel, I am a proponent of ACM because the right ACM system solves this problem. While I can't speak to every vendor's solution, true ACM solutions are, in fact, the re-engineering tool in and of themselves. And if the ACM solution is based on LEAN technology, it only takes days to weeks to implement.

    With ACM, we recommend that clients don't go through the 'as-is' and 'to-be' re-engineering process but instead, implement ACM based on the current process. The system provides immediate metrics so you now have all analytics on the current process. Then, the business analyst starts to 'tweak' the process, gets immediate metrics to measure improvements - an iterative process that delivers continuous process improvements - not based on theory but based on data. An important outcome of this approach is that with these metrics, a client knows the ROI of the system.

    One last important comment. I am not saying that ACM should replace BPM but instead, sit alongside. Most companies will need both.

  • Nice discussion, even i totally agree with Peter's thoughts.
    As the managerial jargon goes DRIFT - Doing it Right The First Time, is definitely an advantageous approach when it comes to building cost effective processes. But considering the Agile mode of business development, it becomes very important to make the process "adaptable" and "flexible" than just making it right the first time.
    And moreover, "Process is not just about building processes but also enriching it with process improvement features".
    If we consider, BPM, the word "M" also refers to - Model, Measure, Monitor, Manage -> So, any process driven by these M's will keep improving and adapting with feedback and key inputs, than just building a one shot process flow in one go!!

Add a Reply

Recently Commented On

Monthly Archives