Introducing Systems Engineering gradually over time in an organization

Speaker: Peter Sjöberg
Venue: Local Speaker in Helsinki.

When you introduce systems engineering in an organization, you can either go with a big bang or do it more slowly, step by step, or a combination. In this presentation it will tell how it was done step by step during the years of 2007-2009, at Volvo Construction Equipment, Components Division, and with a combination of push and pull.

The introduction of systems engineering within the Driveline and Engine departments in the Components Division was related to similar activities within the rest of the Swedish parts in the research and development organization of Volvo Construction Equipment. Those activities, called Early Phases, focused upon the new product developments early phases, until concept selection. The Early Phases was strongly related to IEEE 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process, which the Volvo Group used as the foundation for their Systems Engineering related processes and methods. The champion for implementing systems engineering within the Components Division was its director for Testing, Verification and Standard. His personnel were suffering from poor specifications, which made them performing tests that did not relate to the customer needs, but only to old test specifications. That is usually waste and doesn’t promote good quality.

The first thing to set was the requirements structure of the specifications. The requirements structure was at that time either in accordance with the requirements priority, stakeholders, or life cycle stages. Even though these are important aspects when developing a system, they are poor to use as a structure for a specification, especially when the number of requirements grows. Together with the Hauler Business Line a requirement specification structure was defined, based upon old US MIL standards. This Requirements Specification Structure later became the foundation for the System Specification. After a while, the requirements priority level became necessary to define, including theirs implications.

When the requirements specification structure was released and the projects started to work with requirements as a way to communicate what was to be delivered, it become clear that the stability of the requirements was of importance. In this case, the introduction of a change management process came as a pull from one of the projects.

The way to manage the requirements, verification methods and plans, and the configuration control of these have changed over time from Word documents to excel, to different kinds of databases, and sometimes back again, depending on the projects context and skill level.

A key success factor through all this was the close collaboration between those responsible for the processes and methods development and those for implementing them in the projects. The mentors and process developers always need feedback, to be able to adapt. Another key success factor was to have a clear overall goal, but only implement what brings the most value in the current project, in order to get commitment, and take it step by step where the different pieces connect to each other.