Executive Summary:
We all strive to balance speed of execution against management of risk and assurance of product quality. Make a simple adjustment to your existing product development process to solve a number of challenges. Change the focus from tasks to purpose and watch your process execution improve with regard to both speed and risk management.
The Rest of the Story:
In Part 1 of this post we discussed the first two steps to making some very minor adjustments to the wording and to how we follow our existing product development processes. I proposed that we change our review habits from asking “did you do,” to asking “how do you know?” I also suggested that the mandatory deliverables be separately identified from the good-idea risk management activities. In this post, we’ll continue the thought process beginning with step 3.
3. Change your risk management good ideas from compulsory tasks to considerations:
For some projects, certain risk management activities will be highly important and worth a great deal of time and energy. For others, the same activities may provide little or no value. Allow your management and your teams to recognize this and plan the project with the greatest balance of quick execution, and risk management in mind.
Here is an example. The task we will address is Failure Modes and Effects Analysis (FMEA) of the design to begin in one stage and be updated and managed in subsequent stages of the product development process, until closed after final testing. This example will serve us for two points.
First, this task may be very valuable for a complex system design that includes mechanical, electronic, and software elements and several modules communicating and responding appropriately. I can’t imagine completing such a design without an FMEA and also perhaps a Fault Tree Analysis to help identify the possible failures for the FMEA.
What if the team has a better way of tracking and managing all of the risks for such a project? Would you make them use the FMEA because the process says so, or would you allow them to try something new?
However, what if the design project is simply altering the design slightly to accommodate a change of suppliers and the new supplier’s fabrication process? Sure an FMEA might be used, and the team could choose to do so, but what if performing the FMEA takes more time than all of the design work combined? Is that really appropriate? Would a less complex exercise suffice?
My point is that what is a good idea for one project, may just be an unnecessary task for another. Don’t force your simple projects to follow the same risk management plan as your complex ones.
Second, the wording of our process steps or checklist activities makes a big difference. Suppose that the task description simply reads, “Do FMEA,” or “Update FMEA.” What do you get? What is the focus?
A team under a great deal of pressure to execute quickly will be prone to filling out a few lines of an FMEA template with some obvious risks, insert some mitigation plans, and check the box. This is especially true if the expectation is that at the review someone will ask, “Did you do an FMEA?” and all they need to do is provide an honest “yes.”
Believe me, it happens to the best of us, not because we are careless, but because we are trying to find that balance between executing quickly and executing well. If we don’t think that someone will really care about the FMEA, or any other mandated task, we’ll put the least amount of effort into it and move on.
So here is where the wording comes in. Change the wording to focus on why we should do the task, instead of what it is or how it should be done. Consider the following. “Identify and record important design risks and establish plans to prevent problems.”
If you want to encourage the FMEA tool as a standard for design risk management then add, “The FMEA method is an accepted standard, the template is here…(provide link).” Now, combine this alteration with the one above whereby you ask, “How do you know… that you have accounted for the design risks and will prevent foreseeable problems.”
Do you see the difference in discipline? Instead of an answer of “yes” in a case where the purpose of the activity was neglected, you get an explanation of how the team identified and addressed the risks. Follow up by saying, “Show me.”
Suddenly, your team is focused on doing the right thing instead of just doing a mindless, meaningless task. Imagine the power you have just unleashed just by changing the wording of the good idea item and the review question.
Let’s recap step 3. By making your good idea process steps considerations instead of mandated activities, you give your teams the option of performing them or not, as it makes sense to the development project. By changing the wording of each activity to focus on why the activity is important instead of what or how to do it, you keep the team and your managers focused on doing what’s right instead of just doing.
4. Re-focus on planning instead of reviewing:
With the adjustments to your process description and your review habits above, you can now make one last adjustment to how you plan and follow your existing process. This step enables flexibility in how you execute your process, and also prevents run-away minimalism and elimination of the good idea (considerations) activities.
Give your teams the responsibility and authority to plan the project based on the deliverables, which remain mandatory, and the considerations that make the most sense to the project. Let the team make a case for why each consideration is or is not important, and propose a plan or tool to get each one done.
Pressure to get the project done expeditiously will drive the team to look for alternatives to testing for validation, over-analyzing designs, and to challenge procedures that get in the way more than they make sense. This provides project plans that have less waste or unnecessary activity.
An expectation that at specified reviews the team will be expected to answer the “How do you know” questions means that the team remains focused on the value of each activity and helps make sure that those good idea considerations are executed with purpose.
Congratulations, not only are your teams finding ways to execute more quickly, they are executing with greater diligence at the same time. You didn’t think it was possible did you? Be assured, it is.
There is a final benefit to the forth step. Believe it, the added responsibility and authority placed on the design team to plan the process steps for its project makes it easier to introduce this approach and make it habitual.
Remember, your business selected personnel based on skill, experience, and intelligence. It’s a sure bet that those skilled, experienced, intelligent people would prefer to exercise their judgment base on those traits than behave as mindless drones following a dictated recipe. They will latch on to the new approach readily.
That leaves your management team’s behaviors. This can be a more difficult sell sometimes because of the fear that the business will lose discipline or that the process, which has been so carefully constructed over time, will be whittled away.
To sell it, present the same balance of speed and discipline explained above. Draft a prototype of the changes that might be made to one element of the process to show that the process isn’t changing really, just some wording and the way they plan and review the activities.
No matter what, because what we are talking about is fundamentally a behavioral change, it will take significant leadership, consistent mentoring, and perseverance to succeed in making the change. Do it and you won’t be disappointed.
After all, what I have described is little more than wordsmithing your existing process and changing how you plan and review the checklist of activities. The difference in performance is huge. Instead of focusing on getting meaningless tasks done, your management and your team will be focused on what they learn and can improve about the design and the project plan.
In the end, product development isn’t a recipe. Recipes are for doing the same exact thing every time. You don’t need the same exact product every time. You need something different every time.
Product development is a learning process by which the development team explores possibilities and decides upon solutions. Treat it like a learning process by constantly planning for what needs to be learned and addressed, and asking questions focused on what has been learned or decided.
Keep the team focused on the activities critical to learning and making decisions by asking how it knows. Keep the critical few tasks as mandatory executables. Open up the rest of the checklist of tasks to be adjusted according to what is important or appropriate to the project in question. A few simple adjustments can make a very great difference.
Stay wise, friends.
No comments:
Post a Comment