How to reconcile speed and control within system engineering
By: Anders Ekman, Simone Bernardi, Celeris AB
Introduction
System engineering has been through several paradigm shifts during the past 2-3 decades, where two predominant trends during the past decade have been a) agile development and delivery, in the pursuit to reduce time to market and b) compliance and regulation, in the pursuit to contain risk.
On one hand, you want speed. On the other hand, you need control.
Where we come from - Control
At the outset, the main task of requirements management professionals was to produce requirements specifications. The requirements professional had a strong grip of the domain and a good understanding of possible solutions and wrote specifications with limited involvement from current and future users. Modeling techniques, such as UML, emerged to offer even stronger control.
The requirements professional was a master on producing well-organized and coherent requirements specifications.
With a low rate of change, modest user expectations, and with little pressure on time to market, the setup did work for several organizations. However, substantial time was spent on documenting findings and concepts rather than on engaging users or on writing code.
With increasing rate of change, deregulation of local markets, and with increased ease to switch to alternative providers of services and products, what some referred to as “analysis paralysis” had to be addressed. The remedy was to adopt agile techniques. A wave of activity ensued to increase speed of development and delivery, which led to where we are now.
Where we are now – Speed
To many organizations, the adoption of agile techniques made it possible to spend more time on core tasks, such as engaging users and on writing code. The speed (velocity) of the development effort would accordingly improve.
The requirements professional became the workshop facilitator, with the aim to bring stakeholders together to gain a joint understanding and needs and requirements, while developers used whiteboards with Post It notes to coordinate development efforts. Within many organizations, modeling techniques declined in use.
The pendulum had swinged heavily from control to speed and with the high-velocity approach came the challenge of documenting a system to sufficient detail to simplify system maintenance (of the total lifecycle cost of a system, significantly more money is spent on maintaining the system than on developing the system and hence, maintainability is a main concern from a lifecycle perspective). Add to this increasing regulatory pressure on many organizations, and it is apparent that one needs both speed and control, which leads to a projection on where we are heading.
Where we are heading – Speed and Control
The initial pursuit of agile techniques relied upon workshops, whiteboards and Post It notes. Even if those who attended the workshops or were part of shuffling Post It notes at the whiteboard session had a firm grip of things during the session, people tend to forget and people tend to change duties. To allow for sharing, reuse, tracking and preservation of information to future team members, the knowledge needs to be recorded digitally.
Initial attempts at using tools for workshops and for daily team meetings delivered mixed results. The tools were not trimmed for speed and efficiency and stakeholders were not used to run conferences instead of physical workshops.
Recently, collaboration tools have improved, and stakeholders have become increasingly proficient in using these tools (many of us use tools such as JIRA, Azure DevOps or IBM Engineering Workflow Management on a daily basis and with limited effort). What was earlier seen as a bottleneck –documentation – has turned into an enabler that, if used well, will turn into a competitive advantage.
While collaboration and communication are critical capabilities for any requirements professional, the need to document requirements, and the need to document certain requirements meticulously, will be prevalent in development efforts. Accordingly, the successful requirements professional will be a polymath who masters a host of requirements management techniques, has good judgement on what technique to apply where, taking into account aspects of velocity and accuracy in representation, and who has comprehension of tools for modeling, requirements management and collaboration.
