A Business Technology Place

The Merchant Stand

Tag Archives: The Goal

Do more with less by working smarter

Posted on by Posted in Business Process Management 1 Comment

I haven’t kept count of the most commonly used phrases I’ve heard in my professional career. But “limited resources” has to be at the top and this phrase talks about people more than objects. It’s a given that there is always more work that businesses want to do than they feel like they can accomplish with the current number of people. If that were not the case then the business would let go of people to match capacity with demand.Resource Constraints

In my experience, most business leaders typically approach resource constraints by trying to hire more people or by ignoring the situation and letting the day-to-day tasks run as-is. Hiring more people is a difficult battle in most businesses and ignoring the situation certainly doesn’t provide answers.

I try to approach resource constraints by examining the underlying processes of how people work. Maybe I’m wired differently and don’t mind examining processes to find opportunties for improvement. Maybe I don’t mind fighting the battle of getting people to change existing processes. But if an organization is to work smarter, then it must examine underlying processes and not be afraid to make adjustments.

In the book Blue Ocean Strategy, Kim and Mauborgne describe this technique:

“instead of getting more resources, tipping point leaders concentrate on multiplying the value of the resources they have.”

The Theory of Constraints looks at the underlying process as well. This management paradigm teaches us to first find the constraint within a process and then to exploit the constraint by shifting resources, managing work queues, and possibly adding capacity.

At the end of the day, changing existing processes within an organization can be as difficult as justifying new hiring. But I would argue that it’s a more worthwhile endeavor. Throwing more people at some problems might provide a brute force solution. But the underlying process will eventually bog down the productive output and you’ll soon here again the infamous phrase “resource constraint”.

Find a way to multiply the value of what you have by first examining the underlying process for inefficiencies and also by making sure that underlying processes contribute to the overall goal of the organization. Easier said than done, but if it were easy then everyone would do it.

Attacking process waste

Posted on by Posted in Agile Organization, Business Process Management, eCommerce Leave a comment

I don’t like process waste.

Who does? But how many of us really try to change processes to eliminate or reduce waste? In my experience this is a tough topic, and I dare say an unwelcome one, most of the time. The problem is that in an organization processes are tied to job existence and security. So the people in charge of setting the processes and administering them really don’t see the incentive to make adjustments.

I’m nearing my 20th year of software development experience, so I’ve observed and talked to many practitioners about software development process philosophies and techniques. Process waste starts to build when the people within the organizations place more importance on the process steps (requirements, estimates, and schedules) instead of the process output. The ultimate goal of software development is to make money by producing output. Waste takes away from the output.

Business case modeling and estimates are a common area for waste.

Let me start by saying that business case modeling and estimates are a necessary part of software development. The problem arises when the business case and estimates begin to consume a large percentage of the organizations time and a large percentage of the work is rejected. All of the work becomes throw-away because it has not created a return. Ironically the entire point of the business case is to prevent waste. We don’t want our organizations to produce product that does not yield a financial return.

Think about it. If the software development team is constantly estimating and scoping projects that are not approved then it reduces the amount of usable output created for the business.

The theory of constraints is a critical teaching to understand.

The Wikipedia entry for the Theory of constraints quotes Eliyahu Goldratt.

The underlying premise of theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput.

In a perfect world, everything the software development team touches is processed into work output that generates money. We don’t live in a perfect world, but we do want the throughput of the system to be optimized. So it should produce money making output as quickly as possible. Work that is started and later thrown out is like throwing away inventory and only increases the overall operational expense of what it takes to get good output.

You have to work the constraint.

I’m a strong advocate that software development needs to focus on features, not projects. Projects are by definition unequal in size and length. Features are smaller in size, easier to understand, quicker to estimate and assist with providing more consistent system output. Bloated projects tend to have large price tags, take weeks to estimate, and are more likely to be rejected by management.

Think about the project approach. A team may spend two weeks creating a business case to review with management. Then the development team spends another two weeks estimating umpteen features. If the project is rejected then there is four weeks of effort that creates $0 of sellable output. The exercise devolves into a discussion about a single cost to build and the the time required to do so. It’s all or nothing and the focus on the goal of making sellable output is lost.

So if we want to work this particular constraint in the system then we need to evaluate each feature on its ability to achieve the end goal. Everything else is really just noise waste.  I hate waste.