How to work with the system diagram of a project or enterprise ​

When we talk about a project or enterprise system diagram, we mean not a diagrammatic representation, but a representation in modelers: tables, lists in issue trackers. However, of course, more simple forms can also be used, for example, a list of areas of interest or even alphas drawn on a board.

The simplest use of a project system diagram is structuring a progress report. You just need to provide a brief substantive description of the state of the alphas and areas of interest you have chosen in the creation graph. The diagram (again, not necessarily in the form of a diagram! It can be, and indeed should be, a set of tables in a universal modeler!) maintains collective coherence in the project, ensuring "not skipping any areas of interest, alphas, or sub-alphas." A missed alpha in the description often does not necessarily mean that its state is dire and the presenter intentionally wants to hide it. Yes, this happens, but rarely. Usually, "the world is ruled not by a secret lodge, but by an obvious blunder," and the reason for skipping in the report on the state of a certain alpha means that people simply haven't thought about it for a long time, its state (including its sub-alphas) has not been assessed for a long time, and the need for conscious and structured attention to it has simply been forgotten due to other tasks. And this means that it's time to think about what is happening with the missed alpha and its sub-alphas. The progress report is passing a checklist.

When preparing a report, track omissions in describing the state of affairs for certain alphas or sub-alphas and immediately think (most of the time, this means not just "think," but first gather more information, talk to various role executors in the team and external project roles) about what is happening with them and what needs to be done in relation to this situation. Like with any checklist, in 9 out of 10 cases, everything turns out to be in order, but in 1 case, it prevents an inevitable disaster for the entire project. But sometimes the problem is even that it's unclear which work products can be used to understand what is happening with an alpha, and which executor of which role can report on it: this is the most worrying, as "If you didn't think, then you didn't do it. If you didn't do it, then the system is not successful, unless by chance."

Even just the basic alphas of the adapted and modeled project system in a universal modeler (without transitioning to sub-alphas) are useful not only for making regular progress reports (needed for the entire team and its creators to collectively understand the state of each alpha and what needs to be done next, what risks are present in the project), but also to provide useful substantive feedback on such reports, not just noticing what is said, but what is not said. So, if the report doesn't say a word about the organization/team, as a useful feedback on the progress report, questions must be asked about the state of the team. A lot of important unexpected information can be uncovered (key team members are considering leaving, collaboration has been absent for three days due to various reasons, etc.). These questions about the alphas overlooked in project thinking won't be random questions, as these alphas are chosen for a reason and reflect the experience of numerous developments, encapsulated by the authors of the standard method using areas of interest, alphas, and their states reflected in various work products.

Asking questions about the important project objects or alphas that have slipped the team's attention is managing collective attention in the project, ensuring collective coherence. To do this, computer memory should be used: alphas must be adapted to the subject area and the result of this adaptation documented in a modeler accepted in your organization—perhaps, this will be a distributed model, where different parts will be distributed among different employees, different computers. Then, you must regularly (daily, weekly, but definitely more often than once a month!) go through these alphas, maintaining the team's attention on all these alphas, not just on those alphas they are currently urgently working on. Because while you are urgently working on one, another can quickly burn out—projects require a lot of attention.

Another way to use the project system diagram is to understand what competencies exist in the project team, and which ones are lacking. Print out the project system diagram (as a list or even as a diagram "for beauty") and have project participants mark with a cross the alphas for which they plan to be responsible in this project, playing certain roles. If some alphas remain without their crosses, the project faces significant risks, and this needs to be discussed immediately: who in the team will take responsibility for the state of these "ownerless" alphas?

Instead of a simple survey, there could be an immediate conscious acceptance of responsibility for certain alphas (or sub-alphas) in the project. The project as a whole is broken down into objects that change throughout its course and require special attention (alphas), and the project team takes individual responsibility for these objects—and collective responsibility for coordinating actions related to them.

The systemic approach here is that at no moment is the project as a whole lost, but with the project's complexity, at each moment, you can deal with functional parts-alphas. All the other parts-alphas of the project do not disappear during this specific consideration of one alpha, they are modeled, remembered, and will definitely be revisited and checked for how well they fit into the overall project.