Currently Being Moderated

MichaelHugos.jpg

 

If you ask a global CIO like Gary Cantrell of Textron to name you one of his goals for 2008, he'll tell you he wants his IT organization to become more agile. No one knows more about what Cantrell is trying to do than Michael Hugos.  Up until 2006, Hugos was the corporate CIO at Network Services Company, an $8 billion cooperative distributor of janitorial products and disposable food services items. He received a CIO magazine 100 Award in both 2003 and 2005 for improving the agility of Network Services' supply chain initiatives. He also received an InformationWeek 500 award in 2005 for innovative use of an IT wholesale distribution system.

 

Hugos now sports the titles of business agility mentor and CIO-at-large to several companies. He also writes books about supply chain management and business agility. The second edition of Essentials of Supply Chain has become the top selling book in its class on amazon.com. He recently published The Great Innovation Since the Assembly Line -- Powerful Strategies for Business Agility. In addition to writing books, Hugos often writes about agility in his Computerworld column and on his CIO magazine blog. He also conducts workshops on what he calls the 30-Day Blitz to becoming agile.

 

enterpriseleadership.org recently sat down with Michael Hugos to get a better understanding of business agility and IT agility.  Here's what he had to say:

 

EL: What exactly is agility and why what does it  offer an organization?

 

MH: Agility applies to a wider range of activities. Just as lean manufacturing advocates using easily reconfigured machines in flexible production sequences, agile methods advise the use of short and iterative development cycles for rapid response to changing conditions and customer demands. Agility also places a greater focus on customer satisfaction rather than internal operating efficiency.

 

EL: Can you explain what it  means for an organization to be lean and what is the relationship between lean  and agile?

MH: Lean grew out of the popular manufacturing principles in the Toyota Production System and Just-in-Time manufacturing process. It emphasizes two things: the elimination of non-value added activities that customers don’t pay you for, and the elimination of wait times where products or work in progress accumulates and waits. These ideas relate mostly to manufacturing or supply chain processes. However, lean also advocates ideas that overlap a lot with agility. For example, a rapid response to changing customer demands can occur through using appropriately sized and easily reconfigured machines, and placing those machines in flexible production sequences that can change quickly as situations change. These are very much agile ideas. 

 

EL: Apparently,  supply chain experts have merged lean and agility to create leagility.  What's  the story behind this term?

MH: Leagility applies mostly to the operations of lean and agile supply chains. We can discuss these concepts well enough with the words lean and agile. By making up a new word like leagility, you create more confusion in the discussion.

EL: What are some  of the characteristics of companies that are either agile or lean and agile?

 

MH: Lean and agile companies display a handful of key characteristics. The most important characteristics include decentralized decision making procedures, and individuals and autonomous operating units that are empowered to decide and to act on their own initiative. At lean and agile companies, senior management makes the goals clear to everyone, and trains and trusts employee to do the right things to accomplish those goals.

 

These characteristics have become necessary for agility. Why! We live in a world where things change quickly. People at the scene of the action need to assess events and act quickly in order to be agile. If they're required to pass information up the chain of command and wait for orders before they can act, they won't respond effectively because situations will change while they are waiting for orders. Opportunities will disappear. People will become frustrated and passive. This scenario creates the inertia and lethargic behavior that bureaucracies are so famous for.

 

EL: Can you provide  an example of an organization that has done a super job of becoming both lean  and agile?

 

MH: The United States Marine has done a good job of becoming both a lean and an agile organization. Its basic tactical unit consists of the 20 to 40 person autonomous platoon. Specific platoons of infantry, artillery, and armor become task forces to handle specific assignments. The commander issues mission orders which spell out what the platoon must do to accomplish its assignment. The senior commander doesn't tell people how to do their jobs. People closest to the scene have been trained and are trusted to figure out how to do what the commander wants, without asking permission before they act.

 

I'll admit business isn't war. Business creates opportunities; war destroys. You can learn many lessons for business by analyzing successful military operations. I've learned a lot about agility from reading U.S. Marine Corps' 110-page book called Warfighting. Everyone from the Commandant of the Marines to the newest recruit has to read and live by this book.

 

EL: When it comes to  agility, what company has a lot in common with the U.S. Marine  Corps?

 

MH: Both Whole Foods Market and the US Marines -- two very successful organizations -- use very similar operating models. They both consist of small, autonomous operating units, empowered to act on their own initiative. Senior management in both organizations says what they want but does not micromanage. Instead, they train and trust their people to figure out how to do their jobs. These two organizations come from very different lines of business and very different world philosophies.  Because they have both independently arrived at similar operating models, you can easily conclude that there some universal truths about agility and the way effective agile organizations operate.

 

EL: What are some of  the hurdles an IT organization has to overcome if it wants to improve its  agility?

 

MH: It needs to overcome three big interconnected and self-reinforcing hurdles, which are tough to break down. These hurdles include the tendency to use bureaucratic organization structures and operating procedures; the tendency to engage in long development cycles that last between 18 to -36 months, and the tendency to design and build very complex systems.

 

For centuries, people have used the bureaucratic operating model. Most companies today use this model, not just IT departments. Bureaucracies work well in situations which don't change that much. They can handle lots of details and complexity, and produce predictable results. Problems arise when we try to use the bureaucratic operating model to deal with situations that change all the time. The rapid pace of change can easily overwhelm these bureaucracies. They react by trying to slow things down. They become even more rigid and intransigent. IT and business must cope with rapid change. The rigid bureaucratic behavior of many IT groups really drives business people nuts. IT needs to adopt a decentralized and flexible operating model.

 

EL: What are some of the  programs with long system development?

 

MH: Traditionally people have the tendency to engage in long system development. Long development cycles work when things don’t change much, but they don’t work well in high change environments. The bureaucratic process don't respond very well to change, especially for the waterfall approach of collecting requirements, creating system specifications and then implementing the system. People first spend three to six months analyzing situations and collecting requirements. They next spend another 12 to 24 months developing systems or selecting and implementing packaged solutions.

 

During this time, significant changes will occur, and business people will want to come back and alter the system requirements to reflect the changes. This process starts up a whole dysfunctional cycle of behavior where bureaucratic IT project organizations resist the change requests, business people resent being put off, and nobody is happy. Because business people have a lot of political power and influence, IT usually gets the blame for whatever happens. IT needs to be able to get things done in shorter periods to respond well to change.

 

EL: So how do you deal  with the complexity hurdle?

 

MH: Because we organize ourselves in hierarchical bureaucracies, we then use bureaucratic procedures to do analysis and requirements gathering. We spend months analyzing things. And the more we analyze things, the more complexity we find, the more complexity we build into the specifications for the system we're developing. We become overwhelmed and intimidated by the apparent complexity. We attempt to design systems that can handle every eventuality, no matter how rarely it may occur. This practice leads to specifications for a very complex system, which you can't build on time or on budget. We need to work in shorter development cycles and deliver working systems that address the most pressing problems first, instead of trying to solve all problems at the same time.

 

EL: You say that an agile  organization is one with a network organization. Can you briefly explain?

 

MH: Agile organizations have a network organizational structure. It provides the best way for autonomous operating units to act quickly on their own initiative, to coordinate their activities with each other, and to deliver benefits for the entire organization. Network organization structures can make best use of an agile operating dynamic.

 

Traditional pyramid shaped hierarchies just move too slowly. They restrict decision making to those at the top of the pyramid. Since those people are several levels removed from the action, it takes them a while to analyze the reports they get and understand what is happening and then issue their orders. Merely putting in expensive business intelligence and reporting systems does not shorten the decision cycle enough or make the decisions that are made much more effective. Since the people who have to carry out the decisions where not involved in making them, people often make a half-hearted attempt to carry them out. To counter this tendency senior management often indulges in micromanagement of lower levels which only reinforces the dynamic because people have no initiative to think for themselves and are reduced to merely following orders.

 

EL: Many CIOs use metrics from scorecards, such as the Balanced Scorecard, to evaluate the effectiveness of IT process. What criteria (such as number of projects done on time, or number of projects done on budget) does an agile IT organization measure?

 

MH: As CIO at Network Services Company, I developed a suite of e-business and supply chain systems that we developed and iteratively enhanced for several years. The project office produced a simple set of weekly reports and scorecards that enabled me, as well as everyone else in the company, to track progress on projects and our performance against budgets. I needed to know how projects were doing as they progressed. I needed to see early on if problems had developed so I could get involved when necessary. Reporting should enable effective intervention and mid-course correction, not just keep score.  You shouldn't measure things, such as the number of projects done on budget, if they don't have any value to the business people who use the systems.

 

Author: Elizabeth M. Ferrarini - She is a technology writer  from Boston, Massachusetts. Reach her at elizabethferrarini@yahoo.com.

| More
1,250 Views Tags: agility, article, business_intelligence, innovation, metrics, strategy


There are no comments on this post

Actions

Bookmarked By (0)