Are You Working In Parallel Or In Sequence? One Of These Is Much More Efficient.
Often, when trying to get something done, we list out the steps (often mentally) and check them off as we go, one by one. When we get held up on a step, we work on something else until the holdup resolves.
This sequential approach generally works and, in most cases, whatever it is we are trying to do, gets done.
But to complete what needs doing faster, try working on more than one step at once; work in parallel not in sequence. As a simple example, when I arrive on site at a new liquidity-constrained crisis management client, I ask for a receivables and payables aging all at once. Typically, A/P generates the receivables aging and credit generates the A/R aging. Two different groups, so just from a manpower perspective, these two tasks can be done in parallel.
So what are the keys to working a process in parallel? Follow these steps...
Step one is obvious: list out the needed work steps. What is less obvious is
the importance of thinking through and listing the steps before you begin and not just winging it along the way. This is important; if you fail to consider a step until the end of a process, the process overall will take longer to complete. A complete list will also highlight steps that may not really be needed. (If you have not completed a particular process before and are therefore unsure of the steps, find and speak with others who have.)
Next, determine the critical path: those steps that can't start until a prior step is complete. Then start executing - at the same time - all the steps that
aren't critical path dependent. For example, when I review head count and staffing for cost reduction opportunities in a crisis, I review the payroll register, the organization chart and have a discussion with the CEO, even though I rarely make any staffing decisions until I have my arms around cash flow in the form of a
13-week cash flow forecast.
The cash flow is on the critical path and should be completed before head count reductions are made. Reviewing the organization chart and payroll register are not on the critical path.
A clear understanding of the critical path is essential (for more on this see
Patience is a Waste of Time). Consider whether the steps really are dependent on one another - or is that just how work has been made in the past? Remember as well that
there are times when a preliminary run of the next step can begin. Let's say, for example, that you are reviewing a large capital project to make a go/no go decision. A preliminary run of a financial model - with more assumptions than are tolerable for a final decision - can provide an early screen as well as highlight potential further analysis and steps that may be needed.
Along the way,
delegate tasks, only doing what you really need to do, while using a less scarce human resource whenever possible. Generally, you'll be looking to keep the critical path steps and delegate the rest.
You'll also want to estimate the time necessary for each step, particularly those on the critical path (these represent your true time constraint from start to finish).
Working in parallel can be applied to both decision making and transaction processing work Parallel processing is effective both for transaction work (such as paying invoices), and for making decisions (such as allocating resources, hiring, firing, and so forth). But even these two types of parallel work are different from one another.
For one,
management's role differs between the two. When management gets involved in transactions it is usually about exceptions, such as in the
limits of authority. Also, and because the volume of transactions is much higher than for Executive decision making, the steps are well known and cost savings from personnel and related costs can be had.
When dealing with decisions that are, by nature, less frequent than transactions, new thoughts arise on what to do as the steps proceed. This inherent unpredictability suggests the regular involvement of management, particularly since the financial consequences of poor decisions often have greater impact than transaction processing errors.
As the work load increases multiple departments can bring economies of scale There are both pros and cons to spreading tasks across multiple units for the sake of efficiency. Multiple units may mean more proficiency from repetition, as well as more horsepower in getting the work done. But they add complexity (read: cost) as well.
Closing the books is a good example. As businesses grow in size, the work required to close the books grows too. Well run companies want the books closed quickly so they can make appropriate adjustments and still impact the current month. So they naturally respond by growing the accounting staff (not many accounting shops close the books by having one person work, then another, then another). Everyone works simultaneously: parallel processing. Eventually units are formed, fixed assets increase and geographic dispersion begins. Some work is done at the business unit while other tasks occur in central services locations that might close out A/P, A/R and payroll, for example. This gets more complex - and costly - with added staff meetings, travel and so forth.
Working in parallel cuts time and cost for computerized work as well All too often, computer programmers and system designers process work in sequence when with thought, it could be done in parallel. Back when I was in foodservice distribution and ran a modern "MIS" department (today's trendier name is IT), operations was hamstrung by our batch-processing mode.
We couldn't process orders for picking in the warehouse until all orders were in by sales region. If there was a problem with one sales region, such as a downed telephone line, the warehouse was held up. This led to delivery trucks leaving late and getting snarled in rush hour traffic, leading to overtime and upset customers. This type of serial processing made little sense and ultimately we replaced the entire system for one that worked in parallel.
In summary, it's always best to consider which tasks must be completed sequentially and which can be accomplished in parallel.
The more work that can occur simultaneously, the faster the overall project can be completed.
