Archive for November, 2011

The Case of the Disturbing MBO Business Processes

Posted November 29, 2011 By Fletcher Groves

I recently finished writing a management case study, the subject of which is our firm’s mapping of the current state of the application-to-investor sale process for the mortgage banking operation of a community bank.

The bank is a client of ours, and the case study stems from our work performed on their behalf; the focus of the study is on the current state of that process, so it does not delve into the solutions from the subsequent redesign effort (in any event, that information would be proprietary).

I wrote the case study, because it strikes me, that, although this bank’s situation is hardly unique in terms of the current state of its processes, its situation will conger disturbing thoughts about the condition of business processes in any enterprise.

As with most case studies, it is a bit lengthy for casual reading. But – it is a worthwhile read if you want to understand how good process analysis works, understand where good process redesign and improvement starts, and understand the financial cost of all the waste, uncertainty, and variation found in the design of the workflow of the processes that most of us have to use, every day.

You can download the full case study at, but here is some of what it has to say:

These comments on the financial cost of process variation:

  • Almost every loan application that was opened (93%) was sent to Underwriting, but only about one-third (38%) ever made it to the Closing stage. Underwriting wasted about half of its current capacity. Processing wasted about one-third of its capacity. That is a significant amount of wasted capacity.
  • The financial cost associated with that waste, whether viewed as the lost Contribution (Gross Income) from the sales of loans that the operation could have closed (if it wasn’t consuming its time and effort on loan applications that cancelled), or as the cost of the production capacity (in the form of overhead) that was not utilized (and, therefore, an unnecessary expense).
  • The annual payroll, advertising, and administrative/processing expense for the mortgage banking operation was projected at about $5.4 million per year. If the case was made for, say, a 12% allowance related to unavoidable cancellations [i.e., an 88% pass-through rate], that would only push the conversion rate from the 38% range to the 50% range [88% – 38% = 50%]. There were only two possible conclusions: Going forward, either the mortgage banking operation would have to live with $2.7 million in excess, unused capacity – capacity that it didn’t need – or, it would face the prospect of giving up the Gross Income from the closings that it failed to get through the system.
  • During 2010, there was a total of 1,193 loans submitted to Underwriting. If unavoidable cancellations were 12% of the loans that made it to Underwriting, the operation would have still closed 1,050 loans. But, there were only 450 actual closings. The difference [600 closings] corresponded to the additional 50% cancellation rate that was avoidable – therefore, preventable – and, therefore, either wasted capacity or lost throughput. Using the [bank’s] forecast assumptions of $185,000 average loan, and an average Gross Margin of 3.2%, the 600 lost closings had cost the bank about $3.6 million in Gross Income that year.
  • There were a range of issues that had caused loan applications to cancel, but a percentage of any cancellation rate is preventable, and the cost of preventable cancellations, whether measured in the cost of wasted loan production capacity or in lost income, is likewise preventable.

These observations on process lead time:

  • In the engagement letter for this project, there was “an expressed determination that the cycle time for the Application-to-Close process should not exceed 25 business days”. That was the only measure of performance for the redesigned process that was discussed. That duration of lead time was a target, not an indication of the duration of lead time for the current process.
  • We looked at the 2010 operating data, and determined what the level of applications-in-process would have been, with the reported throughput, under the assumption of achieving the targeted 25 day lead time. The lead time – for any process – can be calculated according to the following formula [universally known in production physics as Little’s Law]:  Lead Time = (Units-in Process/Units Completed) x Daysn.
  • Presuming that every loan application passed to Closing eventually closes, there were 450 closings throughout 2010. Therefore, if n = 360:

(X/450) x 360 = 25

X = (25 x 450)/360

X = 31

  • The indicated inventory (applications-in-process) that the process should have been working on to produce 450 annual loan closings with a lead time of 25 days was 31 applications-in-process. However, there was an average of 299 applications being acted on – being passed between different stages of the process – at any point in time during 2010.
  • It was impossible, therefore, for the current process to be achieving the targeted lead time of 25 days.

To be fair, the level of average inventory in 2010 wasn’t likely the 299 applications-in-process indicated, either, because that would have meant the calculated lead time for an application going through this process would be almost 240 days.

If there was, as indicated by the operating data, a progressive decline in the number of actions being taken as applications moved downstream in the process, then a very rough average level of inventory for the overall process could be estimated from the average number of actions that occurred at the front-end and the back-end of the process.

In 2010, there was an average of 107 opening actions each month. There was an average of 38 closing actions. The averages were 72 actions and 450 closings:  (72/450) x 360 = 58 days

Then again, calculated as the monthly lead time based on the average number of loan closings indicated each month (38 closings), a 60 day lead time would have had 76 applications-in-process; a 90 day lead time would have had 114 applications-in-process.

What was the true level of applications-in-process? Who knows? The truth was, the system so distorted the metrics, that it could not even determine the number of applications-in-process.

Then, there were the following comments on the characteristics of the process associated with little or no added value:

  • In a process that is intended to take only 25 days to complete, there are at least 39 instances when the work of one person (or department) is handed off to another person or department.
  • There were 29 instances when the completed work of one person or department was subjected to the review, inspection, or approval of a different person or department.
  • Characteristic of the process was the iterative, piecemeal review approach to gathering additional documentation, looking for missing documentation, and meeting other requirements. The process constantly – repeatedly – reached back and checked to be sure that it had everything, checked to make sure everything was right.
  • It became an excuse for not getting the work completed and done right the first time;
  • It promoted multi-tasking, because applications were never really completed.
  • It prevented major rework, but it slowed the process.

Because it slowed the process, it also reduced throughput, lengthened lead time, delayed closings, kept too many applications-in-process, and consumed resources.

Finally, this set of observations, culled from the case study’s epilogue:

The analysis of the current state included the time-consuming task of flowcharting the actual workflow, which confirmed that the only existing documentation of the process was a transcribed outline that the senior-most manager in the mortgage banking operation had sketched on a large erasable board in one of the break rooms.

This was a community bank, but it was not a small banking operation. Yet – all this mortgage banking operation had to show for its existing process was an outline of the management-prescribed workflow that SAI had to transcribe from a whiteboard.

There was never any relevant, reliable operating data available from the process, at any time during the AS-IS.

Following the dissemination of the AS-IS Report, as the project was reconvened to begin the SHOULD-BE element, the first order of business the team undertook was to reverse the illogical order of the process, in which loan applications were completely underwritten before the applications were ever processed.

The revealing part, was that this action flowed from the insight gained during the AS-IS and was arrived at completely ad hoc, before the formal redesign work began.

The team members had taken it upon themselves, in informal, unstructured conversations and dealings, to consider elements of logical process design; they walked into the SHOULD-BE session, prepared to act on what they had seen during the AS-IS.

After all, it was the team members who performed the actual process work, not the managers. The team members could see the problems. They knew – intuitively, instinctively – that loans couldn’t be underwritten before the application was even processed. They could see the stakeholder benefits – to the borrower, the investor, the bank, and to themselves – of having a redesigned and improved process.

The team members understood the benefits of doing more and better with the same or less – more loans funded and sold, more revenue, better results, produced with the same or fewer resources, in less time, with fewer errors, with less pointless effort, with greater satisfaction and less frustration.


Charter Homes & Neighborhoods’ Seeds of Success

Posted November 4, 2011 By Fletcher Groves

It’s always good to see your clients recognized for their achievements. For 2011, Charter Homes & Neighborhoods won its second silver National Housing Quality award, an accomplishment that is highlighted in the November issue of Professional Builder. Beyond the sheer effort and determination required to win multiple NHQ awards, the notable part is that the seeds of Charter’s success were sown more than a dozen years ago, and the company has remained true to that strategy and vision.

SAI Consulting was fortunate to participate in the development of that vision and strategy. In 1998, Charter became the third homebuilder client in SAI’s fledgling consulting practice in the res-con vertical (our second builder client was Jagoe Homes, which was named PB 2010 Builder of the Year). Before the back-to-back engagements with Jagoe and Charter, Service and Administrative Institute (as it was then known) was a TQM consulting practice, operating mostly in the transportation, logistics, steel, and aggregates spaces.

Ostensibly, our engagement with Charter was about business process improvement, but improving operating performance and business outcomes does not restrict itself to matters of process and workflow. As we always point out – to every client, at the beginning of every engagement – processes are not the only issue, they are not the only opportunity, nor are they the only answer; processes are a piece of the puzzle.

We encouraged Charter to go further, to take a hard and open look at the other parts of its operating model, to match that integrated operating model to the requirements of a specific band of the homebuyer value spectrum, and to look at how team performance was rewarded and compensated. We advised Charter to subordinate some of its policies and beliefs in those areas to the outcomes targeted in this and future projects. We told them that process mapping – focusing on the design, documentation, and improvement of workflow – tends to be a catalyst that drives the effort into other needed areas.

In keeping with the advice we offered, Charter produced an implementation plan with 15 initiatives, formed from a set of business performance and operating requirements – things that had to happen, things that needed to change – all flowing from the work performed in mapping their process workflow. I recently spoke with Charter’s President and CEO, Rob Bowman, about the long-term results of what Charter, at the time, termed “a look into the future, and a vision of pursuing excellence”. Looking back, over this many years, it is remarkable how closely the PB article and the discussion with Bowman track to the outcomes envisioned.

For example, Charter implemented a plan to mold its operating model – its processes, systems, organizational structure, culture, and human resource talent – around the implicit promise to deliver a “best product” value proposition. “It is still very much the focus of what we do”, said Bowman. The company also revamped its organizational structure around horizontal workgroups, instead of the existing functional hierarchy. “We are still organized that way, right down to the team names”, he said. To that end, Charter converted its entire sales force from outside real estate brokers to associates that are employees of the company, a move that was required in order to have the community-focused building team that Charter wanted in its organizational structure.

Charter also established the process for gathering and analyzing detailed data, information, and research on the expectations, requirements, and buying decision of targeted buyers, which directly led to and enabled the company’s “Ready Now” program of offering a conservative number of inventory homes for sale. In that regard, Professional Builder described Charter as a “design-data-driven organization”, an approach Bowman says Charter has “stayed with consistently”.

“The NHQ award is a point on a long [and perhaps, never-ending] journey”, Bowman said. “We see the award for the significant accomplishment that it is and represents, and an achievement in which we have a lot of pride and satisfaction. But, we are also keenly aware that we have a long way still to go.

“Whatever else you say about us”, Bowman told me, “communicate the humility that comes from knowing that we are not there yet. We do think, however, that what we have managed to accomplish began with the process focus that we had in 1998.”

In times like the past five years, you look for the lights that shine in the darkness. Everything that Patrick O’Toole (and the NHQ judges) write about this company is true. In 1998, Charter made up its mind about what its value proposition would be, and designed a value discipline around it. Having made up its mind, the company consistently stayed with the strategy.

Charter Homes & Neighborhoods, congratulations – well-done, richly-deserved.


The Spectrum of Workflow

Posted November 1, 2011 By Fletcher Groves

[Note: As an enterprise, before you start trying to improve the quality and productive output of workflow, you need to figure out what kind of workflow you face. Below, the enhanced excerpts from our recent counsel to a web services company seeking to elevate the level of enterprise workflow consciousness.]


Our advice is to start the effort by determining where [your company’s] operations fit on the spectrum of workflow.

The most basic – the most universal – proposition of business is simply this: The reason for an enterprise’s existence, the way it makes money – is through the value that it delivers to customers and other stakeholders. That value is only delivered by the work that the enterprise performs, and that work has to be performed in some method of workflow.

Those methods exist, whether enterprises are intentional about them or not. In our view, those methods are descriptively termed process management, project management, and case management. We used to not draw the distinction.

We used to say that workflow was all about processes – that workflow was synonymous with process; to a degree, that will always be true. In fact, we used to state the sequence of our proposition underlying business process improvement as value-work-process. But, the workflow spectrum is broad, and a single approach will not fit every enterprise situation, will not singularly fit every industry space. By necessity, workflow solutions are becoming more industry-specific, often more enterprise-specific; that is particularly the situation when it comes to the applications that interact with – and enable – the workflow.

Ironically, as the workflow spectrum has broadened and the applications have become more specific, most enterprises find themselves in need of addressing all three methods.


PROJECT MANAGEMENT: In residential construction – which is SAI’s primary vertical – workflow is project management with embedded, repeatable processes; homebuilding companies are primarily Project Management Organizations (PMO), and they are multi-project, which really makes them Project Portfolio Management Organizations (PPMO).

Project management has long timeframes with a lot of task dependency and resource contention; although individual projects (jobs) have similarities, their work breakdown structures can vary significantly, depending on the project requirements. So, they tend to be treated as individual projects managed in a portfolio. A PMO schedules projects, not the process.


PROCESS MANAGEMENT: On the other hand, the operations of manufacturing companies are essentially about process management – continuous flow, sometimes single-piece, very repetitive, very definable, very standardized, often, very transactional. We choose to differentiate between cross-functional workflow – which I refer to as processes – and workflow performed in sequence by one person or department, which I prefer to call procedures.

And, we choose to differentiate between processes (documented in process models), which are intended to provide an in-depth, largely internal understanding of workflow, and value streams (documented in value stream maps), which are intended to provide an external, higher-level view of workflow, resource capacity, material flow, and information flow.

Having drawn those distinctions – processes, procedures, and value streams are of the same genre; project management is a different animal, and process-centered enterprises have workflow management requirements that are distinct from those of a PMO. If you place process management and project management on a spectrum, they tend to be at opposite ends of that spectrum. In terms of automating workflow steps – obviously not the entire distinction – some process steps can be automated, but project tasks usually cannot.


CASE MANAGEMENT: Then, there is the emerging discipline of case management, which is not really on the single plane/spectrum with processes and project management. In a sense, process, case, and project management triangulate. They are distinct. To be sure, case management has been around a long time in certain industry verticals, such as healthcare, insurance, and legal; it is extending into additional segments. And, case management is becoming an alternative to a pure process approach. The primary distinction – and argument – for case management is in what Bruce Silver (Bruce Silver Associates) describes as case management’s “unstructured progression” of workflow, situations that are more ad-hoc (as opposed to pre-defined).

Case management also applies to workflow situations that are more document-intense (as opposed to data-intense); to situations that share documents in the same folder; to situations that require real-time collaboration (as opposed to a more defined sequence); and to situations that involve physically separated, remote, and independent resources.

From an automation standpoint, some of the sub-processes in case management can be automated, in fact, automation probably offers the biggest overlap between process management and case management; process management and case management use the same execution language (i.e., XML, XPDL, BPEL export), and they will likely link to Business Process Management Notation (BPMN) as the standard.


The applications that support process management, case management, and project management are very distinct. Our recommendation would be to figure out which type of workflow you are managing, before you start to consider the application that you need.

We don’t know what situation [your company] is facing, or which scenario would best define its workflow. But, you should start with making that distinction. Start with the context.

That would be our advice.