Software, Curricula, or Widgets: Products are Created by Similar Processes

Processes are processes, and their common feature is that they start at some place and end at some place. “Modern” processes have a feedback loop so that they are continuously subject to review and improvement. Let’s focus on essentially identical processes that remain inappropriately proprietary depending upon which of us is laying claim. Trainers claim the Systems Design process. It begins with Analysis—whether Needs, Gap, or Job Task, and a quality check to be sure everything has been thought of. Analysis is followed by Design, which creates a flow diagram, or a map of the entire curriculum. It’s here that tests are created because every important element of the course has been laid out. Again, there’s a QA step with a design review team as a cross check. Now that you have a map, you Develop material to flesh out the content. As in the other steps, QA looks at the developed course to check sequencing, examples, accuracy, and so on. Finally, you Field Test the material to work out bugs in presentation, content, and timing. After the final tweak, you are ready to present the course, evaluate understanding, and immediately revise, as necessary. You will also want to measure ROI, but that will only happen over time when you see whether, for instance, the time to do a task has shortened significantly or that numbers of mistakes drop significantly. Software engineers also claim the Systems Design process. Software developers meet with customers to define the scope of work. They need to find out exactly what the customer wants the product to do. This is the Analysis phase, and includes both functional and technical requirements. Once the customer’s requirements are known, an engineering design is created to “illustrate” the product to be developed. It is also called conceptual prototyping or modeling. This is the Design phase, and it’s also the point at which QA test plans are created that test the performance of both the component parts and the final system against the requirements as established in the Analysis phase. Then, there’s the development of the pieces that, when linked together, become discrete modules in the system. This is the Development phase in which a working prototype is developed. As each piece is completed, it is tested, and as each module is completed, it is tested. Finally, the entire system is tested, which is the equivalent of Field Testing a curriculum. When the final system testing is carried out, ostensibly for customer verification, acceptance, and payment, that is the equivalent of teaching the curriculum. If there are downstream measures of ROI, they are measured only after the system is operational in the customer’s environment, just as in the case of training. The GMP (Good Manufacturing Practice), so coveted and “owned” by manufacturers, is nothing more than a quality assurance process that verifies that your manufacturing process is operating as intended. The processes very closely resemble those already described. When I last consulted to a computer product manufacturer, I discovered that the problem they told me was a training problem with the manufacturing line was, in fact, a failure to stick to the GMP. The didn’t pay attention to document control issues for Manufacturing Process Instructions (MPIs) on the line. It wasn’t a people problem, but a failure to adhere to the process model. Trainers, software developers, and manufacturing engineers all operate in different environments, but product development processes are essentially the same. The observed differences between them are more easily accounted for by a personal lack of experience across industries than by any real differentiation. Those of us who use this product development process as a routine part of our work lives will see that our skills are readily transferable across businesses, industries, and functions, much the same as accounting and marketing skills are. Building a hard drive, a software application, and a training program require the same skills in the process designer. Beyond that, all sorts of skilled people with specialized knowledge are required to complete the product. That’s why trainers need SME reviewers, why software functional analysts need technical and systems analysts, and why plant process managers need mechanical engineers. Look how broadly we can each apply our own hard won process skills!