How much of your day is spent adding engineering value to your development projects? Think about it for a minute. All that email. That huge list of issues you track in a spreadsheet. Running across the office with those forms because you heard the engineering director finally came out of that meeting. Let’s face it, there’s a lot of non-value added work that goes on every day in the engineering office. In our last post on the hero work of an engineer, we talked about how to use the ‘Get It Right the First Time’ principle to avoid letting product issues get downstream, where they come back as firedrills to blow up your desk. In this post though, we’re going to focus on how to identify non-value add work and then how to avoid it if at all possible. To what end? Well, if you can cut down on the product issues that get downstream and eliminate some of the non-value added work, then your work day can get a lot more normal. To start off, what do I mean by non-value added activities in engineering? First, let me outline the different types of activities in the engineering organization during the design phase of the development cycle.
- Authoring: This group of activities covers the creation of traditional engineering deliverables such as specifications, drawings and models.
- Decision Making: This category of activities addresses meetings and discussions amongst the team or individuals to make engineering decisions.
- Issue Resolution: This set of activities includes the myriad of product issues that arise during the design process that must be resolved to move forward.
- Governance and Oversight: These activities provide visibility into the status of the development project so corrective action can be taken as necessary to stay on-budget and on-schedule.
So are any of these categories of activities non-value added? My answer is a definitive ‘no’. These types of activities are necessary to run a successful development project. However, the depth to which you go in each of these categories can be too far, thereby expending time and effort on activities that are not absolutely necessary. Another area to consider is the effort required to track and monitor these activities. For example, one could track product issues in spreadsheets amongst a team or in a centralized system that acts as a source of truth. The manual effort required to reconcile and propagate change in the spreadsheets in the team is unnecessary compared the use of an centralized system where change is automatically managed. To wrap for today, I think there’s two questions to consider.
- What other areas of non-value activities have you seen in your engineering organization?
- What steps do you take to avoid them?
I’ll be back next week to summarize the discussion and add some final thoughts. Take care. Talk soon. And thanks for reading.