Resources

Once you have your current state model, what do you do with it? How do you share it with the Process Owner and Executive Sponsor and spark their interest? My experience is that executives looking at a model that is 30 to 60 steps long are impressed and say something like, “Wow, that process is complex. I can see it has a lot of steps which could take a long time.” But they are not interested in reviewing every single step and getting into the details.

Tell me if this sounds familiar. Organization A decides to adopt Agile methods and begin the lengthy and possibly (probably) expensive transformation process. In doing so they engage in lots of training, read books, attend conferences and listen to webinars. They engage a consulting organization to help coach the change. But, after a period of time has gone by someone brilliantly asks, “So, are we better for having done this?” Great question. Many companies have no idea whether or not these Agile methods are actually helping the bottom line and the way we deliver overall. We figure that if teams are sprinting and doing retrospectives we must be better. If teams are co-located and I see sticky notes on the wall, we must be better.

Projects create a maelstrom of documentation – charters, workplans, issues logs, process flows, requirements, solution designs, parking lots, and many more. With the deluge, invariably some of the documentation is relegated to the hard drive of death – hidden out of the view of those who might benefit from its availability.

OK, you have completed a successful pilot BPM project and your organization is now committed to a major enterprise BPM initiative.  There are many steps you need to undertake now, too many for a single article such as this, but in this article we will explore one which is often overlooked.   The BPM industry, both tool vendors and consultants, like to talk about how much simpler it is to develop solutions with BPM than with traditional programming tools.  While this is certainly true, too many organizations interpret this as license to short-cut the disciplines which they have found to be necessary in all other forms of solution development.  This article will discuss the importance of modeling standards, provide guidelines on how to develop appropriate standards and perhaps most important how to make them an integral part of your process.

Requirements gathering should be done mindfully. Then there is this world we are living in, which requires agility, right? Well, can mindfulness and agile be imagined together? Once you can imagine this your requirements will be solid and done right, and you will obtain agility. Your sign-offs will be also achieved smoothly. It won’t stop there. Development, unit testing, functional testing and UAT will be smooth as well, including your org readiness efforts, along with your usage uptake and learning experience. Does this sound like it is out of this world, or in Utopia as most of us know this is not a very easy thing to achieve?

In the last twenty years we have become very good at mapping and improving processes; but we still have poorly structured organizations. Can we use our understanding of processes to improve organization design? A process exists to deliver a positive outcome to a customer or beneficiary. Sometimes the beneficiary is the person who does the work, as when you make a cup of coffee for yourself. But most processes in organizations exist to do something of value for an external or internal customer, who is not the person doing the work. This principle, deliver value to the customer, lies behind one of the great developments in process work – Lean. By analysing a process with a focus on what is needed to deliver value to the customer and eliminating everything that is not needed, a process becomes Lean. But Lean tells us little about how the work and people involved in delivering the process should be structured into an organization. So let me try to make a connection.

A SIPOC diagram represents a high-level view of a process. It shows the Suppliers, Inputs, Process, Outputs and Customers. The SIPOC Diagram plays an important role in Process Definition/Improvement and should ideally be done first before embarking on extensive process mapping. An analyst – in collaboration with other stakeholders – may use it to arrive at a consensus on the process before moving to a greater level of detail. To emphasize putting the needs of the customer foremost, the tool is sometimes called COPIS and the process information is filled in starting with the customer and working upstream to the supplier. It is very helpful to give people who are unfamiliar with a process a high-level overview.

Under what scenarios might you use a SIPOC diagram?

There has never been a better time to jump onto the automation bandwagon. The process automation bug is hitting companies left, right & center and these are times when companies that are helping other companies automate their processes are prospering like never before. Hence, it is quite natural that you could do a google search and a flurry of “N reasons to automate your business processes appear on the results. But, what nobody would ever tell you is to ask yourselves why you need to automate in the first place. Because, that would make you think and maybe process automation isn’t for everybody. Let me explain to you some scenarios where you need to ask yourself why it is necessary & here are those.

Does my cost outweigh my benefits?

 The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner

This is the second of two articles that address the specific challenges you may be facing in your work with Product Owners. The first article focused on two very different types of Product Owners: The “Big Picture Thinker” and the “Aspiring Developer”. In this article, the focus is on two types of Product Owners that appear to be different on the surface but who create surprisingly similar challenges for the Agile team: The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner.