We’ve been talking about some of the issues with Product Development. Today I’m going to talk about a problem present at the start of projects. There is consistently a lack of clarity in the goals or requirements coming into engineering. Software development has made significant progress in managing this problem, but in hardware engineering it persists.
Clarity of goals is important. Clarity is one of the hallmarks of an achievement culture. If you’re trying to achieve something in a project the more clear things are at the beginning the faster you can make progress and the better you can make headway towards the accomplishment you’re trying to achieve.
We used to hear about engineering “throwing things over the wall” to manufacturing. There is a similar problem at the beginning of a project where work is thrown over the wall into engineering without any kind of clear objective or explanation of what is trying to be accomplished. In our consulting experience we’ve run into companies where individuals have spent the beginning of a project just trying to understand what is being asked of them and what a project is all about. Once they’ve figured it out they still need to gather whatever supplies or materials they need to start making progress towards the goals of the requested work. Both of those steps are absolute efficiency killers. If you’re familiar with the efficiency statistics in engineering, then you know that the amount of time engineers typically spend engineering and creating value for customers is pathetically low in US industry.
Software rather than hardware has made significant progress in improving efficiency. They have done two things to increase the efficiency of their resources: implemented the use of use cases (Use Cases explain how somebody is going to use their output product), they also use “stories” in software development techniques such as Scrum. In the case of stories, someone making a request of software engineering will make a request and the request will have three specific parts. The request will say 1) who it came from (name and role of the person making the request) 2) what is being requested (generally the statement of “what” is very simple) and 3) what is the benefit that will be recognized by the organization (the benefit statement of executing the work)
When something like a Scrum “story” is generated, it doesn’t go directly to an engineer’s desk to be executed. There is another step that is fundamental to the role of managers. This step ensures engineering efficiency is optimized and removes anything other than the executable work from the engineers. This is the role of filtering the requests. Filtering requests can take various forms and is done by managers. It is in place to make sure that when that work arrives on the desk of an engineer, the goal of the work is absolutely crystal clear. This is the primary lever of change that will enable significant increases in software and hardware engineering efficiency at American organizations.
Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive.
Follow Bill at http://www.twitter.com/systhinking
