Archive for the ‘Process Improvement’ Category

What will you be doing in 10 years?

Friday, March 30th, 2007

Once again, Tom Peters provides inspiration for what we are trying to do at Synaptus. In his post yesterday Now Don’t You Worry Your Little Self…,  he raises the alarm about 40 million jobs moving out of the US in the next 10 years.

40 million jobs, is that a lot? According to the Bureau of Labor Statistics there are about 150 million Americans in the work force. 40 million jobs moving overseas is over 25% of the jobs in the US. What could cause this to happen?

China has 798 million people in their labor force. India has 509 million workers available in their labor force. Their real wages are far below the US and Europoe. As education rises in these countries and communication technology improves, businesses will move work to where it can be performed well-enough at the best cost.

Stop and think about what this means. The way companies do work is going to change.  We are just entering the knowledge-based, or project-based, or information-based world. My kids will be entering the job force as this world becomes predominant. It took 50-100 years to get really good at managing industrial based organizations. The businesses and individuals that figure out how to thrive in this new world of work are the ones that will survive and grow.

Aligning a dynamic organization with strategy, understanding and improving processes across your business (regardless of your organizations boundaries), productive collaboration, talent management, and project management become key skills to build and manage organizations that will thrive now and survive in future.

The ability to gain competive advantage from these shifts, both for you and your organization, is there today. On the other hand, 10 years is a long way away. You can wait for someone else to figure out how to run businesses profitably and manage the new workforce. I chose not to wait. What will you be doing in 10 years?

Multi-tasking is bad – Again

Wednesday, March 28th, 2007

Several of my favorite bloggers have discussed multi-tasking. Reforming Project Management, Focused Performance, and Clarke Ching often explain the dreadful impact of multi-tasking. Multi-tasking is bad for a number of reasons. All of them have been widely discussed. But I want to discuss four of them here.

One.

Starting sooner doesn’t mean you will finish sooner. Let’s say you have three people that want you to do something. To simplify this example, each thing takes three days to perform. You want to make everyone happy so you start working everything as soon as possible. You switch between them each day to continue to show progress on each thing. So your work looks like this.

ABCABCABC

You deliver "A" on day 7. "B" on day 8. And "C" on day 9.  In trying to make everyone happy, you pushed A and B back and didn’t do C any favors. If you had worked on these things in sequence, your work would look like this.

AAABBBCCC

You deliver "A" on day 3. "B" on day 6. And "C" is still delivered on day 9. Starting sooner didn’t get work done sooner.

Two.

Sometimes work needs to be expedited. It just happens. In the second work flow above, you could just drop the expedited work into the queue as the next thing to do. You don’t interupt other work in progress, and you will finish it just as fast as possible. Remember, starting it as soon as possible isn’t what’s important. Finishing it as soon as possible is what’s important. Mixing expedited work into the middle of the flow will slow everyone down.

Three.

When you take longer to deliver work, you raise the risk that the customer requirements will change.  You want to have the shortest amount of time from when the work starts to when the work is delivered to the customer. This will reduce the risk that the customer requirements will change on work in progress. When customer requirements change on work in process, it creates rework. Rework is extremely expensive.

Four.

Task switching is expensive. As this NY times article points out, we are not effective at getting back to productive work when we are multi-tasking. Having multiple tasks active at a time increases the likelihood of interuption.

Our work lives are probably impacted by most of these issues. Often in combination. The multiplying effects of multitasking is devastating to performance in organizations. Just fixing this problem can double the productivity of a work group. You can have the right people, the best processes, and a solid strategy. Managing the flow of work through each person in the organization has the potential to boost productivity as much as any people, process, or strategy improvement.

What can you put into place to reduce the impact of multitasking on your organization?

You don’t understand, I’m new here

Tuesday, March 27th, 2007

I took an old laptop in to a shop to have it repaired before Christmas. They lost it in January but promised to look for it. I went in today, for the 10th visit, to find out the status of my laptop. The manager was not familiar with my problem. I expressed my dissatisfaction with the overall situation. The manager replied to me, "You shouldn’t be mad at me. I just started working here. I am not familiar with the situation." I told him I didn’t care whose fault it was. I didn’t care that he was new, my concern was that I brought my laptop into his establishment, and didn’t want to feel like it was my fault that it was missing.

He continued to explain to me that it wasn’t his fault. I acquiesced and asked him to try to find my laptop. He went into the system and started asking me questions about the make, model, and serial number of my computer. I asked him to review the records on his system. Surprisingly, I don’t have the serial number of my old laptop memorized. It was not in the current record in his system. So, I asked him to find a prior service record for my laptop. He found a prior record and got the answers to his questions.

He wasn’t sure how to proceed in looking for my laptop. I asked him a series of questions about how a laptop typically would be processed and we identified three points it could be missing. We identified how he could verify whether my laptop was in those locations. It took about 30 minutes for him to agree to take responsibility to look for my missing computer.

I believe this is a talent management and process problem. From a talent management aspect, the basics of the business were so obvious to everyone else that no one explained the laptop process to the manager when he was on-boarded. Also, this is a new manager. The business doesn’t have a clear understanding of the necessary skills and competencies for a manager in this store. He may be technically competent but he lacks some customer service competencies.

From a process aspect, there is no process to ensure accurate information is stored when orders are entered. There is no process to track customer complaints. There is no process to ensure inventory moves reliably through the system. This shop is very affordable, and they have historically done quality repair work on my computers.

There are two more local PC shops and two computer repair chains nearby my house. By failing to hire talent and manage their processes with the view of the customer in mind, this company has lost a customer. It isn’t enough that they are cheaper and technically competent. What capabilities within your company are most visible to the customer? Are you keeping in mind the customer impact of the talent and process decisions you are making? 

Which comes first?

Monday, March 19th, 2007

Gemba Panta Rei has an article that is relevant to, People or Process, a recent post on this blog. I think this highlights the benefit of looking at process or environment first when you have a people issue.

"in Japan the first response to a high rate of absenteeism is to conduct root cause analysis into the behavior of absenteeism, leading to kaizen. In Europe the management would replace the worker who had an attendance problem with another workers. Problem not solved, but deferred."

If its a flawed process, or if you have a flawed understanding of competencies necessary to perform the job, switching people out does not solve the problem. Combining a quality process with a clear understanding of the innate competencies and values required to be successful in the job is a powerful combination. Much more powerful than either applied independently.

People or Process

Saturday, March 17th, 2007

I’ve been engaged in a conversation with Gary Farush over at ComplexWork regarding whether performance issues can be addressed by people or process. We agreed that sometimes its people and sometimes its process. Gary contends that people tend to get blamed first, and that by not addressing the process issues they tend to recreate the same problems.

This is probably true. People don’t do bad work because they want too. They tend to act in they way that makes the most sense to them. So, when expected results aren’t being delivered, you should look at these five process/organizational environment issues before you start blaming the people.

1. Inertia or Momentum: "That’s the way we’ve always done it"

2. Conflicting Priorities: Compensation or rewards are in conflict with specific objectives. Or a person is being pulled in multiple directions by various levels of management.

3. Bad Inputs from Upstream in the Process: The person is having to deal with poor requirements or bad inputs from upstream.

4. Lack of Tools, Knowledge, or Understanding: A person can’t perform their job satisfactorily if they aren’t made capable through enabling technologies, training, or expectations.

5. Management Inattention: The work itself is not being managed. This can actually manifest itself as any of the prior four points.

All of these causes can be identified, managed, and the impact on your business reduced. There is also a very issue though that certain jobs require specific skills and innate competencies. Skills can be trained. Innate competencies are part of how people are wired.  When you have addressed the five problems above and performance doesn’t improve, match the competencies of the people to those best suited for that job. Also, it is probably smart to ensure when hiring that you getting people with the best set of innate competencies for the job.

Lean Will Work Here

Wednesday, March 7th, 2007

Kevin Meyer over at EvolvingExcellence has a great article Lean Won’t Work Here. He points to an article in CIO magazine by Dean Meyer (no relation to Kevin Meyer) that describes all the reasons why Lean won’t work in IT. Dean (non Kevin) says:

Apply Lean and Six Sigma to a job that involves diverse tasks, relationships and creative problem solving (like what most IT staff do) and you may find you’ve created a very efficient organization that fails to accomplish its purpose.

As Kevin (not Dean) points out, the problem is that Dean is fundamentally wrong. The to pillars of lean are to reduce the time to customer value and respect for the individual. The problems the article highlights are not problems with lean, but with the application lean.

The problem is not just that the management of many organziations don’t understand the point of lean, but that the consulting firms helping them don’t either. These resulting disasters further muddle the lean story. It’s no wonder that an industry that has this understanding has satisfaction rates below 30% with their service and fails to deliver projects to their customer up to 70% of the time. From the standpoint of Pragmatic Process Improvement, you have to focus your efforts where it will benefit the business. You can’t view process improvement distinct from value creation and human interactions. Despite what Dean Meyer represents, lean is completely aligned with both of these pillars.

Lessons Learned

Saturday, February 24th, 2007

At the workshop I am attending this weekend the concepts of lessons learned has come up several times. Several times someone in the group has said, "we have the lesson’s learned from the last time we did this, haven’t you reviewed this?" In each case the manager in charge of the project replied, "I didn’t know they were out there." Despite the diligent efforts to capture lessons learned, the organization isn’t benefiting from prior experiences as much as they could.

So when is a lesson learned considered learned? Stopping at the end of a project effort and identifying the things you wish you knew at the start of the project is a very powerful technique. Writing these lessons down for those coming after us is an important way to archive this information. But without a way to make sure that the people who will be responsible for the next project understand the relevant lessons learned, this is not productive time. There are three suggestions for handling this.

1. The people who are taking on projects must take the time to look for and review lessons learned from prior similar projects. This means that lessons learned must be stored where they can be found and tagged so that the relevant lessons can be identified.

2. There could be someone in your organization who is familiar with the lessons learned that are out there and provide some context to new managers.

3. Whenever possible, there should be a meeting with the new manager, a person with prior experience, and a someone who is familiar with the library of lessons learned where a conversation takes place. Even if 1 and 2 are taken care of, people learn much more from hearing stories than from reading a formal document.

Remember, documenting interesting lessons is valuable, but nothing is learned until it is available for someone to use it when it matters.