A Business Technology Place

Tag Archives: constraints

The Resource Constraint Conundrum

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

It’s the most over used term in the office.

“We have resource constraints.”

“We can’t do that project due to resource constraints.”

“We missed the time line due to resource constraints.”

The rationale behind this line of thinking is that there isn’t enough people. If we just had more people then we could do all the projects and hit all the time lines. We don’t have enough programmers. We don’t have enough architects. We don’t have enough testers. I think the excuse is just too convenient. In a way, it’s lazy.

Here’s why.

Organizations can’t employ an unlimited number of people. Even if the organization hired more programmers, it would only shift the bottleneck to another group. Think about that. If you hired three more programmers then the programmers would ultimately sit with no input because the existing business analysts couldn’t feed them work fast enough. Or the programmers output would increase so much that the QA testers would not be able to keep up with it. There has to be a slowest step. So this is an apparent conundrum. If only we could do more with less by working smarter.

A better way to think.

I find that this conversation parallels budget and financial processes. There is a finite amount of money in the budget, home or work. Is that a budget constraint? If we answer yes, then we have a mindset that there shouldn’t be limits. We should just be able to spend money whenever we want no matter the cost. The reality is that we have a set amount of money and we establish a budget as a guideline for how to spend it. The budget is what we choose to do with our money.

It's really about how we allocate what we have

It’s really about how we allocate what we have

I use that rationale for the home budget. We have X dollars each month. We choose how we will spend those X dollars. The budget isn’t a constraint. It’s a guide and a plan.

The same principle applies to people in the office. We have a set number of people on staff and a book of work to process. How we choose to allocate people to that work is our choice. It isn’t easy and requires tough decisions. But it’s a choice.

The conversation changer.

So the conversation changes from resource constraints to resource allocations. We should be talking in terms of customer retention, ROI, revenue, etc. The allocation of staff is a choice based on a plan. That’s a better conversation to have with everyone. Instead of complaints we talk about acknowledging current state and making choices.

Hiring more people or buying more equipment is always possible if the allocation of funds support it. Businesses are drawn to ROI. If the business case supports it and those in charge of managing the money believe the risk is worth taking, then the funds will be allocated. Businesses exist to make a return.

When it’s all said and done we work within the boundaries of what we have. That includes people, money, tools, equipment, and knowledge. Is that boundary a constraint? I sure hope not. I like to get stuff done!

Attacking process waste

Posted on 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.