OK, enough ranting. The basis of knowledge-based product development is the same as systems thinking and systems engineering. See, for example, my blog entry titled "Implementing Systems Engineering in a Commercial Organization," dated November 23, 2009.
Knowledge-based practice advocates (rightly, in my opinion) an empowered product team making design and development choices based on a solid understanding of the customers' and stakeholders' needs. The opposite of this concept is a waterfall approach, which fell out of favor many years ago (again, for good reasons). So, why is there a need to rename and reincarnate an existing concept. I can think of two reasons, based on my experience:
- Systems engineering has a reputation for being too formal, bureaucratic and top-heavy. While unfair, many commercial companies share this view due to their historic knowledge of systems engineering in the aerospace industry from the 1960s. Aerospace has come a long way since then but the opinions persist.
- Systems engineering has a technical and old-school feel to it. In many cases, it is associated with hardware development only, which is a huge misconception.
- Customer and stakeholder needs are clearly identified upfront,
- Customer and stakeholders are represented in the development team to address day-to-day decisions,
- Decision-making is done at the lowest possible level,
- Solutions are produced to address the highest level improvements (i.e., global optimization rather than local maximization),
- Accountability and responsibility is embedded in the development team,
- Team members have a clear understanding of their product and how it fits into the product portfolio of the organization,
- Product architecture is meaningful and well-structured. Both the decomposition and integration are logical and robust.
No comments:
Post a Comment