Stay tuned as the programme of the conference will be published in May.

In 10 years, Agile development has proven its efficiency but still has a long way to go before perfectly meeting the business expectations.
CIOs, IT managers and IT project managers will discover how lean management helps agile development reach a new frontier: Design the right products, deliver at the expected time and create a competitive advantage for the company.

French speaking Master class, more information and registration in French l’Institut Lean France.

This quote is taken from one of our clients (the CEO of a large European bank), expressing his frustration with IT projects during our first meeting.
A ccording to a famous study by the Standish Group, this phenomenon is not just widespread; it is systemic. On average, only 29% of IT projects commissioned by businesses succeed. In large firms, this ratio drops to 9%. Budgets are exceeded, deadlines are missed (possibly bringing down penalties on the firm), and quality suffers. In some cases the system is even rejected at the end of the project, because it no longer satisfies the client’s requirements.

We are improving, but too slowly. Without a radical change in the way we manage IT projects, in two generations we might be able to succeed on the first try…with a bit of luck.
The study also tells us that more than half of IT projects end up costing twice as much as their initial estimates. Naturally, this figure does not include the extra costs associated with lost opportunities, which are difficult to measure but could easily run to millions of euros. Closer to home, I analyzed a sample of 20 medium to large IT projects lasting months to years, and saw a similar problem in project lead times: delays of 30% to 100% compared to the original deadlines.
Project lead time is defined as the period between the date a client requests a product and the date she accepts it as completed.

Adding to the problem of delays, we have the complaints of IT directors: “Our IT projects lack transparency”, “Our teams are badly organized”, and last but not least, “It feels as if we are always in crisis mode. Every day we’re putting out fires, dealing with the demands of unhappy clients.”:
Observing the operations of IT teams in the field (or in the “Gemba” as we say in the lean world), we find that certain problems occur over and over:
• Reliance on formal specifications, without a clear understanding of the client’s problems
• Fragmented vision of the project
• Lack of synchronization between the project’s stakeholders
• Project schedules don’t correspond to reality, because the people in the field are not involved in estimating and planning
• Problems identified too late (delays, mistakes, “not right the first time”)
• Employee turnover causes the team to lose expertise
• The end-user is only distantly involved

The lean approach

To attack these and other problems, we use a four-step Lean approach:
1. Visualize production to reveal problems,
2. react immediately,
3. and resolve problems one by one,
4. thereby improving your working methods.

This process is not a one-time affair, but rather a system of management to be applied every day in the field. A spirit of collaboration is absolutely crucial to this approach. The team is going to develop new practices and new reflexes, tools that will guarantee its operational effectiveness over the long term.

1. Visualize production to reveal problems:

The first step of the Lean approach is visualizing production. The specific practice is called Obeya, or visual project management. The Japanese term Obeya simply means “big room”, and refers to a room where the walls are covered with visual representations (such as schedules, diagrams, and metrics) that permit the team to steer a project and reduce the time to market of its products.

Every day, representatives from all teams participating in the project meet in the Obeya to synchronize their activities and deal with problems before they can compromise the project objectives.

Toyota uses the Obeya room to conceive products and manage projects. Obeya meetings are led by a Chief Engineer, and the participants include a representative from each of the different core activities (research, development, QA, etc.). The Chief Engineer provides a clear direction for the project, keeps track of performance indicators, ensures that schedules are followed and deadlines are met without compromising quality, and oversees the resolution of problems as they arise.

The Obeya is not exclusive to a business activity or particular context. In an IT project, for example, the leader of the Obeya could be the IT director or a project manager. For a medium-sized software development project, the participants might include marketing, product management, development, QA, integration, and production.

The Obeya is visited frequently by the project team in order to keep everyone on the same page. The team meets:
• Every morning for fifteen minutes (sometimes called a “flash meeting”). Each participant updates their team’s schedules and indicators, presents their objectives for the day, and shares operational problems that might have an impact on the project.
• Once a week to plan the following week (this rule has the advantage of imposing a rhythm of regular deliveries on the project), synchronize schedules, share lessons learned, update weekly indicators, and resolve major problems.
• As needed to resolve show-stopping problems.

2. React immediately:

When an incident occurs or a defect appears, we “stop the line”. We repair the damage immediately so that the problem doesn’t escalate, and because the client must be protected at all costs.

3. And resolve problems one by one:

During the daily flash meeting, the team points out gaps in performance (as revealed by the schedules and performance indicators) and shares problems that arose the day before. After the flash meeting, problems are prioritized, written down on the problem solving board, and tackled one by one following the Plan-Do-Check-Adjust (PDCA) process. Made popular in the 1950s by Edwards Deming, the PDCA is an iterative problem-solving methodology inspired by the scientific method:
1. Identify and measure the problem,
2. observe the problem in the field,
3. brainstorm possible causes as a team,
4. experiment locally, on a small scale,
5. measure results, validate a hypothesis,
6. draw conclusions, change your method of working, and begin again.

4. Thereby improving your working methods:

Members of the team work together to find out whether the actions they took to resolve problems have borne fruit. If so, they set new standards for working. In other words, they create new practices and then share their insights with all of the project stakeholders.

Case Study

The example presented below is a web application development team created by a large European bank. The team is supposed to manage not one but thirty projects per year, and they created an Obeya to help them emerge from the crisis. Henceforth, we call them the “webteam”. The webteam has 10 people, all of whom work on site. It was created as an alternative to the normal IT development process, and is largely independent.

Its mission is to respond to occasional requests for new web tools or upgrades to existing tools from the bank’s network of agencies. Its value lies in its ability to rapidly deliver applications that exactly meet the needs of the requesting agencies, taking no more than 4 months for the most complex requests. The objectives set by the IT director are 10 deliveries during the team’s first year (March to December), and 30 deliveries over the next year (January to December).

The photo below shows a development team very similar to the webteam. What’s going on?

Nothing out of the ordinary, you say? And yet, this team is verging on crisis.

How can we see this crisis? In fact there is nothing to see, and this is exactly the point. We don’t see the state of the project, or how the clients feel about it. Another distinctive symptom of a team in difficulty: the workers themselves are not aware of the project’s progress, and in interviews don’t seem to realize the severity of their situation. They may not even know who their clients are. The clients, on the other hand, are keenly aware that the situation is far from satisfactory.
By September of the first year, only one application had been delivered and the others were late by several weeks to several months. The quality of the webteam’s work (as measured by the number of reworks required before the client accepted the application) was clearly suffering.

The team was not aware they had a problem, and didn’t feel as if they were late: “It’s the client who keeps asking for more [features]; we just try to meet their demands.” As for the clients, most of them said that the applications delivered were incomplete, that the initial versions suffered from errors, and that the times to delivery were much too long.

Here is how the webteam implemented Lean and an Obeya to solve their problems:

1. Visualize production to reveal problems:
In the first week, the webteam constructed their Obeya. On the wall they displayed the “voice of the client” created during their Kaizen workshop, the project backlog, a new macro planning, a task board to track production on a daily basis, several performance indicators also created during the workshop (speed of delivery, defects, cost breakdown), and finally a table exposing all production incidents.
They also added a template for problem solving (by the end of the project, an entire wall of the room was devoted to problem resolution). Little by little, the team added other useful elements to the Obeya: a “red bin” to highlight incidents, a customer satisfaction survey, and a “suggestion box”.

The materials are cheap and easy to use (post-its and paper board). The photo below shows the first version of the Obeya built by the team. Since then, it has evolved considerably.

2. React immediately:
Every incident in the test or production environments is immediately written down and placed in the “red bin”. These problems are attacked with the highest priority. In the images below, two production incidents have been moved from the red bin to the task board.

Note that the red bin incidents are placed above all other tasks, so that they will be treated as soon as possible by the first available developer. If an incident is classified as a show-stopper, a developer with expertise in the matter interrupts his or her work to resolve the problem, generally with the support of the team leader.

3. And resolve problems one by one:

In the example, the team has noticed several delays in one of its project schedules (top). They formed a hypothesis for the cause of the delays: “We don’t understand the client’s specifications, and have to wait a long time for clarification.” In the bottom photo, the team draws a cross each time a delay occurs and can be attributed to this cause. After a series of local experiments trying to improve their process for collecting and understanding client requirements, they succeeded in removing the problem almost completely. The turning point is obvious (black vertical line), and confirms that the team found an effective solution.

4.Thereby improving your working methods:
After completing several of these problem resolution cycles, the team learned several lessons and changed its working methods in response. Notably, after analyzing the problem of missed milestones described above, and after experimenting with several solutions, the team radically modified the way in which it collected information on client requirements.

The team now follows a simple but precise standard for handling client requests. They created it themselves, and refined it in collaboration with their clients. It is now displayed prominently on the wall of their Obeya. The standard calls for an iterative development cycle, regular demos with the clients, and the use of templates and checklists during the requirement collection process (translated sample below).

The results obtained by the webteam in 3 months are nothing short of spectacular:
• 8 applications delivered in November, and a total of 11 delivered by the end of December (objective exceeded)
• Quality: 0 incidents during the last month
• Timing: on average, one application delivered every 10 days, which was sufficient to meet their client request (in lean, we call this frequency the « takt time »)
• Client satisfaction index: +61%
• Cost: on average, 80% of man-hours spent on activities that add value for the client. At the beginning of the project, this ratio was about 50%.

The conditions of success

As a dynamic and collaborative approach to project management, the Obeya boasts numerous and obvious benefits. It promotes and develops teamwork, allows the team to notice and resolve problems rapidly, and is an invaluable tool for first controlling and then reducing the lead time of projects. However, even after a team has begun to take advantage of these virtues, they often have difficulty incorporating the Obeya into their daily routine.

The webteam succeeded in adopting the Obeya for several reasons. First and foremost, we can point to the immediacy of the initial results. In just three months, the team managed not just to meet its objectives but to exceed them, delivering 11 applications instead of 10. Thanks to their Obeya, the team quickly learned to identify “good problems”(1), a decisive factor in the success of any Lean approach. However, to guarantee the sustainability of Lean practice and ensure that it is adopted over the long term, certain other conditions must be met.

The first rests on the notion of managerial challenge. The IT Director and the managers of the webteam visited the Obeya on a regular basis in order to challenge the webteam on its performance and support them in the resolution of operational problems. The CEO of the bank also came to observe the progress achieved by this IT pilot project. His reaction: “I finally see the light at the end of the tunnel!” Regular visits from management provide the necessary support and motivation to achieve continuous improvement.

The second condition is that the team be able to adapt Lean to its particular situation, taking ownership of the approach. In effect, the webteam implemented its own version of the Obeya. It chose its own steering tools and performance indicators, developed a certain autonomy, and acquired a sense of innovation by resolving problems. The team learned to “go and see” its clients to understand their needs, but that is only part of the story. Above all, the team developed a “warrior spirit” that it didn’t have before: the desire to fight not just for their project, but also and especially on behalf of their clients.
(1 -“Good problems” are those with a noticeable and rapid impact on operational efficiency, client satisfaction, and economic results.)

Sandrine Olivencia is a Lean Coach specializing in IT projects with Operae Partners. She is also co-founder of the online community leanedge.org with Michael Balle.

Watch the video