When developing a new product, system or service there are two primary ways you can end up going down the wrong path:
1 - Inadequate requirement capture means that you are developing something that may not work properly due to:
Developing any new product, service or system requires that it be both verified and validated. Providing the necessary assurance can require considerable time, effort and infrastructure to enact and it is important that this is considered from the outset.
Validation is the assurance that the product, service or system meets the needs of the customer and other identified stakeholders. Verification, on the other hand, evaluates whether or not a product service or system complies with a regulation, requirement, specification or imposed condition.
I was recently in a discussion where I was asked to explain the difference between Agile, Lean and Six Sigma. So I thought it would be worth sharing my (expanded) response here.
Starting with Six Sigma we are talking about a set of techniques and tools for process improvement. In particular the emphasis is on using statistical tools and quality management techniques to focus these improvements on the primary causes of defects and variability in a process.
I attended the thought-provoking Warren Centre Vision30 lectures last week. We spent the whole day considering what the key drivers would be for innovation over the next 30 years. So, I thought I'd share some of the key themes with you:
I was recently asked about the applicability of program and project management practices in operations-focused businesses. My view is that it makes very good sense to think in terms of programs for many operations.
There is often a need to achieve one or more specific goals rather than just continue to turn the handle on “business-as-usual”. In fact, most businesses want to become more effective and innovate. Once this premise is accepted then the steps that follow have a similar theme regardless of the nature of the change or product.
The purpose of this brief discussion is to highlight a significant and useful overlap between core Systems Engineering principles and Program/Project design and subsequent management.
Typically, programs are managed to coordinate a set of interrelated projects such that a phased set of capabilities are delivered to the business. The business then absorbs these capabilities to realise the planned benefits over time and deliver the performance enshrined in the Portfolio objectives.
The key here is that the decomposition of the work to be performed when designing a program (or project) will significantly benefit from adhering to the same rules that apply for designing systems.
Last week I was asked a great question: “What strategy do you have when, amongst a small peer group, you are the only one barking?” This was in reference to my previous article "Silent dogs, scouts and beacons"
An important first consideration is that there are probably several reasons why the rest of the pack is silent; the most common simply being a lack of engagement coupled with a narrow perception of the relevant scope.
So, essentially, the focus needs to be on nurturing engagement and incrementally broadening both participation and scope.
I have recently encountered a couple of interesting phrases that are new to me even though the concepts behind them were not. I am sharing them here because both relate strongly to the key point made in my previous article the Lean Startup Iceberg.
Stephen Jenner is a well-respected voice in the realm of benefits management. As part of his collaborations with APMG-International, several of his recent publications have made reference to both “the scout and beacon approach” (Andrew, J.P. & Sirkin, H.L. (2006) Payback, Harvard Business School Press, Boston, Mass.) and “the dog that didn’t bark test” as valuable tools in the arsenal for uncovering emerging or unplanned benefits.
I've been talking to quite a few people recently about using Lean Startup (Eric Ries) and the associated Minimum Viable Product philosophy in a variety of product development situations. Whilst being an avid supporter, my concern is that there is another kind of MVP lurking beneath the surface - a Maximum Viable Product.
An evolutionary process that leverages progressive learning makes sense in many situations where new ground is being broken and there is a high risk that a solution might be unobtainable (at least in the form initially envisaged). Clearly, startups do not have a monopoly on this type of development and such an approach has been used for many years in the defence and oil & gas industries (to name but a few).