Five Ideas for Making Six Sigma Project Software Work

Fulfilling the Six Sigma promise of increased cost savings and employee engagement may ultimately depend on some combination of organizational trust, aptitude and heart of the people who are actually doing the project work. There are many software applications on the market that are designed to support these spirited practitioners who make project results happen. However, that doesn’t mean that adoption of new project execution software is free from issues that require careful planning and management. This article presents five key factors and recommendations for deployment managers to consider as they embark on a migration to bring Six Sigma and Process Excellence projects into a project management software framework.

These suggestions are intended to be applied generally, not specifically to one software product. I have seen how managers can move toward an effective deployment with greater confidence and with lower risk of a negative impact as a result of these ideas.

1. Build a strategic timeline including a Six Sigma software pilot period

The best way to frame up your implementation plan is to build a simple timeline of the key tasks and goals you need to and want to achieve by adding a new project management software tool. At first, you don’t need to worry about attaching specific dates to each milestone — a simple sequence will help lay out the big picture for you.
Your strategic timeline should include things like pilot and training plans, installation and set-up timeframes, and consideration of reporting needs. As your timeline takes shape, start to assign a number of days or weeks to specific tasks. If you are not sure what to estimate for particular milestones, consult with a resource at the software supplier — they should be able to tell you generically about customer best practices. Test them early, before making a large commitment, to check their level of responsiveness. There should be some kind of pilot or evaluation period allowed before an enterprise-wide commitment is made.

In your plan, include good ideas for customizing the software that would improve the performance of the Six Sigma deployment. Once you as the customer articulate what the need is, it is possible that your Six Sigma software provider could surprise you with a satisfactory result.

2. Go a little "old school" when communicating the transition — be specific and challenging

Many Six Sigma project deployments have used a mixture of Excel, PowerPoint, Word, Visio, and other file formats that may be scattered on PCs across the company. Migrating to a new project "paradigm" will involve some changes in the way project information is collected and stored — real changes in the way people do their daily work! Such a change may even be a little scary for some people, so empathy is a key.

What about Six Sigma projects that are halfway complete? It is probably best to avoid bringing new Six Sigma software online in the middle of a lengthy project, as the transition could introduce delays and uncertainty among the project team at crucial points — consider grandfathering those old complex projects. The best time to begin requiring the use of new Six Sigma software is when there are smaller-scale projects to do — the proverbial low-hanging fruit. That gives you a lower risk profile and greater latitude to build your expertise at a comfortable pace. Create a scenario where you can learn from the inevitable mistakes that will crop up along the way.

The best practice here is to take timing into consideration but then move forward assertively with a clearly communicated plan. Don’t be afraid to be a little direct and let people know what is expected. For example: "We expect all projects at the next tollgate to be in the new format." I have seen cases where the team becomes delayed and even bogged down because of, frankly, a wishy-washy approach from deployment leaders.
Get your IT department involved with examining and understanding the requirements of the deployment team. Will your new Six Sigma software require a purchase of new hardware? Will space on a server be needed to handle archives, history of best practices, templates, and other information?

3. Build a strong relationship with your Six Sigma software supplier

So, you have made the purchase and the software is pushed out to users. Now that a new icon appears on users’ desktops, the real work has just begun. All successful deployments that I have worked with have been comfortable tapping into and even demanding responsive technical resources. You need support. Whether you are counting the Six Sigma software supplier or an external/ internal consultant, here is what they should be helping with:

• Tracking that timeline that we created in idea number 1. — Find out what has worked for other customers and provide an idea about how long certain tasks have taken. It may be easier to establish accountability if the team is aware that since other companies have done this successfully in "x" amount of time, why can’t we?
• Training — integrate the software deployment with regular Green Belt, Organizational Excellence, Continuous Improvement, or Process Excellence training. Bake it into your own organization. Part of the body of knowledge for qualified project practitioners should be a competence with the software that the organization has selected. Training is not completed until the trainee knows how to use the software correctly.
• Technical Support — there needs to be first-responder support that offers a real human to talk to, maybe an online knowledge base, and offers prospects to connect with formal or informal user groups.

4. Assess your staff’s skills and create leading early adopters

Not every professional on your team will be the ideal candidate to lead the team in developing expertise on the new Six Sigma software. Who will be your champion? Who’s bought into the migration plan — and who is likely to resist the change? It is essential to identify the most competent and respected person who is also positive and eager to lead the change. That may not be the most senior person, or even the person who has been most successful with the old way of completing Six Sigma projects. But it might be! The idea is to go through a thought process on who is going to be making this initiative work "on the ground."

These early adopters typically become "go-to" people for the rest of the team once they begin their own training. One best practice that I have seen is to establish post-sale communication with the Six Sigma software supplier directly, even with key software designers and engineers if possible. There may be simple changes possible in the software that come to light or features that were not readily apparent but emerge to solve real problems. This kind of interaction also demonstrates commitment to/from everyone involved. Just make sure that the early adopter leaders are well suited to assuming those informal leadership roles and they are capable of informally training peers and acting as resources to others.

5. Make the commitment

Changing routines and establishing organizational discipline is difficult work. It involves detailed planning, and you can count on the fact that the effort will never go exactly as planned. When Six Sigma leaders decide to purchase a particular project management software tool, the decision represents much more than a simple "software upgrade."

As such, the most effective implementation leverages a company-wide, cultural commitment to embracing and adopting the effort. Ideally the new system will have managerial buy-in at the highest levels. One real life example I have seen involved sort of a skunk-works approach led by a rogue (but quite engaging) Master Black Belt. This effort began with a burst of activity, but it ultimately did not gain enough momentum to demonstrate the value of the system. The organization would have been better served if key players were apprised of what was going on. Then, possibly, they could have offered support.

Installation means much more than simply inserting CDs or downloading installation programs. Leaders will need to flesh out the details of configurations and file management, and then communicate the answers. Where will you store your files? Are there shared templates to use? Will you mandate the use of a certain library of project files — for example a "Topeka Plant" library? How will you manage archived Six Sigma projects? Will you integrate with SharePoint or other web-based tools? Centralizing these elements prevents confusion and helps you scale up. As your implementation grows beyond a handful of early adopters, these issues will assume greater importance.

So to conclude, time spent on forethought and careful communication can eliminate needless complexity and allow problem solvers to remove non-value-add administrative tasks from their plate. With a thoughtful and directed implementation, the Six Sigma project software itself becomes just a means to an end and starts to fade to the background. Attention is shifted to the heroes of the production floor, call center, hospital, or transactional environment who have the ideas, energy, and process knowledge. When that happens, the organization will start picking up the tremendous cost savings and employee engagement benefits that were thought possible when the whole initiative started.