From the life of a requirement — from start to finish

Allow? The default life cycle model

All of this can be represented in the default life cycle model. The model is an excellent starting point for the question: How can we deal better with our requirements? The fictitious Opti1 GmbH also asks itself this question below — and answers it using the 8 phases of the standard life cycle model.

Hands-on: The default life cycle in practice

The initial situation: The introduction of new IT tools at Opti1 GmbH has always been quite bumpy up to now and has led to many inquiries and improvements. That is why the company now wants to establish a binding procedure for the introduction of new IT tools.

‍

Stage 1: Create a preset

At the beginning, the IT department at Opti1 GmbH collects typical steps for introducing a new IT tool and drafts a corresponding process description. In doing so, she pays particular attention to clearly defining roles and tasks. In addition to personal experience, colleagues from other teams and Internet research serve as sources of information.

Phase 2: Coordinate the requirement

It is now time to coordinate the content of the created specification. To do this, all roles involved in the process come together: Together, the IT department, management and data protection officer check whether the requirement can be implemented in practice and weigh up the benefits and costs for the company:

• Who can suggest new IT tools and initiate their introduction?
• Who is testing new IT tools technically, commercially and in terms of content?
• Who has the power to decide on risks and exceptions?
• How and where is the decision for or against a new IT tool made?
• ...

The results flow directly into the process description.

Phase 3: Release preset

In the third phase, the drafted specification is now approved as a process description and therefore comes into force. As in most organizations, this is also done at Opti1 GmbH via a firmly defined approval workflow in the management system: Management, IT management and compliance officer must agree to the new requirement — otherwise it goes back to phase 2.

Stage 4: Publish preset

Approval has been granted! It is now time to inform all employees about the new requirement. To this end, the IT department writes a circular in which it points out the new process in the management system. The email also contains the document “Introduce Quick Check IT Tool”, which allows the individual departments to present the new requirement in their meetings.

Phase 5: Train requirements

In this phase, it is ensured that all affected employees are aware of the current status of the requirement. The IT department of Opti1 GmbH decides to actively answer questions about the new approach at every department meeting. In an Excel list, IT ticks off the individual departments one by one.

Other organizations also see new requirements as a paycheck on employees or require confirmation of reading the process description. In exceptional cases, standard-compliant proof is also obtained at this point that all affected employees have taken note of the requirement (amendment).

Phase 6: Act according to the requirements

Opti1 GmbH is introducing two new IT tools and is thus putting the new requirement to the test. This phase is particularly important because it is only now clear whether employees are complying with the requirements — and whether it is practical and effective. In our example, the practical test is successful: The entire team is pleased with the newfound confidence about “how to do it right with us.” Strictly speaking, the value of the requirement only takes place here, because it is only now that the requirement influences the actual actions of the organization.

Phase 7: Check and audit compliance with the requirements

Depending on the type of requirement, it makes sense to systematically check its effectiveness. This usually takes the form of regular audits, which compare actual behavior with the documented requirements. Half a year later, Opti1 GmbH has also come: IT management wants to check whether the new procedure for introducing IT tools is actually being followed. Since new IT tools usually incur costs, invoices serve as a point of review. Here, auditors are appalled to discover that four new IT tools have been introduced in the last six months. Since the implementation was only carried out in accordance with the new requirements in two cases, compliance with the process is a 50:50 opportunity. There is grumbling, retraining and a tightening of the requirements is being planned: It should become even clearer what exactly is meant by a new IT tool. This brings the default back to phase two.

Phase 8: Deduct the requirement

At the end of the eighth phase, the life of a requirement comes to an end. Four years later, the process of “introducing a new IT tool” at Opti1 GmbH is largely carried out using a project tool. Thanks to automated tasks and messages, it is now barely possible to deviate from the defined process. The company actively submits the original requirement and archives the corresponding process description so that no one accidentally follows the old requirement.

More added value, more efficiency

A new requirement always has an overarching goal: more added value or more efficiency. Viewed soberly, only phase 6 generates measurable entrepreneurial added value. All other phases could also be described as a necessary evil. Or as valuable steps that contribute to the overall goal and make the change in behavior possible in phase 6 in the first place.

One way or another, it always makes sense to optimize all phases of the target life cycle. A management system that simplifies many steps through automatic information flows is helpful here. We will explain what this actually looks like in the next article on the default life cycle model. In the meantime, the interested reader can consider: How can I improve my organization's lead life cycle? In which phase is there currently the biggest waste?