Why You Need Projects in a CI Program

Decades ago, I walked through a GE Power Systems service shop with Steve Zwolinski, at the time a newly promoted ex-MBB. He has always been a very effective leader and understood the indivisible operational unit of an effective continuous improvement program – the project. He would go through the shop on his own Gemba style waste-walk saying, “There’s a project. There’s a project. There’s another project.” He quickly translated product defects, waste or customer issues into well scoped projects and layered them onto the relevant business processes. Everyone knew what they were expected to do as a part of a program to get things done.

Philosophy, vision statements and slogans look great on coffee mugs and t-shirts, but if you are responsible for a program you must be able to identify problems, direct empowered improvement teams and ultimately report on progress and results. You must be able to prove that your teams are empowered to take action by making real and defendable changes to the company. You also have to prove this to multiple stakeholders with different agendas over and over again. Only then will you start to change corporate culture.

A CI project is not an exercise in making the situation unnecessarily complex with a huge rollout plan complete with multiple implementation phases; it is a way to fix a process. Fix a defect and it will come back, fix a process that produced it and it won’t. Continuous Improvement means that teams continually do more improvement projects, not that they perpetually work on the same issue.

Project leaders must write and maintain a charter for every project. It is the central hub for communication for you and your team members, subject matter experts, program leaders, internal stakeholders, and other CI personnel. Charters can all go in a central repository for reference, access, tracking, archiving, research and reporting. Elements of the charter can also be incorporated in database style reporting and management tools. You could even print them off and put them on communication boards around the office. I usually complete a fill-in-the-blanks Excel spreadsheet for each project and put them on a shared folder.

The charter contains a number of elements required to define and sustain an organic continuous improvement culture.

Before Project Launch

Identify the customer or business problem

• This is to identify the need for the project. Why is this problem the most important thing we should address right now? How does this have an impact on customers or stakeholders? This should include the financial benefit of the improvement. Face it – unhappy customers don’t come back. Poor financial performance means the company won’t come back.

Identify the project executive sponsor

• There are a lot of roles and responsibilities to be sorted out. This one is essential. Whose P&L does this project fall under? The project benefits all roll up to the corporate level and projects must do the same. You will need this person if your project runs into snags later on.

Establish a baseline and establish a priority

• Document how big this problem is. This metric will also be used to track the progress of your improvement. Not all projects should be done. Work on the ones with the biggest impact first. Don’t make the mistake of working on projects that are easy to implement, yet have only a small impact.

Define your goal (and have the stakeholders agree)

• This does two things. It establishes your target and gives the team a measure of effective progress. When you have achieved your goal, you celebrate with the team and move on to the next project.

Communicate with the team

• Your team will have a lot of people. The best thing you can do for them is to clearly define how they fit into the puzzle of solving the problem. Don’t make the team too large. Your team and project should be organized using MECE - mutually exclusive and collectively exhaustive.

Scope the project

• It is useful to define what is in the project, but most importantly what is NOT in the project to minimize scope creep later on. Use a SIPOC to define the edges of the business process, and the data and reporting requirements.

During the Project

• Track your progress and manage the team
• Establish project milestones and track progress for team meetings
• My Excel spreadsheets have a rudimentary colour coded Gantt chart, nothing fancy
• Update the charter sections for team meetings

After the Project is Complete

• Document the new process and make it stick
• As part of the initial project, you and the team will document the existing process. You can use this to come up with a “to be” process that you may or may not achieve. Remember the project goal is based on a performance metric, not a percentage of actions taken, budget spend or calendar date. You should document this new process, not your dream process.
• Archive the charter and project documentation in a manner that can be found by someone else. One day the project sponsors will have to report how well the program is having an impact in their area. This request will always come at a very inconvenient time for you. This will not be the best time to start gathering project documentation and making PowerPoint slides.
• Celebrate with the team and move on to the next project.