"We're repeatable. We consistently and repeatably do the same stupid things over and over again." - senior test engineer
Process improvement experts emphasize the importance of having a repeatable process. However, many organizations misuse the "repeatable" to mean "not entirely chaotic." In process improvement terminology, "repeatable" means that the company has a documented product development process that includes project management, requirements management and QA processes. Although you may have a repeatable process in the sense that your organization does the same things repeatedly, it may not be repeatable in the process improvement sense of the word.
 |   |
| Johanna Rothman consults on managing high-technology product development, focusing on project management, risk management and people management.You can reach her at jr@jrothman.com or by visiting www.jrothman.com. |
Even in organizations that use the term "repeatable" correctly, there's another problem. Some people view their repeatable process as a substitute for thinking. One project manager asked me this question:
"If we have a process, all we have to do is follow it, right?"
It depends. If you think you "just" have to follow a process, you're repeatable. Repeatable can work for you, if you continually do the same kinds of projects. However, if you work on different kinds of projects, including long R&D projects, small projects with quick deliverables, and iterative delivery projects, then reconsider your process.
Is your process working for you on the current project? Has your process ever worked for you? Does it meet your needs for this project? I prefer to consider the needs of a particular project, before deciding on a process:
- Do we know how to gather the requirements for this project? Should we use the design to iterate the requirements?
- Is our design process appropriate for this project? Are we going through extra steps because our process tells us to, although the design is as complete as it needs to be for this project? Do we need to iterate on the design this time? Alternatively, is the design complete, and we're filling in the details with a series of projects?
- What kinds of testing do we need on this project? How will we start testing at the beginning of this project? Do we need more exploratory testing this time? Do we need more automated testing this time?
- Do our customers want a series of deliverables, or one major deliverable at the end? Does this mean we should choose a different lifecycle for the project?
- What risks do we have? Do we expect to have to replan this project sometime or several times during the its lifecycle?
When you start analyzing your projects and your process, you can understand what's happening in your different project. You can then choose what to do for your current project. This continual analysis and understanding of your process is called "steering" by Gerald M. Weinberg in his Quality Software Management series.
Steering managers plan what they want to have happen, they observe what's happening, and then take action if the desired effects are not happening. If you're starting a project, consider the problems you found on previous projects. Do you want to change your project planning to reflect what you've learned from previous projects? A repeatable, routine process won't prevent you from thinking, but consciously choosing a steering mindset can help you make better decisions.
If you're starting a process improvement initiative, you may find that it's easier to use you and your team's problem solving abilities to decide on the appropriate lifecycle and project plan than it is to follow a process cookbook. Watts Humphrey, in Managing the Software Process, says, "Software engineering is not a routine activity that can be structured and regimented like a repetitive manufacturing or clerical procedure."
Instead of focusing on being repeatable (as in repetitious), let's think first, and steer our projects.
Previous columns by Johanna Rothman: