Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
In the previous article, I shared how employee fears can negatively influence the work culture of your organization, stifling innovation, hampering collaboration, limiting growth and preventing continuous improvement. In this, the second article of a 3-part series, I’ll share the elements of an effective tool to evaluate your organization for employee fears and the impact of those fears.
[Read more…]
In any organization, effective leadership is crucial to driving success and achieving goals. However, one often overlooked aspect of leadership is the role fear plays in an organization. Fear and its negative effects are present in every organization but rarely identified or measured. And when employees are afraid, they are less likely to take risks, share ideas, or give clear, honest assessments of risk. In this first article of a 3-part series, I’ll share the general effects that fear can have on your organization. And in the follow-up articles, I’ll share what can be done to identify, measure and mitigate these fears. In the end, employee fears stifles innovation, hampers collaboration, limits growth and prevents continuous improvement as detailed below.
[Read more…]
In the world of research and development, time and money are precious commodities. DOE is the one statistical tool to save both time and money through its efficiency and efficacy. By carefully planning and executing experiments, DOE not only saves time and money but also leads to optimized designs and improved outcomes.
[Read more…]
Often, when the completion of a task or deliverable is needed, a meeting is a good way to establish mutual understanding of the way forward. With many resources working remote these days, effective meetings are taking on even greater importance.
In a previous article, we compared and contrasted the definition of a requirement, with a ‘story’, which is used in agile/scrum. In that article, we stated: “requirements and stories establish a clear understanding of customer needs in the context of desired functionality”.
What if we want to establish a clear understanding of a customer’s needs in the context of desired business functionality? The customer can be an internal or external customer, business functionality can be a business process (IT-enabled or otherwise).
A complex production process requires a mixture of leadership, governance and management. In this article, we’ll discuss a tiered meetings structure that can effectively enable this. Empowerment, escalation paths, accountability and responsibility are included as some key ingredients. We’ll start with the following diagram:
In reviewing several previous articles in this article series, it’s apparent there is much in common with product development, project management and process improvement.
Let’s look at a brief list that considers a structured approach vs. unstructured
While this list is pretty “high-level” it reveals the importance of project leadership, governance and management. A structured approach (for example a phase-gate structure, DMAIC or agile/scrum) enables management and planning, which enables governance and governance enables leadership.
Some structured approaches may be more suitable than others depending on the type of project. However, any structure (with leadership, governance and management in mind) is probably better than none.
Our previous article identified several forms of waste, specific to completing tasks, as detailed by the following table:
Keep in mind, by focusing on tasks, this table assumes several things:
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.
