Checklists are one of the tools that compose the Toyota Product Development System (TPDS). They make up a base of accumulated knowledge, presenting everything that a company could learn over time about the good and bad practices of a project. We can say that the checklists are simple reminders of items or practices which cannot be forgotten during the develoment of a product. They can be so powerful if used and updated regularly or useless if they were little or not used. According to James Morgan, author of the book - Toyota Product Development System, the checklists are standardized tools and form the central part of the TPDS. Its use begins from the time of kentou until the end of the project. The checklists can provide the guidance of a process and help to ensure the quality of a product. Each item of a product must contain a list with a single person responsible, who would take care of its maintenance. The matrix of quality of the fender of the Camry, illustrated in Figure 1, is a typical example of a checklist.
Figure 1. Example of Checklist - The matrix of quality of the fender of the Camry. Source: Morgan, J. M. e Liker, J. K. (2008), Toyota Product Development System - Portuguese Version (p. 309). São Paulo: bookman
We can understand the above illustration that with further advances in developing, new items to be inspected will arise through each step of the process. Thus, the Toyota can ensure quality in each piece and therefore the final product. How can a checklist be used in Lean IT? The example of the checklist shown in Figure 1 may seem complicated due to various details to be inspected during the manufacturing process of a car. However, if we recall that the principle of a list is only adding simple reminders of items or practices that cannot be forgotten during the development, thus makeing implementation simple. For example, suppose a Product Owner (PO) receives few customer requirements weekly. Over time the PO will have experience of what is necessary to have additional checks and may create a checklist for similar requests. For a email marketing template we could have a list of some items such as:
Note that items mentioned previously should be checked during the development process and not just at the end of implementation. To specify more details about the concept of checklists, imagine that a developer receives a requirement, a User Story or a hypothesis to implement. During encoding different points of application may appear that would require adjustments. At that point, the programmer must make a decision: change (s) the code (s) immediately in other (s) part (s) of the application, in order to maintain integrity in their development, or continue to schedule and modify when you finish what you are currently doing. Normally, developers would answer, if the change is rapid, so as not to lose focus on the current work, I would adjust other parts of the application first, or, I would modify only after finishing what I started. We can conclude that if there is a large number of parallel settings (regarding the current encoding of the programmer) the greater the chances of him forgetting to implement something. If the developer register these changes, at the moment that he identifies them, on the computer or using pen and paper, the chances of forgetfulness will decrease considerably, resulting in greater consistency in coding and consequently improving the quality of the final product.
We can conclude that if the items to be inspected in an IT project become recidivists for the team over time, the responsible for the area where the recurrence occurred, should create a checklist detailing what should be checked and at which stage of the development process. If there were specific problems that arise frequently during encoding, the checklist should be made at the exact moment that the developer identifies the necessity - under this kind of situation, these specific reminders may be discarded if the developer does not identify use in the future. To find out if the applications of lists are being properly made in IT, one option would be to measure the number of errors obtained in the test phase of the development process and verify if it decreases over time. It is worth remembering that the checklists are not only a tool that Toyota uses in the process of product development, they are a form of learning and enables a continuous improvement of the subprocesses responsible for vehicles design. The quality of a product or a project is often perceived in the details and to lessen the forgetfulness of some of them and avoid further error, it is necessary to use a checklist.
Bibliography
- Morgan, J. M. e Liker, J. K. (2008), Toyota Product Development System - Portuguese Version. São Paulo: bookman