Among us, walks the engineer, creator, innovator, scientist or student who is tackling a mammoth mosaic of problem solving. Irrespective of our industry, we face projects which at first appear harmless but possess the capability to sprout arms and legs, and turn into a wild beast that requires taming. Whether it be finance, engineering, startups or accounting, controlling what we do, for when is imperative. To understand the common problems I’ll introduce the challenges we attempt to overcome, from there, I’ll introduce Systems Engineering. A discipline of engineering, borne out of the need to understand complexity in WWII and gripped by NASA in the early days of space exploration in order to understand interrelated deliverables, control budgets and reduce risk.
Let’s consider the devils of delivering a project, your first hurdle is comprehending between what your customer ‘wants’ and what they actually ‘need’. It’s then up to you as ‘the creator’ to interpret this into a tangible set of specifications or requirements which are used to develop the solution. This simple task can be misinterpreted which becomes the starting point for project failure. This initial doubt is the beginning of scope creep. Scope creep is where new capability or system functions get added to the initial scope of work, thus creeping the project boundary out slightly. The resultant impact of this is chaos. A small scope change can reap major knock on effects. What are these effects? Losing sight of what you intend on delivering breeds confusion among your resources. Review meetings turn into arguments and defensive encounters in an attempt to reduce or minimise the amount of effort required. Treasured resources begin to lose job satisfaction due to stress and overworking. Productivity goes through the floor. Budgets begin to go wild because resources are spending extra time delivering additional scope. All of a sudden, your deadline has been missed by 6 months, your customer is unhappy, your budget is inflated by 30%, and your resources are leaving. You're left with an almighty project disaster.
You’ve more than likely encountered these problem’s before. You understand the havoc they can wreak in achieving your goal. It’s likely that the program you’re involved with right now has seeds of doubt! You’ve heard rumblings about added functionality, lack of resources and lack of budget. It’s painful. It’s the equivalent of professional pain. It’s like being out in the garden and being stung by a nettle or stinger. It’s sore, annoying and frustrating when you learn it could have been avoided. You learn to live with it. That’s the type of pain you're feeling.
Introducing you to Systems Engineering
Systems Engineering is a tool, methodology and discipline which you can adopt to drive certainty into your project. It enables you to deliver on what was planned and handle the riskier parts of a complex project. Below, I’ll outline its origins, it’s core components and how you can begin to utilise it on your own project.
It originated during WWII when Britain conducted a study of its air defence system, a true ‘system of systems’, exploring the concept of repelling German invaders. Since then, it’s been the focus of study groups and institutions. NASA adopted it during the space race to manage the complexity of building space ships. It’s linear, iterative and recursive processes drive you to understand the customer, implement official gate reviews and stick to a design that has an acceptance plan. The outcome is delivering a system or solution which is safe, as specified, on time and within budget.
There’s two main viewpoints worth exploring. The theory and standard which define the ‘official’ accepted meaning and interpretation of SE. These are agreed by the International Organisation for Standardisation (ISO) and the International Council of Systems Engineering (INCOSE). To maintain rigour, I'll use the definitions straight from the ISO Standard of 15288 - Systems and Software Engineering (system life cycle processes) and the INCOSE SE Handbook. It’s also worth exploring the practical applications in your project. Not everyone follows the defined standard to the letter and it’s important to reflect that. Whether you’re a student, engineer or experienced practitioner in another discipline, I aim to introduce you to core concepts so you can become familiar with SE. The aim is to understand how to begin to reap the benefits in your project. Let’s begin.
What is Systems Engineering?
ISO 15288 defines Systems Engineering as an interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution and to support that solution throughout its life
To comprehend this, I tend to further elaborate upon SE as a methodology used to deliver a project with defined stages where each stage has clear and concise inputs, processes and outputs. By fulfilling each phase in line with the ‘V Model’ (explained below), it enables someone to join at any stage of the project and pick up where another left off. In start up parlance, a user need is recognised. This need is translated into a requirement which upon a solution is designed to fulfil this requirement. Before build, analysis is conducted to understand the strengths and weaknesses of a solution. The ‘solution’ also contains how the system shall be validated and verified. Most importantly, determining how a solution shall be deemed ‘safe’ is considered early on in the process. Risk and successive risk mitigation is carried out throughout the project to ensure successful delivery.
The V Cycle
A core component in understanding Systems Engineering is the ‘V Model’ or ‘V Lifecycle’. The cycle covers the whole life cycle of a system from ‘cradle to grave’. In Figure 1, The ‘V Cycle’ contains each of the 14 phases of activities / processes carried out over the life cycle of a system. In its simplest form, that is Systems Engineering. It’s a bunch of activities, carried out in a linear progression (with some recursive or iterative loops included).
Figure 1 - The V Cycle or 'V Model'
The process starts in the top left corner at (Business Case), flows down through each process and finishes in the top right corner (Disposal). You’re perhaps familiar with some elements or stages and perhaps have worked across a couple of the processes. The ‘V Cycle’ captures the activities required for a successful system development from concept all the way through life, say 25 years later at disposal.
It’s likely you have worked in one of these processes within your organisation or career. For example, ‘designers’ such as coders, graphic designers, or mechanical / electrical design would sit within ‘Design Definition’. Your brief would more than likely have come from an earlier phase such as ‘Architecture exploration’ or ‘requirements specification’. These all tie into the initial phase of understanding stakeholder needs and the business case.
It’s becoming increasingly important for engineers to understand the whole ‘V Cycle’, irrespective of their discipline. Why? The systems we are designing are beginning to cost more due to their higher levels of technological complexity. This in turn means it's harder to qualify these systems as ‘safe’, often meaning that the impact of an ‘unsafe’ system is catastrophic. How is this linked to you? Consider you are a designer in the design definition stage. It’s imperative your design fulfils the stakeholder need first time. If it doesn't, it’s likely to incur redesign or even worse makes it through to later stages where the error is carried forward. Both outcomes are costly to the project. A great design considers the need, requirement and most importantly, how their design fulfils the need and how it can be proved or ‘verified’. This makes it easier for the solution to be qualified as safe once built and transitioned into service. ‘Right first time’ may take more time initially, but it’s time well spent. When it comes to your project being audited, having a trail of evidence from requirement, architecture, design, testing method and then a nice stash of qualification evidence at the end of the trail is the beginning of a successful sign off.
Furthermore, ownership is increasing in organisational structures. Quite often as an engineer, designer or scientist you own ‘the system’ without understanding its origins or qualification needs. The V Cycle is the best place to understand who owns what.
One note worth mentioning is the recurrence of validation and verification in Figure 1 of the V Cycle. I’ve outlined those definitions below for further understanding, but during the V Cycle processes, those activities are recurring regularly in order to ensure you’re on track. More on this later.
Understanding core components
In ISO 15288, there are 4 main categories of processes. They are:
14 Technical Processes
7 Technical Management Processes
6 Project Enabling Processes
2 Agreement Processes
The 14 Technical processes are essentially the ‘V Cycle’. The 7 Technical Management Processes are focused on delivering the program and decision making. The Project Enabling Processes consider the enterprise level components such as Human Resources and Quality. Agreement Processes consist of Acquisition and Supply methodologies. The standard also includes a bunch of definitions to define the discipline. A common pitfall of a project is a lack of understanding between people. SE refers to an ‘ontology’ which is a pre-agreed set of terms where people can refer to. Seems simple enough right? Making sure everyone is working on the premise that ‘X’ actually means ‘X’ and not ‘X+2’ can save a lot of time in meetings or time spent correcting homework.
If you’re aiming to sit your ASEP / CSEP exam, knowing the above processes inside out is imperative!
There are a bunch of other terms worth exploring to further an understanding of Systems Engineering.
What is a System?
A system is defined as “a combination of interacting elements organised to achieve one or more stated purposes”
To avoid arguments, it’s easier to refer to something as a system instead of it’s name. This makes sense when you have to decompose the product you’re discussing. If you want to discuss a ‘computer’ for example. The ‘computer’ becomes our ‘system of interest’. It’s now more effective to talk about the system in it’s elements, such as hardware, software, materials, functions and form factor. You can put a boundary around the ‘system of interest’ to enable more effective discussion. This makes sense when it comes to adding things which may make discussion more difficult. If we begin talking about the internet, a computer is connected to the internet but how do we differentiate between the two? Talking about ‘systems’ helps.
What is Systems Thinking?
‘Systems Thinking’ is the use of scientific thinking methods to perform a deep analysis on a system. The methods range from scientific principles of ‘reduction-ism’, dynamic modelling, behavioural analysis, and ‘soft systems approach’ which aims to understand the human impact on the engineering of the system such as attitudes, practices and procedures. System’s Thinking is typically conducted in the ‘Stakeholder needs’ phase of the ‘V Cycle’ as a ‘trade study’. It’s a nice way to actually develop a real world understanding of what a system does, what the outputs are and how we can better engineer the system from scratch as opposed to applying a quick fix. Most importantly, it recognises the ‘Human’ as an interacting element of the system.
What is Validation & Verification?
These are probably the most confused terms used in the industry of engineering. So much so, that the ISO15288 had to be updated with a note to provide further clarification. The notes are actually better than the definition! Why are they important? The combination of the two ensures that your product meets its purpose.
Validation means...
“A system is able to accomplish its intended use, goals and objectives (i.e., meet stakeholder requirements) in the intended operational environment. The right system was built.”
Verification means...
“Verification is a set of activities that compares a system or system elements against the required characteristics. The system was built right.”
Ah! Gosh, even these descriptions aren't very good, are they?! These two terms underpin the entire discipline of SE. They are the yin and yang of building a great system.
An interpretation…
Validation is making sure that the thing you are going to build is actually needed by the user or stakeholder. It means the system you’re going to build fulfils the need completely. Verification is checking that the system you built, actually works. It's testing that the system fulfils the designed function.
What is the role of a Systems Engineer?
A ‘System Engineer’ typically acts within a role in the V Cycle to facilitate the delivery of a project. There are a variety of roles, some more specialist, others more generalist. To give some examples, a Systems Engineer may act as...
Researcher - conducting trade studies, to understand user needs, market analysis and market segments
Requirements Manager - developing & managing customer requirements derived from user needs. Requirements on big projects can be over 10,000+! They ‘assign’ requirements to teams to be fulfilled and then manage the evidence to support the qualification of the requirement.
System Architect - Architecting potential architectures for the system requirements. These could be software architectures, physical architectures or a combination of multiple architectures designed to fulfil the requirements
System designer - Utilising the architecture specified, a designer designs a system solution that meets and fulfils the specified requirements. This could be electrical schematics, system components, control systems etc.
Modeller - modelling the design in a software such as CAD, FMEA, MATLAB, Rhapsody to understand its strengths, weaknesses & performance. This information would be relayed back to the systems design team to make amendments to a design.
System Integrator - Not the most common role, but an integrator or implementer would carry out the build of hardware / software that goes outside the specification of a manufacturer. Something that isn't Commercial off the shelf and requires cobbling together and then integrating. It’s a weird and wonderful role.
Test Engineer - Testing the product or system function as per the test specifications and test scripts. This may be on a test rig, in a laboratory or commissioning the product into service
Safety Engineer - Writing and supplying evidence as to why the product is deemed safe. Utilising the requirements specified, they make safety calculations and analysis such as Failure Mode Effect Analysis (FMEA) and provide this evidence to authorities for certification.
Maintenance & Upgrades - acting in a role to provide in service upgrades or maintenance programs such as Integrated Logistical Support (ILS). Supporting the system after it’s been built and commissioned
Why may it be useful to apply to my project?
Risk reduction. What is risk? In engineering parlance, ‘risk’ is a perceived event or scenario which may cause a critical or project threatening effect or outcome if it is realised. In projects, it often lies in technical uncertainty, resourcing issues, delivery schedules or environmental concerns. For example, a common project risk across any industry is say, ‘designing and building a system function which has never been done before’. It’s risky because you're covering uncharted territory. There’s a risk you might go wrong in development and miss the end target. You might run out of time. You might not have enough people to deliver it on time. These are common risk examples for a technical project.
Systems Engineering presents a logical flow for each phase of a project to enable you to handle and mitigate this risk. I’ll show you. Let’s run through an example.
Example SE Process
‘Dave’, your customer, has come to you and stated that he ‘wants to go to Mars’. Okay Dave, we can help. As a Systems Engineer, here are some of the steps we’d cover:
Determine the business case - Determine if it’s commercially feasible to carry out the project, understand the market, competitors, competing products, current trends in the market place and if it’s a smart business move to conduct the project.
Determine the users need - spend some time researching Dave’s need and why he needs to go. Turns out Dave’s killing his own planet and actually does need to go to Mars to stay alive. Dave has a validated need.
Requirement - formally translate his need into a requirement. Understand how you can verify you have met his need and determine performance measures.
Figure 2 - Dave searching for a solution
** It’s easy to make your requirement complimentary to Dave’s need. Good practice in Systems Engineering avoids doing this. As an engineer, we could fall into the trap of giving the customer what they want instead of what they need. For example, a requirement such as ‘A system which shall enable Dave to travel to Mars’. This is pretty costly but it’s what the customer wants right? Perhaps your studies might find, Dave just actually wants to live on his planet without the threat of extinction. It’s important to avoid solutioneering in your requirement creation. A more precise requirement would allow the system designers an opportunity to explore multiple designs later on. Avoid designing in your requirement phase, keep an open mind. A more succinct requirement would be ‘A system that enables the user to live without extinction’. That’s quite an open ended requirement and would need further requirements below, defining what his needs are, e.g. clean air, water etc. However, your talented team of designers may come up with a cost effective solution of cleaning up Dave’s current planet for a lot less cost than say building a spaceship to send him to Mars.
When you have a full understanding of the environment, requirements and measures of performance. You would present these to the Customer for sign off and acceptance. In the Figure below, an example user need and the operational concept of the system is defined.
Figure 3 - Operational concept of how the System shall operate
They are super vague, but they offer an appreciation of what Systems Engineering looks like. In the Figure below, a more specific set of requirements have been created to start to narrow the scope of the project. We’ve transformed and understood our customers' complex need into something that is achievable. We know what our design has to entail, what the success of that design looks like (e.g. a solution with at least 30,000kN of thrust) and how we intend on testing it. This is a simplistic worked example and we’re overlooking a whole bunch of things such as safety, standards, failure modes etc. Most importantly, you can see how the risk is immediately reduced in the project from ‘oh how are we going to do that’ to ‘okay, now I know what the key things to success looks like’.
Figure 4 - System Requirements Specification
From there we can move onto...
Architecting and Designing - exploring architectures and design solutions which fulfil your requirement. Present several ideas to Dave to gauge his thoughts and his budget
System Analysis - run models of the solution, determine their strengths and weaknesses. Understand how it fulfils the requirements including safety, qualification and failure modes
Build, Test, Transition, Maintain & Dispose - Once the above stages have been agreed and defined, we then have the complex task of finding a manufacturer to build our solution. It then goes through a rigorous testing program and if successful transitions into service.
Hopefully, Dave walks away a happy customer, whatever the solution may be. You can be confident that you’ve reduced the technical risk of uncertainty by following the V Cycle and acting as a Systems Engineer!
You’re interested in applying it to your project, where do you begin?
The answer? Anytime, anywhere.
It’s unlikely you have the luxury starting at the very beginning of a project, up in the top left hand corner of the V Model. That's okay, very few Systems Engineers do. Quite often, SE’s join projects where they are at the point of going wrong, so often have to pull the project into the V Cycle whatever phase you’re in.
If you’re in the design phase, say, it’s worth pausing and spending a few days, weeks or even months, base lining where you are and what you’re delivering. Go back and understand your customer's needs. When this is clear, define your requirements and give them numbers. Understand what shall satisfy these requirements and ultimately your customer needs. Then you can begin to explore architectures or designs which satisfy your requirements. It can take a bit of time to rationalise all of this content into a logical manner, but once it’s done, it’s a lot easier to communicate with your team or customer, who’s doing what and for when.
Figure out where you are on the V Cycle above, and begin to put all the pieces of the jigsaw together.
It’s important to apply the right amount of Systems Engineering. Too much or too little can kill a project. You want to walk the SE tightrope between the valley of ‘analysis paralysis’ and ‘f*ck it, just do it’. If it's a Start Up, 1 page with a well defined need, requirement, design, test case and expected outcome can be more than sufficient, if it’s a military helicopter then having 10,000+ requirements is advisable to make sure you haven't missed anything…
Other aspects
There's a bunch of stuff which I haven't spoken about. I’ve focused heavily on the early stages of the V Cycle as opposed to the latter stages. This is an introduction into SE only and I know that’s the best place to start! Once you’re on the V Cycle, there’s a wealth of information out there to help you along. For example there’s experts out there that will chastise this article because I've forgotten to mention core elements further along such as ‘Safety, Reliability, FMECA, FMEA Whole Life Costings, Fault Analysis, Project Management, Decision Making, Headline T&C’s of contracts, etc etc.’ Not to worry, that may be covered in another article down the line.
There’s a whole lot more to SE, but for now, we can put a boundary around the introduction stuff to keep it palatable. If you’re interested in learning more about Systems Engineering, get in touch!
Conclusion
Systems Engineering is a powerful discipline and growing among industries. It’s commonplace in large infrastructure or defence projects where it’s clear that it's needed to control complexity and cost. It’s beginning to show face in Start Up’s to provide a strong foundation for a product without the need to backtrack down the line. We’ve covered the defining components of the discipline and outlined the technical processes which drive the standard. We’ve explored what the role of a Systems Engineer is. We’ve delved into how it can be applied to your project, where to begin and what each stage looks like. Most importantly, the ‘V model’ or ‘V cycle’ is your newly equipped tool which you can use to tackle complexity and drive understanding into the layers of your project! Good Luck!
If you’d like to learn more about Systems Engineering, check out our free or affordable courses at www.schoolofsystemsengineering.com/courses
Comments