I joined Nefit/Bosch on an assignment from Capgemini to speed up the software development (Matlab/Simulink) running on their boilers. Aside from the application development, I picked up the task to improve the software architecture to enhance readability, I became the sole responsible for the creation of the application requirements and I was leading the team through the various internal quality gates.
Situation Overviews using STAR methodology
[2024] Proofing implementation of customer requirements
Situation – Due to updated Bosch guidelines, proof of implementation of the customer requirements had to be created. Earlier, showing the complete set of application component documentation was sufficient. Initially, the customer requirements were refined into product requirements (including hardware, firmware and software) and the software was described component-wise in functional descriptions.
Task – Link the product requirements to the functional descriptions.
Action – The product requirements were too high level to link directly to the functional descriptions. Therefore, I made an additional layer of application requirements based upon the functional descriptions (bottom-up). Reason for the bottom-up approach is because the functional descriptions were the only layer known to be complete (as it was used previously as proof). Once all functional descriptions had an upstream application requirement, I linked the application requirements to the product requirements. This resulted in multiple extra product requirements mostly describing basic functionality (f.i. since the customer requirements were created for an ongoing project, no requirements were written for the burner actually activating, only the safety scenarios were discussed).
Result – Using the extra layer, the customer requirements were now linked to the implementation. Because of the bottom-up approach, the product requirements were made more complete.
[2024] Passing Quality Gates
Situation – At the same time I started working on the requirements (See previous situation overview), I joined the Quality Gate team, responsible for managing the project documentation and passing the quality gates. When I joined, I saw the progress of the team was slow with the main reason being ineffective meetings (every topic was reopened every meeting) and people not prioritizing the work for this team (everyone was also part of the application development team).
Task – My task was to join the ongoing team and focus on the documentation related to the requirements.
Action – Seeing that the team was reopening a lot of topics, I started making meeting notes focusing on decisions and action items. Soon after I was leading the Quality Gate team and the meetings using the previous action items as guideline.
Result – Due to the recorded decisions and people being reminded of their action items, the productivity increased dramatically. Even though the velocity was low before I joined, all Quality Gates were met within the required timeline.