Your Reliability Engineering Professional Development Site
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.
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 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…]
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”.)
In this article, we’ll compare and contrast the definition of a requirement, with a ‘story’, which is used in agile/scrum.
The framework for each is somewhat different, however.
Recall the definition of a requirement:
…a requirement defines “what the product (or process) design shall provide <output> at operating conditions <input>”
The framework of a story is as follows:
In this weeks article, we’ll explore how the three disciplines (product development, process improvement and project management) can enable change management.
First, it’s worth reflecting on how these disciplines fit together. Starting with product development our goal is to understand customer value, and to optimize the product (or service) by maximizing customer value and minimizing cost. It can be seen that, process improvement naturally complements this objective as way to further reduce costs. In addition, project management establishes how product development and process improvement is planned, executed, controlled and monitored.
Now let’s look at some key attributes of change management, along with elements of the three disciplines mentioned above.
All projects or programs have a formal or informal resource management process, with the goal of completing projects on time, within budget and with good project quality.
In order to meet this goal, the resource management objectives are:
In a previous article we compared and contrasted the role & responsibility for a scrum master vs. project manager/core team leader (CTL/PM).
In this article, we’ll take a closer look at the scrum product owner role and compare it with the product development team’s “opportunity champion”.
In a previous article, we explored agile product development with a focus on early product validation.
In this article, we’ll compare and contrast the role & responsibility for scrum masters vs. project managers/core team leaders.
Let’s start with (all) the basic scrum roles:
Many companies pursue a product development strategy that provides a product (or service) which meets customer needs sooner (rather than later), and then makes adjustments after the product has been fielded.
Pursuing this approach means accepting the associated risks. What if a critical to quality or critical to reliability characteristic fails to meet customer needs? A product could fail miserably by eliminating important product development work scope and accelerating time-to-market. By the time an adjustment or “pivot” can be made it may be too late, or too costly to correct.