Imagine a world with no capital projects. We’d have no high-speed trains, no nuclear waste facilities, and no cruise ships. At a recent IBM IoT Watson seminar on Systems Engineering in Capital Projects, we learned about the latest and greatest projects; including the high-impact Crossrail project that is to add 10% to the London commute capacity, presented by Chris Binns. Many wouldn’t think of all the dependencies (or coupling, as referred to in Systems Engineering) that the new high-speed railway have on existing Network Rail stations. An example is the lifts that need to be upgraded throughout existing stations to cater for accessibility requirements that were set out by the Crossrail project.
Increased risk & cost escalation
But these expensive and high-risk initiatives are not the sole property of high-speed train projects. Paul Fechtelkotter from IBM showed us the many forms of capital projects and systems engineering. A number of industries, such as oil and gas, suffer from cost escalations, with the number of engineering hours per asset skyrocketing, and productivity falling.
Typically, capital projects have a global impact, and as such, increased risk. Increased risk is also due to often having to project hundreds of years (or hundreds of thousands of years in the case of nuclear waste facilities) into the future.
As we were at an IBM Watson IoT seminar, it wasn’t surprising that the impact and the many uses of IoT were explored. In particular, IoT allows us to monitor the systems and assets throughout their lifecycle. Whilst sensor-based intelligence often comes with challenges when adopted across the sites with geographical variations (such as temperature), they help futureproof the system especially in industries with many regulations. It should be noted, though, that IoT is not limited to “devices”, but concerns technology and processes used in a wider sense in enabling “smarter living”.
Know your requirements, and know them early
Towards the end of the seminar we had an open discussion, and one of the questions was how to know our requirements 5 or 10 years before we even start a project; for instance, when designing and building a new office? How could we know, at present, the technologies that we could exploit in five or 10 years’ time?
The consensus was that to be able to assess the “unknown unknowns”, we need to perform good problem analysis. And, what was re-iterated throughout the day, good problem analysis is based on sound requirements management.
Further, it is important to catch errors in the requirements early: as the impact from errors increases with time (think of a ripple effect); but on the flip side, any rewards that can be realized earlier in the process will amplify with time. An example of this could be sensors and computing resources for security purposes; which, when deployed early and in the right place, will bring multiplied benefits throughout the asset’s lifecycle.
Document management isn’t requirements management
Another “gotcha” from the day was a reminder that document management is not the same as managing requirements. On average you miss half the requirements or change requests when extracting from a document. One of the reasons for the human errors are around understanding the coupling of requirements, as well as errors in understanding the impact of the proposed changes. Thus, when using documents for managing requirements, the true cost and impact of the requirements are lost, along with traceability.
Paul and the other speakers were very good at demonstrating how requirements management toolsets can be used as part of the “V & V model” (verification and validation model) that is championed by many in systems engineering.
Learning from each other
A seminar that brings a variety of professionals into the same room has the major benefit of learning from each other by sharing past successes. As part of his presentation, Paul shared his views on how we may not only look at, and learn from, successes within our own industry, but also from industries with similarities.
But how to pick the right industries to look at? This exercise becomes much simpler when you separate problem from solution. What is the system culture and what tools and processes are in use? To put it simply, focus on and look for similarities in coupling and complexity of the industry; as demonstrated by NASA (presented by Paul) in the image below.
The one take-home message from the day, and which I’d like to repeat once more, is to separate the problem from the solution and you’re half way there. And, of course, based on the discussions it seems like a good idea to use a requirements management system to use for this purpose. But if I were to suggest that, I would couple the solution with the problem, which is quite the opposite of what I’d like to do.