The risk associated with developing and deploying integrated systems has many dimensions – complexity, novelty, speed, technology, social, political and others. The greater the risk the greater the need for some form of overarching governance and the adoption of risk mitigating approaches.
High levels of complexity are best addressed using a systems approach to compartmentalise the requirement and develop a modular solution architecture that minimises and clearly defines interdependencies.
I have recently been engaged in some quite animated discussions where the other party was confusing several common terms so I thought that, this week, I'd share my views on a few of my favourites...
Invention – is the creation of a product or introduction of a process for the first time. This does not necessarily mean that it is useful on its own and it often needs to be incorporated into a wider system to realise its potential. [eg light bulb, steam engine, wheel]
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’ve been interested in ideas emerging from behavioural neuroscience for some time and I thought it might be worth sharing one of my favourites here. In his book, Your Brain At Work, David Rock likens the conscious mind to a stage in a small theatre with fairly limited resources; there’s a director, some actors and an audience. The stage (pre-frontal cortex) is where thinking plays out. The actors (consciously selected information and external stimuli) and selected guests from the audience (memories and internal models) collaborate on stage to facilitate understanding and inform decision-making.
Recently, I was fortunate enough to attend the first meeting of IoT Sydney where we enjoyed a couple of excellent presentations and plenty of enriching conversation in the breaks. However, the main take-away for me was how far we still have to go in terms of interoperability, safety assurance and contextual awareness.
One thing that struck me was that there seemed to be a lot of situations where we have a solution looking for a problem.
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:
There has been a lot of interest in Agile Project Management in recent years despite the fact that, at its core, Agile is more aligned with single product, team management than projects involving complex systems. Indeed, in Scrum (the most popular variant) there is not even a role for a Project Manager.
A key element missing from some of the popular support tools for Agile software development (eg Jira/Greenhopper, Rally, Basecamp et al) is dependency management.
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).