Ideas for Operative Project Management

Brainstorming session with Hanno, Holger and Raphael during the "Konzeptentwicklung FAIR-Patterns" on 2023-10-10

Motivation

We are now at the point that we want to make the transition from strategic planning (for which we have a decided upon a plan up to the 2026 beamtime and crafted a milestone and dependency overview) to some form of operative planning which can be used to determine who does what and when during the implementation phase. There are plenty of options for doing that and it's not really clear how to best bring together the multitude of sub-projects to achieve some form of consistent progress monitoring, so the participants bounced some ideas back and forth on what they think might make sense.

Planning Subprojects

The complete structure of subprojects for the Injector Controls Upgrade (ICU) project is yet to be finalized, but during the creation of the milestone overview, the most important ones have already been identified: Applications, BSS, Data Master, LSA, LSA model and MASP. There are quite a few other teams and departments that must provide certain components for the overall project, though. So one of the main questions is which subprojects should be planned to which level of detail.

The current idea is to have a core team that plans their activities in a relatively detailed manner for short time periods to ensure close cooperation and high momentum. This could be done in an agile manner e.g. with sprints that span two weeks, matching the time between two ICU JF meetings which would allow for being able to report on past sprint progress and plans for the next sprint. One option might be to make sprints start and end on Tuesdays before the next JF on the following Wednesday. Other subprojects would be managed in a more superficial way via more coarse-grained tasks and milestones contained in the overall project planning gantt chart, with detailed planning being left to subproject leaders.

The core team should probably consist at least of the following members:

Name(s)	Responsibility
Peter	Project lead, UNILAC expert
Hanno	Architecture, Technical concept
Raphael, Andreas	LSA
Stefan	BSS

Responsibilities for LSA and BSS would not be as distinct as shown above, as the idea was to form a joint BSS/LSA team that implements the new Chain Groups concept. The reason behind this is that the new concept relocates quite some functionality currently contained in LSA towards BSS, requiring very close cooperation between the two teams and making it implausible for Stefan to tackle the resulting effort on his own.

What is not fully clear is whether other colleagues, e.g. Susi and/or Jonas for the LSA model, Mathias for the Data Master or a colleague from APP, should also be part of the core team. As an example, close coordination between the Data Master and BSS/LSA teams would certainly be required, but whether it would make more sense to include Mathias and Martin in sprint planning or rather treat them more like an external supplier of required features needs to be discussed. In principle, it would be conceivable to have them join the core team for certain periods of high activity within the ICU project only, but whether that makes sense in practice is uncertain.

Levels of Planning Detail

It would probably make sense to derive a high-level task planning for all subprojects over the whole project duration (i.e. until the first production run in 2026) within an integrated gantt-based project plan. From there, a more detailed plan, also for all subprojects, that spans the time until the next major milestone (e.g. for now: until the 2025 beamtime / "emergency system" milestone) could be developed. At this point, it would be necessary to clarify whether requests for additional dry runs / wet runs / machine development beam times can be fulfilled or not. Also, project internal development milestones must be defined, e.g. release dates and integration testing periods.

For the core team, tasks on this level of detail could then be transformed or broken down into Scrum-like epics, which would in turn be broken down into implementable tasks once the time has come to actually work on them. This would also allow us to keep the high-level gantt-based overall plan up to date and consistent with...

Tooling

Since we assume that the core team will work in a distributed way at least partly due to WFH, it makes sense to have some digital task planning / kanban tool. Since APP is using JIRA already, it might be desirable to use that as well. Unfortunately, a GSI-/Controls-wide license is not available yet. However, from what we could find out, Atlassian's terms of use should allow for setting up another free 10 user instance for the ICU project. Ben's assumption was that migration from a free "island" to an integrated Jira instance becoming available later should be manageable.

Documentation

From the experience with successfully completed past projects, e.g. Storage Ring Mode, it seems necessary to establish some technical documentation which serves as a single source of truth for all those involved in the implementation phase. Hanno would be responsible for that part. The idea would not be to write a technical concept beforehand and implement it afterwards, but rather to have a continuously evolving document (e.g. in the wiki) that covers the concepts developed so far and incorporates new decisions as they are made.

What remains unclear is whether (and if yes, how) this technical documentation can and should be integrated with the general new Pattern/operation concept document that has been initiated within the "Konzeptentwicklung FAIR-Patterns" meeting series a while ago.

Next Steps

Discuss with Stefan/Vitaliy whether and if yes, to what extent Stefan's time can be scheduled within the ICU project. Stefan said he will have time to get involved in the project shortly. Vitaliy stated that Stefan can be scheduled freely unless conflicts between his projects arise, in which case we would have to talk about priorities.

Clarify requirements for testing periods with and without beam

Discuss and decide with Peter / core team whether this approach is sensible. If yes...