About six weeks ago, I was invited to present at a Six Sigma symposium in Washington, D.C. As it turned out, I was the last speaker in a three-day agenda. Throughout the week, speaker after speaker presented solid information on Six Sigma concepts, tools and approaches. Further, each session would say: ‘When you are working on a Six Sigma project, here are some good …..However, if these Six Sigma tools, approaches templates, etc., are so good for Six Sigma projects, why not use these approaches in our day-to-day software development and IT project management process? Coincidentally, my presentation discussed and drove this very idea. Examples of these Six Sigma concepts are discussed below. Please note that due to the evolution of Six Sigma over the years, the names of the project planning tools and so on may vary from your own titles for them.
1. Learning Objectives
Whenever we embark on a new project, we need to learn new concepts that are beyond our current knowledge and experience. To help us identify, plan and document such needs, the Learning Objective Matrix can be used. This process should be done very early in the project management life cycle in order to discourage us from jumping to solutions based on our current biases. If we bypass this critical thought process, we often are forced to rework plans and project deliverables during the lifecycle. In turn, we can disrupt the project. The three simple matrix columns of ‘What do we need to know’, ‘Where are we going to get it’ and ‘How are we going to get it’ drive us away from ‘solution thinking’ until the proper time in the project life cycle.
2. Customer Matrix
The Customer Matrix helps us to plan and assure that the correct representatives are included in requirements gathering activities, e.g. interviews and observations. The population is segmented into specific areas – for example, geographical regions. Then, we consider the types of participants we would like to cover, e.g. expert users, new users and difficult-to-satisfy users. By doing this graphically in a matrix, we can easily see any gaps in the planned interviews and make the proper corrections. After all, what project doesn’t need to do a better job with requirements?
3. Context and Needs Data Analysis
Speaking of project management requirements, we often hear about ‘new or changed’ requirements. There is even a metric called ‘Requirements Volatility’. However, about 85% of the time, the item is not a new or changed requirement. The requirement was always there, but we just missed it due to poor handling of Needs and Context data.
