All Beginnings are Hard

If people use different terms for something, that’s a good indicator they mean different things. Even if they use the same terms, their understanding of concepts may differ. To some extent, this is unavoidable and harmless. Jargon is rampant in any discipline and fairly innocuous as long as it’s only used within that domain. With terminology for processes and particularly with its start(s) and end(s), which is needed in communication that is interdisciplinary, it can be problematic.

Ask different people what "the process" is, and you’ll get as many answers as respondents. People’s views differ on what the process is, so they also have alternate views on what constitutes its beginning. Deciding therefore means sitting around the table and explaining different options and opinions. This should be focussed on putting together ideas and gaining mutual understanding and agreement on what the starting points of the process are and how they are defined. Which implies you need to do this with various domains at the table (business, project, IT, financial).

This process requires working out details; high-over analysis does not bring you far enough. This is the point where you determine what the process is and is not and where terms used need to align. In a dictionary, this is achieved by defining each word. Here, a similar definition is needed, for terms like "process", "start", "input data" and "customer". You have to look at technical aspects (such as integration challenges) as well as data input requirements for starting a process. You have to look at which actor (human or system) performs which action. You have to define what is meant by "we transform the Internet form data into an Order object". You do this by sketching flows, listing data containers and their properties, drawing system components and their interactions, etc.

There are important trade-offs to be made during this step. Funneling multiple channels into a single process places requirements on input, transformations and administrative processes, but has the benefit of a single way of processing requests. Existing software components may need to be changed, configured or even entire new ones built. Offering a process start screen means weighing user experience against technical impact to support it. There might be a reduction of time spent on data entry with a far more extensive and interactive screen, but it might not be worth the investment to build it over a more simple variant. Once these decisions have been made, these need to be noted with our rationales for them, as they will be needed later on to retrace our choices.

This step should be easy if you took the appropriate time for the previous step as it’s fundamentally writing down the result of the decision process. If you determined there are two possible ways to start the process, write that down. Explain terms used and list input data. Describe assumptions about further processing requirements and how they relate to choices made. In other words: summarize the outcome of the decision making process. You went into all that detail; make good use of the effort by documenting the results.

The importance of this step is that it’s the primary input for further activities. Not just for technical implementation where a precise specification is required to make sure everything works as intended, but also as a means of facilitating discussions. People forget things that were discussed and decided a week ago. Hey, I have trouble remembering why I went to the kitchen by the time I get there, how do you expect me to remember minute details about process start data? Right. I don’t. I look them up. Or I ask somebody else if they remember whether an Internet channel start also includes the exact calculation results or just the input variables. What was decided and in some cases a brief description of the rationale behind the decisions help to remember what should be done and why it should be done that way.

For some reason, we sometimes tend to act like a military operation: information is communicated on a need-to-know basis. While this may be true for a lot of information in a process automation project, the starting point of the process is not one of these things. Anybody involved needs to understand in which ways this process can start. So once the decision has been made and specified, it needs to be communicated. This can (and probably will) lead to feedback from others not involved in the decision making process. They may have the same concerns with the chosen options and come up with alternatives. Most of the time, this re-iterates the discussion held before. Using our rationales, choices can be explained. Sometimes, there is new information that’s valuable and leads to reconsidering our decisions. Even so, the communication makes it clear for everyone which process exactly is being worked on.

By now you may be excited to get started automating the rest of the process. Unfortunately, you need to revisit the previous three steps first. To define what the process is, you need to decide what starts the process as well as what ends the process. Many processes have several valid outcomes and these all determine the scope and content of a process. Does the process end once we package orders or do we require a receipt confirmation on the other end before we’re satisfied our work is complete? If we need more information in order to process a customer’s request, does that mean we ask for it and then close the process until the information arrives and we start a new process? Maybe we should keep a single process open ended until we receive an update. These are the happy flow versus alternative flow decisions that need to be made and are crucial for scoping the process and the project to automate it.

Admittedly, there is no magic in following these simple steps. There’s a lot to be gained for doing them, though.

If that isn’t enough reason for you to make start and end of your process clear, here’s what you may be in for further down the road.

Sound simple? Indeed, it is; and it’s well worth it. All we need is to just do it.

All beginnings are hard, but as the saying goes: a good beginning is half the battle. Make sure you get off to a good start and determine the start and end(s) of your process before you dig into the details of what happens in between. It’s a surefire investment for the whole project.