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.

Scott Griffin enjoyed every minute of his 28-year career at The Boeing Company, the world's leading aerospace company with capabilities in both commercial jetliners and military aircraft. From 1999 until he retired in June 2007, Griffin was the global CIO and vice president of Boeing IT.  His responsibilities included overseeing a staff of more than 5,000 people, and spearheading all of the IT strategy, systems, infrastructure, and architecture, The collaboration between his team and Boeing engineers around the world played an integral part in the design and the manufacture of the first Boeing's 787 Dreamliner.  In fact, a chapter in Evan Rosen's book, the Culture of Collaboration, chronicles Griffin's real-time interactions with other Boeing executives.

While Griffin retired from Boeing, he has no desire to retire from IT. In fact, he is pursuing a master's degree program in not-for-profit leadership at Seattle University.  He plans to start a not-for-profit company to do pro bono IT strategy consulting for other not-for-profit organizations.  He has served on the board of the Greater Seattle Chamber of Commerce, and the Chicago Shakespeare Theater.

Recently, enterpriseleadership.org sat down with Scott Griffin to discuss his IT career at Boeing and his plans for the future. Here's what he had to say.

EL. When you talk to MBA students about IT, what leadership  qualities to your emphasize to them?

SG. I have a regular presentation about preparing MBA students to run organizations and to understand the power of IT to transform a business model. You can use a cookie cutter to stamp out CIOs who understand technology. They need to know how IT works and how to talk to business leaders about things that are important to the business.  That's number one. It made me successful at Boeing.

EL. How do  you acquire the skills that made you successful in your long career at  Boeing?

SG. I had three careers at Boeing. When I worked in customer service, we moved from paper to electronic media. Today Boeing delivers digital content to airlines around the world every day, as well as to the U.S. military. My second career was in avionics where I worked on classified software. When I joined the IT department, my third career, I understood the business process, the IT systems, and the data. I had the great fortune to be a business leader before I became an IT leader. I talked to people in the airlines, in the military and inside of Boeing.  I talked to each audience in language they understood. If the CIO doesn't have this, he or she is just a technical leader.

EL. Why did you decide to spend your retirement  years pursuing IT in the not-for-profit sector?

SG. Before I went to work for Boeing, my wife and I, both fresh out of Fresno State, moved to Seattle to work as house parents for a home for troubled teenage girls. This was my first experience dealing with a not-for-profit.  It was a truly rewarding one. The hill the home was on run down to the Boeing 747 plant. In fact, the home benefited from a Boeing fund.

I picked up Peter Drucker's book, Managing the Not-for-Profit Organization.  In it, Drucker talks about how not-for-profits have become the distinguished feature of American society. The book talks about how to get the most performance out an organization. The book ends with this profound question: What do you want to be remembered for?  That drew me back to my experience working at the not-for-profit.

EL.  How did you IT team react to your decision to retire and to go in this  direction?

SG. My staff wasn't surprised by my decision, just the timing of it. Recruiting a new CIO takes time.  We started the process five months before we announced my replacement, John Hinshaw. I still get a lot of questions about the initiatives my team started while I was CIO.  I left a well-run organization that had great people.

EL. What, if any,  reporting changes did you make to your IT organization?

SG. Before 2005, IT had a shared services model for the infrastructure group. The rest of the IT folks resided in various business across the company. In 2005, we brought everyone in IT together under one organization.  We even pulled the functional analysts in, engineers who sat on the boundary between being a design engineer and being an IT person. We needed those people because we build IT solutions for our customers. This move gave us a fresh start to figure out what was important to us. It was one of the strategies for Boeing IT.

EL. What challenges did you place driving innovation in  IT?

SG. When we looked at innovation, we always benchmarked against the top companies in the world, especially Toyota.  Concurrent design has a lot of complexity. You had people working on the same assembly, regardless if they are in Moscow or in Everett, Washington. We had these great pockets of innovation. Our money didn't match our strategy of innovation. Two- thirds of IT budget went to support the things already in place and one-third went to innovation. We created a strategy to fill this gap. We looked at how to have two-thirds go to the future and, one-third go to support the business. We were just embarking on that when I retired. .

We looked at how IT could help transform the business and innovate there, not where we thought IT was going.  This posed an interesting challenge. You need to have people thinking about how to do the business process differently. If you don't, they will become adverse to change. Unfortunately, even the best IT leaders over time can find themselves spending most of resources on improving the things already in place, not trying to create a breakthrough change the company. Collaboration became that breakthrough at Boeing.

We looked at the places where we had innovation. For example, we worked with our global suppliers as if they were part of the same company.  Cisco did this before Boeing.

We set out to work on those  areas we had ignored. I really don't want to elaborate on them. 

EL. Can you discuss the your philosophy behind your mantra to  innovate and to inspire?

SG. Inspire deals with who are the people looking for the change.  Is it the IT team?  No CIO is smart enough to know which inflection points are real, which are flash in the pan, and which IT company has the next great thing. You have to energize your entire team to work on these issues. When you inspire, you begin to remove the obstacles for the experts to do innovation. My leadership team spent a lot of time thinking about what people can really inspire other. We looked for a certain leadership style, which focuses on breaking down walls for your team so they can be most effective rather than leading the charge.

EL. What did you do to inspire  future IT leaders?

SG. This's one of the top roles of the CIO. It's the reason I was able to retire and to shift in providing IT to the nonprofit sector. You can judge the effectiveness of the former CIO by looking at the future leaders that CIO groomed. I can tell you the list of potential CIOs and why I selected them.
We had some great programs.  Every week the entire IT team, people located in about 60 countries, attended a virtual IT staff meeting. Our executive skills team met every week. We asked staff managers to ponder these questions: Who are our future leaders? What does the pipeline look like?  How diverse is it?

EL. How did you select candidates  for Boeing IT University?

SG. To look for candidates to attend the Boeing IT University, we would comb the pipeline for managers who had the potential to be executives, and staff people who had the potential to technical leaders. The program doesn't use university professors, but IT leaders teaching potential leaders. The curriculum consists of spending eight, 24-hour days discussing what  challenges face Boeing, how do these challenges translate to Boeing IT, and how these future leaders can contribute to the strategies of innovate and inspire. We give the participants a graduate-level case study, which we created. It presents the what if scenario about Boeing acquiring a company.  The participants must work through migrating the company into the existing IT structure. Using actual data and strategies from Boeing, participants, at the end of the week, have to give a present their findings to a board of directors comprised of the IT leader instructors. This experience has changed the way we relate the people in that pipeline. We get to know these future leaders. In turn, they have a safe place where they can present their ideas. They also write a business case. to do an ERP implementation.

EL. Do you use the center for excellence concept to fuel new  ideas?

SG. It's not a strategy for us. Most of my colleagues with centers of excellence didn't have a consolidated IT organization. We had the center for excellence strategy when IT was decentralized throughout the company. At that time, we said let's create and fund centrally a center of excellence for manufacturing engineering. Once we got all of the IT folks together, we still called them centers of excellence. I don't want to say that concept isn't a good strategy. Now the people who do manufacturing engineering systems now work on the same team as Boeing IT. Together, we begin to create the future process, systems, and data for those functions.

EL. Can  you describe how the Investment Board came about at Boeing?

SG. After the merger with McDonnell Douglas, we started to think about how we could move Boeing to common processes and where it makes sense for common systems. We couldn't do that if every cubicle had its own IT leader.  We had a shared services model where all of the transactional activities existed. The systems resided in the business unit.  If we wanted to move to common processes, we didn't have the right governance model. We didn't have our hands on the people that were learning today's systems and planning for tomorrow.

Our first move was to pull the IT people together. That was a lot of work. It presented all sorts of cultural challenges. We had shadow organizations all over the place. We had to change people's budgets so they couldn't create shadow organizations.

The 2B model was the IT investment portfolio. I made the decision that I shouldn't chair that. The CTO for Boeing assumed this responsibility We invited all of those businesses who owned their own IT, such as a design engineer on the 787 program on the 787 project had his/her own IT department. We pulled those people away. We offered to make the leader sit on the Investment Board.  Once we got the IT people and the functional leaders together, we could decide what investments we would make with Boeing's IT dollars. We were in the third year of it when I retired.

EL. What  changes did you make to the governance model because of the Investment Board.

SG. The governance model was slow to change. The functional leaders would come together on the front end and say, 'My program is totally unique from everyone's.' We weren't interested in having a discussion about building one ERP system. We rejected more than a $100 million dollars worth of good projects not aimed at the entire Boeing Company. When I left, that model had completely changed. We were still having an Investment Board meeting once a quarter. When people came to us, they knew that their project wouldn't be approved unless they had taken into account the entire Boeing Company.

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