lean management

Overheard - IT MOOSE management

“What we’re seeing is CIOs are working very hard to reduce the cost of their operations on a per-transaction basis. They’ve done a lot of that with virtualization and data-center consolidation.” Mark McDonald, as quoted in IT After The Recession

IT demand is very strong. Companies have had to work harder than ever to make money in this environment and also to be able to drive the types of innovation that will keep customers interested in new things they’re offering. But CIOs are meeting that demand with existing IT assets rather than buying new assets.

In other words, they’re managing the IT MOOSE and they like their MOOSE lean.

Mark points out that the number of IT transactions are increasing — but not all those transactions can be directly tied to revenue.  (That reminds me. I need to log on and check my bank balance.) As the number of transactions to support $1 in revenue continue to go up, Mark predicts that CIOs will be taking a hard look at infrastructure again.

The question is…whose infrastructure will they be looking at?  Their own — or Amazon’s or EMC’s or some other cloud infrastructure-as-a-service (IaaS) provider?

Kanban - a way to visualize bottlenecks in your software development project

A Kanban Board shows the current status of all the tasks to be done within this iteration. The tasks are represented by cards (Post-It Notes), and the statuses are presented by areas on the board separated and labeled ToDo, Doing, and Done. This Kanban Board helps the team understand how they are doing well as well as what to do next and makes the team self-directing. Kenji Hiranabe, Visualizing Agile Projects using Kanban Boards

Today’s WhatIs.com word of the day is Theory of Constraints.  It’s an approach to systems management that can be used by anyone in just about any type of management field.

Let’s say you have a very simple system where components  A + B + C + D = Output.   In the 1950s, the conventional American approach would be to make sure that each component in the system was optimized to its fullest so that the total output would also be optimized to its fullest.  (Component A would be optimized, componenent B would be optimized, etc.)

The Theory of Constraints proposes that you should forget about trying to optimize each part of the system.  Instead, you should look at the system holistically and identify the weakest component in the system.  The weakest component — the constraint — will determine, ultimately, how successful the entire system is.

A constraint is a bottleneck.  It impairs or stops throughput.  Because the bottleneck ultimately rules the sucess of the entire system, THAT is what you should place your attention.  The Theory of Contraints proposes that every working system has at least one bottleneck but no more than three (or the system wouldn’t work at all).

So the question becomes, how do you identify the bottleneck?  In a manufacturing plant, you might be able to physically see the bottleneck — it might be a machine that’s backed up.  But what if the system is distributed or the one you’re managing is knowledge-based?  That’s where Kanban comes in.

Kanban is Japanese for “card.”  In manufacturing, it’s a sign or signal in an inventory control system. As supplies are used up, new supplies are requested simply by sending a re-order Kanban card to the supply point. The new supplies are being “pulled” instead of being “pushed” a la Lucy and Ethel at the candy factory.

Agile software development teams have adopted kanban as a way to track progress and identify bottlenecks in the development process.  It’s a pretty common practice to see big sticky-note charts on a wall of a project room.  Now you know the name for those charts — kanban.  And the part of the chart where the sticky notes are jammed up together and overlapping? That’s a visual representation of a constraint.

David J. Anderson explains how he uses kanban to identify bottlenecks and manage software engineering projects.