Networking

Tool-leading processes vs. process-leading tools

Processes and tools go hand in hand, so the question again is which one comes first?

Which came first, the chicken or the egg? This question has haunted ancient philosophers for centuries, and as of now, there is no concrete solution.

When it comes to dealing with processes and tools, a similar quandary exists. Processes and tools go hand in hand, so the question again is which one comes first?

Interlocking of processes and tools

First, let me lay out the items that I'll deal with in the course of this piece.

A process is defined as a set of coordinated activities performed to obtain a targeted output. For example, to clean a car, the first step is to rinse it, wipe the body, and finally dry it. So, these three coordinated activities are basically achieving a single goal -- a clean car.

A tool is an instrument that is developed to carry out a particular function -- like a drill for drilling a hole. In the clean car example above, I could use a tool like a water pump to help me rinse the car with a flick of a button.

But what if I use a tool like a pressure washer? This tool has the potential to modify the existing process of car cleaning.

The burning question is do you define the process and then hunt for a tool or obtain a tool with capabilities and develop processes around it?

Let's consider both cases.

Tools first

Technology is ever evolving, and with tools resulting from technology, one can argue that tools must lead the way for the activities we perform.

Let's say that a company called TLS finds a particular tool useful, and although the tool doesn't serve their intended purpose one hundred percent, it's somewhat helpful and could come in handy when implemented full force. So the company goes ahead and procures the tool and then modifies the processes to meet the tool's needs.

The company changes some expected outputs to suit the tool's needs. The output starts to appear, just as they envisioned with the revised process.

Process first

A process is developed, without the aid of technology but with analytical reasoning and a good understanding of the objective it's trying to achieve.

PRC, a competitor of TLS, is made aware of TLS's new tool acquisition. PRC sits back, examines their processes, and maps it with the new tool. They don't like the possible adaptation.

They back their processes and shop around for a tool that will also back their process. They come up with a tool that doesn't have state-of-the-art technology. The developer is willing to customize it to their needs. The two parties agree, the customized tool is procured, and the output starts to pour in.

Compare the two approaches

TLS believed in technology, but tweaked their processes to suit the tool on hand. PRC, on the other hand, trusted their process and sought after a tool that could do what they wanted it to do.

TLS compromised their process for technology. PRC stuck with their process and instead compromised the tool's original configuration to suit the process.

Which is a better approach?

Remember what I said earlier: Processes are a set of coordinated activities that will achieve the goal you want to achieve. A tool is a means through which certain functions are carried out.

What counts is the end result, and the process's existence depends on the output it delivers. If it's a home run, it's all well and good, if it doesn't matter what tools were employed. But compromising a process, in the sense that the basic output could be altered, is a scary prospect.

PRC backed their processes and got the tool configured to their needs. They got the best out of both worlds. On the other hand, TLS had to do away with certain process configurations to fit the new master --the tool. PRC's approach is the right way to go about integrating process and technology.

Tools are meant to complement the process by enabling the process activities to be performed as per the design, and never the other way around.

But tools are important

I can't think of designing a process without understanding the capabilities of tools. I'm very much a tools person. But the tools listen to my design, and I don't succumb to their way of working.

It's important that while designing a process, you have a good awareness of what kinds of tools and capabilities are available in the market. That gives you a good starting point. Design the process keeping the objective in mind, but optimize the activities with the available tools.

Tools are undoubtedly vital; a process developer must exploit every aspect of the available tool and perhaps stretch it to imagination -- and have it customized to complement the developed process.

How does a process consultant do it?

I have worked independently and with teams of process consultants in developing several processes for ISO 20K, ISO 27K1, and PCI DSS. So I can give you a fairly good idea of how a process consultant sews processes and tools together.

There are specific objectives that a process must achieve. The inputs, budgets, and other service-level requirements are in our possession before we start defining a process. Apart from this, we are aware of what the tool world has to offer.

The inputs are known and so are the expected outputs. Filling in the blanks with process activities is all that we do. Let me illustrate this with an example.

If you want to bake a veggie pizza, you know the ingredients you probably want -- like a pizza base, sauce, cheese, olives, and tomatoes -- and you know what this pizza looks and tastes like. The steps you take to prepare the pizza are like the individual process activities. The activities you do in order to make a pizza are coordinated -- you pre-heat the oven, apply the sauce on the base, apply the cheese followed by vegetables, and then add more cheese. Then you put this in the oven for ten minutes to complete what you had on your mind. The output is just as you expected, and the oven served as a tool that enabled the process activities to be effective.

Summary

A process must always be the boss and lead the tool to its expectations.

12 comments
baktavarbaba
baktavarbaba

Just a question in my mind.. Lets say, in an new organization which has set up recently there were no processes/tools, what is the best practice to go ahead?

Fairbs
Fairbs

I can think of at least a couple of examples where the process is adjusted to fit the tool. 1. In a very mature organization with well developed (perhaps not well documented) processes. They want to put in SAP, but it is cost prohibitive to create the code to make it fit into their processes. The decision is made to tweak existing processes to fit the 'off the shelf' ERP system. 2. A new tool is required due to limitations of the old one. Two products are identified and both meet >90% of the requirements. One is 100k and the other is 10k. 3. In a mature organization, there are usually many processes that have been globbed onto over the years and in some instance they don't even really make sense anymore. Noone takes the time to fix these problems until someone comes along and slaps a tool into place that may eliminate outputs, create the same one or new ones. The overall results may be different, but not necessarily better or it could be much better. Ideally I think that process should lead tool selection. But the reality is that sometimes you don't get to create the perfect process and even if you did there may not be a perfect tool to fit that process. And you also need to take into the real constraints of time and cost.

steve.lawless
steve.lawless

Process is about achieving an outcome. All the tool does is automate the process..so you get the outcome quicker. If you put tool first with a cr@p process...all you get is fast cr@p.. Process first...always And I'm a ITSM software solutions vendor.... Regards Steve http://www.Wendia.co.uk

gechurch
gechurch

I don't know about Tool-leading processes vs. process-leading tools, but I've been involved in projects that have a tool of a manager leading the process. That never works.

Paul Dandurand
Paul Dandurand

What about a tool (i.e., PIEmatrix) which can be used to create a process from scratch. This would include storyboarding the process while collaborating with multiple "process experts". The tool would then used by the people executing and governing the processes day-by-day. Then the process can be updated with improvements via the tool. @Richard, For low-level process maturity organizations, the tool would be an enabler to help organize the process in a visual format. For a high maturity organization, importing existing processes into such a tool would then bring value for the execution side as well as ongoing process improvement. @fmarkin, What is more important is evolving the process rather than evolving the tool (assuming the tool does its job). Current tools used for containing processes today are PDF, Excel, or Word files that sit on some server. This "library" approach fails. Many process owners have told me their processes are usually outdated. Process improvement really needs to be in real-time, especially for organizations that deal with constant change. The right tool can get it done right.

richard.warren
richard.warren

Bzzzzzzzzzzzzzt...wrong answer, thank you for playing... Process leading the tool is only a valid approach for well established, mature processes. Where they exist, the process-leads-tool approach is appropriate. But, where processes either don't exist or are at a very low stage of maturity, a better approach is to use a Delphi approach and create a set of processes, using the tool of choice, and make it so easy for the adopting organization to use those tools that the process becomes engrained. This is the best approach with low-maturity organizations. I've seen this tool-led approach work with EPM solutions in low-maturity organizations (assessed using OPM3 and other frameworks) time and time-again. A monolithic, one-solution-fits-all recommendation just isn't effective if it ignores adopter maturity. Thanks, Richard Warren PMP, MBA E-Business, doctoral learner in IT specializing in Project Management

chris.mccluskey
chris.mccluskey

Agreed! Now if only techies would understand this as well as upper management. Most processes are can not be changed willy-nilly to fit technologies. Many adhere to strict legislation, standards, policies etc. oh, can you tell I'm a business analyst? LOL

Beejer
Beejer

"What counts is the end result" is the key statement. The focus must be on the desisred outputs and the evaluation of potential processes and tools should be based on producing those outputs with the highest efficiency. If you find that 'home run' off-the-shelf tool that gives you the outputs you need, buy it and design the process around it. Haven't found the tool off-the-shelf? Then design the process that minimizes your costs and have it built. It's the output that rules the design process.

baktavarbaba
baktavarbaba

Nice article with examples..enjoyed reading.. :-) Process is the Boss, agreed..

Fairbs
Fairbs

What does the organization do? The steps that create the prod or service is your process. You may not think you have one, but if you're generating anything then you do. It's probably not well documented. Tools are what you use to accomplish the process and can be very simple such as a checklist on a piece of paper or extremely sophisticated such as using a megadatarecombobulator 9004 R5822.2.8.4. If you document (or at least analyze) your processes and how it's done then you can look at places where it can be improved through more effective tools or better process. I would say that's the first step. A good book on the subject may be helpful as well.

belaihed
belaihed

As a normal practice is to define the process and compare it with the tool to identify the GAPs. Then it depends on the business to "How much they want to invest to modify the tool". Looking at that, the best ROI can be achieved with acceptable compromise. Abdullah

fmarkin
fmarkin

I think the process needs to be developed first for 2 reasons, 1. With the process already in place and well thought out, the tool is allowed to evolve as new and better tools become available. As long as the desired output remains the same, the process need not change, only the tool 2. it is easier to hand down a process then to hand down a tool.

Editor's Picks