Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
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).
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:
Although I’ve had a profile for about six years, I really only got engaged and active on LinkedIn a little over a year ago. And since then I’ve been compiling a list of the Top Engineers to Follow on LinkedIn.
With “marketers” and “influencers” in every corner of LinkedIn, I caught myself wondering, “Where are all my engineers at?”
And I have to tell you it felt pretty lonely.
Don’t get me wrong – there are some AMAZING, diverse, non-engineers that I’ve met and learned from via LinkedIn. [Read more…]
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.
If you’ve hung around this site, subscribed to the email list, or followed me on social media, you know that I am obsessed with engineering impact. It is how I close every email and is the focus of nearly every article and post. Heck, my tagline is Engineer with Impact. But what does that really mean? And how do we know if we are doing it?
As engineers, we pride ourselves on the ability to problem-solve. And rightfully so. We are dang good at it! We’ve spent years, if not decades of our lives, honing the craft of working through problem after problem, getting a precise solution. But sometimes we get so focused on solving the problem in front of us that we don’t stop to think if the problem is really…well…the problem. And when we fail to solve the right problems, we fail to Engineer with Impact. [Read more…]
In my previous article, we reviewed the project approval committee, and emphasized approval to start projects and/or approve projects in-process.
With any type of project oversight, presentations or project schedules are often reviewed.
“Definition of done” is the agreed-upon evidence of completion of a process, activity or milestone and usually includes a project deliverable. Some examples of deliverables might include the project plan, project schedule, documents (requirements document, plans, and reports), analysis, and designs (drawings). Other considerations can be built-into “definition of done” including compliance, acceptance/sign-off, exceptions and best practices.
Last year, I had the opportunity to hear Kat Cole, Group President of FOCUS Brands at the time, speak on leadership and the power of setting priorities. Cole shared with us her experiences on a service trip in Africa, in hopes of helping nearby villages with humanitarian efforts, and what it taught her about setting priorities. In this article, I will recount her experience and provide step-by-step guidance for how you can apply it to your work as an engineer.
Sound good? Good – let’s get to it! [Read more…]