Insight # 7 : Pulling Together : Lean, Six Sigma, and Project Management

The Practice : Instilling Lean into IT

by Carl Dalby

According to recent data, information technology projects can use all the help they can get. A 2007 survey by Tata Consulting found that 62 percent of organizations had IT projects that failed to meet their schedules. Nearly half suffered from budget overruns and had higher-than-expected maintenance costs. Forty one percent failed to deliver the expected business value and ROI, and third failed to perform against expectations. A study by the National Institute of Standards and Technology found that eight out of every 10 dollars in development costs is spent identifying and correcting defects. The infamous Standish "Chaos Reports" found that while 32 percent of projects succeeded, another 24 percent failed and 44 percent were "challenged." Mercer Consulting concluded that "as many as 80 percent of technology projects actually cost more than they return."

While the overall picture may be grim, we've found that applying principles culled from the lean practices of engineering project management will yield significant improvement for IT projects.

Think about the engineering program environment. It's highly competitive and always has a "back to the wall" mentality. The business is high volume and low margin with massive investment requirements. Products frequently have thousands of components, making them highly complex. There's no room for error and a laser focus on cost management. Plus, engineering projects pursue the bleeding edge of disciplined delivery, among which Lean is a key philosophy and defines market leadership.

A Crash Course on Lean

Lean - evolved and formalized by manufacturing companies in post-war Japan - has a few key objectives. The overall philosophy is to design out overburden (muri) and inconsistency (mura) and eliminate waste (muda) through long-term, sustainable, evolutionary, and continuous improvement. The thinking is that following the right process will produce the right results and that developing people and partners will add value to the organization. That focus on continuous improvement results in unremitting attention to solving root problems and driving organizational learning - the company and its people will be smarter today about what they're doing than they were yesterday.

Lean principles touch on four areas of operation : processes and systems, quality management, the organization and its people, and change management. Under Lean, the philosophy of change management requires a long-term view, it's evolutionary, it calls for thorough evaluation but fast implementation, and it requires collaboration with partners.

The organization requires effective leadership and a willingness to continually learn. Its people believe in teamwork and collaboration. Teams or "modules" typically consist of only four or five people. Success is based on the team, not on the individual. Lean calls for the company to grow leaders who thoroughly understand the work, live the philosophy, and have a willingness to teach it to others - because without constant attention, the principles will fade and become far less effective.

Quality management calls for continuous improvement to drive out waste, a commitment to zero defects (which means that anybody on the line can stop the line if he or she finds a problem), getting work done right the first time, and using visual control to know what is going on.

In the area of process and systems, Lean calls for continuous process flow, workload balancing, standardization, demand-driven systems, and user-driven technology.

Lean Principles in Engineering

Applying Lean in engineering calls for five driving principles:

  • Simplification, which is manifested in areas such as production rationalization, component standardization, and product differentiation late in the process.
  • Elimination of waste, which you'll see in centralization of inventory and the practice of driving out non-value added activities.
  • A balanced production throughput, whereby demand is matched with supply and resources - people and plants - are expected to be flexible.
  • Continuous improvement, which calls for an involved workforce, visible performance management, disciplined implementation, and a work environment organized for success.
  • Quality at the source, whereby quality is built into the entire process, not just at the end, and where there are instant feedback mechanisms.

So how do you redirect those engineering principles to achieving success with Lean in IT? Some elements are the same and some are unique to the functions of data center infrastructure design or software development. They are:

  • A structured and disciplined approach.
  • Process-driven practices.
  • Adherence to continuous improvement.
  • Carry-over engineering, whereby practices in one area are applied to other areas.
  • Test to destruction, where the point of catastrophic failure is measured and known.
  • Visibility at the project and program level.
  • Pursuit of a data-driven culture.
  • Decision-based governance.
  • The linkage of plans to specifications and scope.

Lean for both disciplines calls for economy and efficiency and using no more resources than are necessary. The goal is to design for sturdiness and durability, to show clear thought and common sense, and to build systems that recover from unexpected conditions during operation.

Yet, frequently, IT practitioners display behaviors that degrade or even destroy an organization's ability to deliver complex programs:

  • Meeting paralysis leaves no time for "real work."
  • Access to executive calendars becomes the default program critical path.
  • Organizational "chimneys" block progress.
  • A lack of clear responsibility or accountability results in parallel and wasted effort.
  • A lack of visibility and control leads to subjective reformatting and interpretation of reports.
  • Participants have an inability to identify critical program work or to align their efforts to it.
  • Managers have an inability to control change or to prevent unauthorized work.
  • There is little or no continuous improvement ethos supported by metrics that bring to life onward progression - the mantra "we've always done it this way" prevails.

Leading IT to Success with Lean

In our experience, achieving Lean in IT requires pursuit of four broad goals:

  • To set up projects for success by driving a single source for project communications and data and driving an integrated team approach to project deliverables.
  • To set up management and information processes to deliver simple, efficient, repeatable, and global capabilities.
  • To drive project operations and continuous improvements. This encompasses two key principles : 1) Access to relevant information by delivering reports and data to the right level of decision authority and decreasing decision cycle time and increasing organizational throughput; and 2) Focus on activities that only add value by eliminating the cause of problems and subsequent re-work and focusing expertise on the critical work that offers the most value add.
  • To develop an integrated program team. This has many aspects : to integrate teams across cultures and organizations; to drive common standards in tools, processes, and reporting; to get people together in order to align teams and enable continuous improvement; to organize project meetings to work across geographies, organizations, and functions; and to drive collaboration by implementing module team structures across interdependent stakeholders whose work is then integrated.

The IT organization must adhere to some key principles:

  • There's a clear, lean cycle of governance and escalation.
  • Decisions can be made at the lowest level by fully empowered decision-makers. If something isn't perfect at that level, the individual can "stop the production line."
  • Processes follow discipline to be repeatable, which, in turn, builds visibility and confidence.
  • A few key metrics bring visibility of what matters and helps direct energy into delivering continuous improvement in critical areas.
  • Meetings are agenda-driven and focused on specific deliverables and outcomes. Their overhead is minimized to allow for critical program work.
  • Vendors and stakeholders are integrated into a collaborative structure.
  • Project tools, while essential, must be simple and integrated. Also they must be designed to feed issues, risks, and action reports to participants and leadership. What they produce must be trusted by all.

As you might infer, program management is an important component in achieving Lean IT. Project management and its enabling technologies drive the flow of quality data to enable fact-based decision-making and robust communication that can be filtered for specific organizational roles. A robust program governance program can drive the reviews to manage and control project changes.

How does governance play out in real life? One way is through the efficient use of meetings. Let's say you're managing a development team. During the course of your week, you have multiple meetings about the application being created. (See Figure 1.) On Monday your team might hold an operating communications meeting with an agenda that includes : module checks, a draft agenda for the upcoming module integration meeting, and a draft steering agenda. The teams can refine the draft agendas for meetings taking place later in the week, thereby noting, minimizing, or eliminating potential gotchas.

On Tuesday, each member of the development crew participates in his or her own module meeting to report on progress and issues.

By Wednesday, the agenda for the module integration meeting is finalized and distributed.

On Thursday, the module integration meeting takes place between all teams contributing to the overall IT project and those that are affected by the project - such as human resources, finance, and sales and marketing. The agenda briskly works through plans, risks, issues, decisions, and gateway status. On that same day, data is frozen in order to integrate all program status.

By Friday, reports are produced and distributed and the steering meeting agenda is finalized. That meeting takes place the following Wednesday. This is where larger problems are escalated and decisions made on how to proceed.

Buffers between each escalation level allow teams to prepare and present with quality data and confidence.

Figure 1

Figure 1 : A robust governance cadence keeps participants apprised of status and work constantly moving forward.

To expedite cross-functional work, we've found it useful to bring representatives from departments with tangential interest in the project together into a core functions module team. For example, that might include participants from IT, HR, finance, sales, manufacturing, and purchasing. At regular points in the process that team will interact with the program development team in their own sets of meetings.

Throughout the entire program, governance is structured to bring visibility and control to the process to enable the delivery of plans and to address issues at the module level.

Structuring for Success

We have found that structuring for success requires building up the delivery capability of IT, reaching outside of silos to span functions in order to gain an end-to-end view of the business, and driving consistency by continually building leadership throughout the organization. There may be aspects of this endeavor that the organization can achieve on its own and others that will require outside expertise to help attain.

Engineering has a stronger record on successful program delivery than the IT industry. That's not because engineering projects are inherently easier, but because the engineering industry has learned Lean lessons that could be applied to IT programs : focused management, exception management, waste reduction, effective metrics, and enabling technology. As Lean-instilled companies have proven, following the right process will produce the right results and developing people and partners will add value to the organization.