Standard Time Plans for Projects and TQM
Standard Time Plans
I post this blog, because I have recently witnessed an organization working to create a standard time plan for their work. This is not necessarily a bad thing, however, by PMI definition, projects are not operations and are unique. Each project can have considerable variation in scope and personnel. This is especially true for product development, which is often exploration and knowledge management type work. The attempts to superimpose a standard time plan will require the use of TQM tools for success. Or these types of projects are misguided at best. The use of standard implies that we have a way of knowing what is typical, and even typical has variation. Standard times are often used in repair scenarios, for example a standard time to replace an alternator. However, replacing that alternator has a well-defined set of steps and tools. The measurements of the time to achieve the replacement are made many times with different people before a standard time is settled. In other words, this activity is more like operations than project management. If you are considering standard times for the project activities for your organization, consider this. Is the task more like operations or more like project management? As all people are not the same (talent and ability) can the duration be set that considers this dilemma? Have you gathered enough data to allow prediction of the variation in the task?
Repeat-ability and TQM
If the projects have recurring theme or steps attempts and quantifying are not entirely futile but gathering the data and making predictions are precarious. Total Quality Management tools can help quantify and assess the range of possible durations. We have shown examples of the use of those tools in earlier blog posts but provide a list below:
- Histograms
- Pareto Charts
- Fishbone and Cause and Effect Diagrams
- Scatter Charts
- Control Charts
- Flow Charts
- Check Lists
- Check Sheets
TQM and Project Work
These tools apply to project management as well as the typical line functions, for example verification or software engineering typical activities. Some of these may be more readily understood in terms of time and effort. For example, if the company has a formal software release process, perhaps this process has enough consistency to set a very rigid standard time. I have worked at companies where this was so repeatable the standard time was low risk for the project. Using this same fixed duration approach for something like writing a specific software feature for a product may not be so successful.
TQM Reduces Risk
The task should be carefully considered before assigning a standard time. This is easy to find out with measurements and Total Quality Management tools. Our book shows you how to understand what you have – so you can perhaps make some of the elements of the time plan standard without incurring too much risk.