The introduction of agile and other iterative methods have replaced deterministic-normative development processes as the predominant paradigm. As a result, changes must be viewed as opportunities.
- [Instructor] So why do we talk about change at all? Well, the new product development process is all about solving problems, and the changes are often the problem statements that the engineering and design professionals use as input for the design tasks. A change may describe some new intellectual property that has to be created, a new design that has to be created based on customer requirements, and so forth. Conversely, a change may arise from, shall we say, opportunities of a product that's not performing up to expectations in the field.
Despite the fact that change is at the very core of engineering, it also elicits a lot of emotions amongst the stakeholders involved in the change process. In this course, we'll examine how change can be leveraged in an Agile new product development environment and how to make change a bit less painful along the way. If we continue exploring this concept of why change is painful, we can even trace some of the roots back to the education that engineering professionals get. For example, according to Syracuse University's Department of Mechanical and Aerospace Engineering, leading texts say that by controlling change, you control cost, so it is a vital organ of the business and should be run efficiently.
One can see from this quote how change is being positioned and used not only as a restrictive measure for engineering, but as a cost control measure for the business. Similarly, the Institute of Product Development at the Technical University of Munich, Germany, says that the leading text describes the reason for change is for controlling design changes is to restrict the otherwise limitless creativity of designers in order to keep the design within the budget and time-scale.
Again, change is being positioned as a very restrictive measure as opposed to an Agile-mindset-like opportunity to involve customers, to define customer requirements, and to create greater customer satisfaction. So we need to look at how we can reposition change in the Agile mindset, but there's slightly more that we need to consider first. Another reason change is viewed as painful is because there are many International Standards that have very specific requirements around change.
For example, if we were to look at the ISO 13485 documents which describe the new product development processes and change processes in the medical device industry and the ISO 16949 documentation that describes similar processes in the automotive supply chain industry, we would find a lot of commonalities. Some of the commonalities and some of the major findings related to change is that the standards require all design changes to be documented before their implementation.
Now this is definitely at odds with the Agile mindset that says documentation should be secondary and the final product is what you're really working towards. Similarly, the standards require that all design changes are to be reviewed and approved by authorized personnel before their implementation. Again, this is out of alignment with the Agile mindset of making changes and making improvements as you go along so that the product evolves very rapidly.
And lastly about International Standards, The International Standards prescribes some other requirements of the change process. So these standards as we've just described dictate that the design needs to be documented before any change is implemented and that the change process needs to be reviewed by a number of named personnel or named roles. As such, industry has responded by creating a number of artifacts.
We have problem reports and change requests, and many of the artifacts that you're familiar with from the new product development process. Again, this is a lot of documentation that is out of alignment with the way Agile would prescribe change to be handled. Similarly, the roles of the people involved are very prescribed. Again, this is out of alignment with Agile's idea that teams should ad hoc come together, work on a particular aspect of the design, make decisions about the design at a very granular level, and then move on.
- Why change management is hard
- Increasing rigor for new product development
- Anticipating change
- Restricting change
- Improving your tools and technology
- Managing each phase of change
- Adopting a change management solution framework