Your Reliability Engineering Professional Development Site
This article series will help guide organizations in optimizing the value of products being developed, while minimizing both development and operational costs.
Consider the “wasted energy” during product development on products that don’t meet customer needs or product requirements. Multiple prototypes, rework and redesigns are often needed, and substantial time and effort is typically invested post-development to reduce product costs.
These articles aim to address this problem by enhancing readers' understanding of product development, project management and process improvement tools and methodologies.
With these disciplines, company culture and competitiveness can be significantly improved by leveraging skilled, efficient teams and collaborative problem-solving.
Sign up for the “Product Development and Process Improvement” email list to receive weekly articles.
Our previous article compared agile/scrum with lean/kaizen and revealed several similar fundamentals that helped make each methodology easier to understand.
Since the objective of lean and agile is waste reduction, we also want to identify and eliminate various forms of waste.
In order to do this, first let’s consider our objective to manufacture hardware product, develop a hardware or digital product and/or execute a project:
Our previous article covered the benefits of comparing the DMAIC problem solving thought process with project management. The key takeaway was DMAIC can be more effectively executed using “measure & plan” phase.
Now let’s compare and contrast agile/scrum with lean/kaizen. While agile is primarily used in software development, there are many valid comparisons. By making this comparison, those familiar with kaizen will improve their understanding of agile and vice-versa. Also we’ll cover key success factors that are applicable to both.
Our previous article covered the benefits of comparing waterfall with agile, emphasizing the benefit of planning the agile process and product backlog content. In this article we’ll compare the Define, Measure, Analyze, Improve and Control (DMAIC) thought process, with a project management thought process.
DMAIC is a problem-solving thought process applies critical thinking to ensure robust problem solving. (See our previous article on the subject here.) DMAIC is not necessarily a process by which projects are managed, however. Recall the high-level project management process as follows:
Previous articles have covered a proposed waterfall product development phase/gate process. This article will compare and contrast waterfall with Agile product development, especially with respect to the front-end of the process.
Let’s start with a proposed waterfall product development phase/gate process. (The process below implies a hardware product, however, it can be considered any waterfall process for now.)
In Part 1 of this article series, we explored a simplified project management process using a phase/gate structure that enables a robust project planning and execution thought process. Now let’s identify some deliverables within each of the phases.
These deliverables would be required and reviewed at each of the gates. Below is a brief description of each:
Organizations often accumulate a list of desirable projects, however, may not have project management bandwidth to filter or manage them effectively.
While project management is a respected discipline, the Project Management Institute Body of Knowledge (PMBOK) has swollen to several hundred pages. This level of detail and complexity makes it difficult to absorb and apply for ‘informal’ project managers. [Read more…]
From time-to-time, there are new ways of thinking or shortcuts to solving problems. However, the tried-and-true Define-Measure-Analyze-Improve-Control (DMAIC) thought process endures as a fundamentally robust problem-solving thought process.
DMAIC must be properly applied to be effective, however. In this article we’ll consider some important objectives within each DMAIC sub-process.
First, let’s consider each sub-process as an opportunity to perform collaborative problem solving. In the “Define” phase (for example) the stakeholders and team members mutually agree on the problem statement, goals & objectives, process under study, process start/stop points, team members, business impact, etc.
Tasks (or action items) are a fundamental building block of an ongoing work-effort or project schedule. While we tend to think of completed actions as deliverables, a project schedule can also be considered a project deliverable….and the value of well-written task (within the schedule or otherwise) is often overlooked.
Generally, a task begins with a verb (some action to be performed) to achieve a milestone or outcome to some desired level of completion. (Recall a previous related article where we discussed the “definition of done”.)
When considering a business process improvement (or some other) initiative, we also want to communicate to motivate the right behaviors. However, initiatives often seem to use buzzwords or use titles familiar to employees that have seen such initiatives come and go (the key word being “go”).
In previous articles we covered design for six sigma and design for lean. Now let’s take a look at Design for Assembly. We’ll do this by following the Design for Six Sigma (DFSS) thought process, and add design for assembly (DFA) subtopics as follows:
When it comes to ensuring a task or deliverable is accomplished, we often see the word “owner” used. Perhaps surprisingly, there really is no true ‘owner’ of anything in the context of program or project management.
We can begin explaining this with two adjectives: responsible and accountable.
In this article series, we covered several topics in the area of product development and project management. We will now begin to explore process improvement with the topic “Design for Lean”. While design for lean may be a subtopic within product development, it helps us understand operational risks, operational costs, enables operational planning and process improvement.
Previous articles have covered product development tools and methodologies such as lean product development, agile, design for six sigma, product life cycle (PLC) and project management processes.
In this article, lets consider “the product” being developed any hardware product, software, IT system, service or new business process. We’ll use the acronym “PSSBP” (Product, Service, Software, Business Process) as an all-encompassing placeholder and to illustrate critical thinking on the topic as follows:
In a previous article, we defined design for six sigma (DFSS) as a thought process focused on maximizing customer value and minimizing cost.
More specifically, DFSS is used to reduce variability in product performance (thereby increasing value), using analytical models and our knowledge of manufacturing variability to enable specification limits on difficult-to-manufacture tolerances to be increased (thereby reducing cost).
For the majority of organizations, long-term success is tied directly to the new product development process. Tomorrow’s revenue and growth are tightly bound to how successful you are at launching new products.
…fewer design iterations to achieve the same goals (reduced time to market), more efficient production and delivery processes (reduced operating costs), fewer defects & warranty costs during the entire product life cycle (increased customer satisfaction).
