What to keep an eye on in the project ​

The main use of alphas (the approximate relationships of which are shown in the project system scheme or even an enterprise) is as a checklist, prompting to think about what you might forget to think about.

When airplanes became too large for one person to control, they often exploded on takeoff due to simple mistakes: forgetting to release the manual brake, forgetting to check all the numerous engines before takeoff. The introduction of a checklist helped: the checklist made people think and check what everyone knows needs to be done in a calm environment, but in the hectic takeoff, they sometimes really forget to do it, leading to fatal unpleasantness^[1].

The project system scheme is exactly such a checklist: at the top level, these are alphas that need to be kept in mind throughout the project. If team members did not think about the state of some alpha, there are significant risks that something may go wrong there simply because attention was lacking. The process of creating a system is usually no less complex and troublesome than a plane takeoff, so the absence of the most obvious and simple tasks can be expected - for example, in the project rush, forgetting to establish communication with the performers of external project roles and simply fantasizing instead of clarifying the situation regarding the needs and supra system, or forgetting to conduct tests within engineering justifications, or forgetting to consider certain architectural solutions. Collective coherence in the project must be somehow organized:

• Important objects of attention that change during the project are alphas. We understand what work products implement alphas and do not forget to track them.
• "Don't forget" is achieved through the use of computer memory and the habit of regularly reviewing the contents of this memory.
• The key is not the state of the alpha itself, but whether you thought about its state (because if you did, there is a chance to correct something, and if you didn't think - "everything that can go wrong will definitely go wrong").

Milestones for achieving the states of each alpha in the state change graph are formulated as checklist questions, the positive answer to which indicates the achievement of this milestone. For example, in the "work" alpha of the organization's project interests area, the state "initiated" has the first sub-item "required work results are clear". You can consider reaching the state "initiated" by a certain date as a milestone and all the sub-items there as control questions for achieving this state, or you can also consider these criteria as milestones that can be achieved at different times for each. It's your choice what granularity of modeling you choose. Modeling alphas and their states, control points for achieving these states are flexible and not rigidly predetermined.

At the same time, the result will not clarify itself: to meet the milestones, you need to activate some practice (or quite a few practices performed by various roles), in order to achieve the state defined by it - by the set date, earlier or later. A view on milestones inevitably generates a discussion of methods to achieve alpha states and then a discussion of resources to perform these works based on the emerging discussed practices. The thought process should go like this (we will give a simple example, but this is a general reasoning, while other similar sequences are omitted for simplicity):

• Silence in the meeting room::alpha
• External noise is eliminated::state of the "silence in the meeting room" alpha
• External noise is eliminated by the start of the meeting (expected at 4 pm):: milestone (derived from the state of the alpha and the expected time of achievement)
• The door is closed:: control question about the state of no noise in the room alpha.
• The windows are closed:: control question about the state of no noise in the room alpha
• The door is closed by the start of the meeting (expected at 4 pm):: milestone (derived from the control question to check the state of the door and the specified time of achievement)
• The windows are closed by the start of the meeting (expected at 4 pm):: milestone (derived from the control question to check the state of the windows and the specified time of achievement)
• Participants' mobile phones set to "silent mode"::question about the state of the alpha.
• "Door closing":: work performed by the "secretary of the meeting"::organizational unit (options: "participant closest to the door during the meeting"::organizational unit, installation of a door closer and further "automatic door closing" operation performed by the door closer::equipment, but requires additional work to install the door closer)
• Closing the door is added to the issue tracker and assigned to the meeting's secretary (and further progress in this work is checked "as usual" - this work won't get lost, it is also recorded).

The trouble is that all these numerous actions/works to achieve the necessary states, continuously sliding towards the previous states of "unpreparedness" (life changes, and you need to constantly develop the system), accumulate a lot. This is one of the reasons why applied engineers do not like issue trackers like Trello, and also dislike all kinds of "sticky notes Kanban boards". "Managers," on the other hand, adore them: "everything is visual", each task looks like a "work card", and the progress of the project is nicely displayed as "progress of the cards". But the manager believes that the control of 200-300 works is too much, and even in a small team development, in a few months, 2-3 thousand issues can easily accumulate, which need to be tracked. Programmers and engineers cope with this, but managers get lost. How to solve this problem? It is important to understand who these "managers" are in their roles and why they need to know all the works. Modern issue trackers usually allow you to create a hierarchy of issues, and show only high-level cases to operational managers, there are not many of them. Most issue trackers allow you to display them nicely as cards on the screen. This is similar to the first automobiles - they were made in the form of carriages and even called "self-moving carriages".

In our example, it is also necessary to note that alphas are subjects of cases. The slice into cases and sub-cases significantly depends on how you view the world. For example, "quiet room" versus "silence in the meeting room", the state "internal and external noises are absent", alternative solutions for silence by changing the task setting (moving the meeting from a physical room to online, muting all microphones, except the speaker's microphone, or even using a chat instead of holding a meeting - and then there are no noise problems, etc.). The world can be divided in various ways, and working with these parts afterwards can be done in very different ways, and some of these work methods may imply another world, which we can also somehow obtain - also through works on some practices, but these will be other works on other practices. Working with alphas and cases and thinking about them the same way does not close the huge complexity and variety of the world. Thinking the same way about very different things saves some time. But creativity doesn't go anywhere!

All these dates in the milestones are just expectations, but it is very useful to assess the time of achieving these states, and if time estimation is difficult - break the system further into such versions or increments, or highlight such features so that the time to pass these checkpoints can be estimated. It is clear that the passage of states of higher-level alphas is poorly predictable over time, but it is easier with sub-alphas. Therefore, divide alphas into sub-alphas.

The graph of passing alpha states is by no means a linear sequence of these states. The examples given in the previous sections show the simplest cases of sequences of states, but in general, the state graph has loops and branches. Moreover, the alpha or sub-alpha (sub-alpha is also an alpha!) may refer to only one version or increment of the system, to one feature, but there may also be alphas that gradually change their state as various versions of the system are released (for example, achieving a desired architectural characteristic may be achieved during the release of five versions of the system - and the state of the architecture alpha should be tracked consistently for different versions of the system, and the state of a feature - like during a single pass of the V-diagram, but not in a "waterfall" way, but only for this small feature, because for a large feature, it may also require many attempts for implementation).

There are also common cases where one alpha will be a sub-alpha of several other alphas, the alphas themselves represent a graph, not a tree. And the relationship there, remember, is not "part-whole," but "a sub-alpha is something that, when moving through its states, somehow moves its higher alpha."

Here is another example: a milestone for the organization/team/collective/enterprise alpha - "collaborates" is formulated as a checklist item, which is also read as a checklist: "the team works as a single cohesive organizational unit; communication in the team is open and honest; the team is focused on achieving the mission/task of the team; team members know each other and collaborate.". This is a checklist within a checklist, and four levels can be easily accumulated:

1. Area of interest of the system creator of the target (there are also areas of interest description alphas, team work alphas, and there may be others)

1.1. Alpha team (there are also alphas describing the team, the team's work, and others)

1.1.3. The state of the alpha "Collaborates" (this is the third state in the series "planned, formed, collaborates, produces, disbanded", hence 1.1.3)

1.1.3.2. Control question about "open and honest communication in the team" state (it's the second in the list).

Achieving this milestone 1.1.3 requires leadership practice. Achieving this state from control question 1.1.3.2. requires thinking of ways to achieve open and honest communication - and this leads to thinking about a certain leadership sub-practice, you will have to choose a specific way to achieve this state through some work on some practice (preferably from the textbook rather than made up by yourself). You need to think like this: "what leadership discipline from which textbook will we apply to achieve this milestone"? "What tools from which supplier will we apply to support leadership?", because in the 21st century, even leadership is supported instrumentally!

Then you will need to perform works (understand who and when will perform these works according to the chosen leadership practice - plan the works, then allocate time and other resources, and do these works - work execution) for the selected leadership practice. And so with each checkpoint, for each question on the checklist.

Of course, there are numerous of these questions! Follow the following rules:

• Remember it should be that way. Human activity is complex. Just need to think about each task individually, not everything at once. You can't think about everything at once. But there can indeed be a lot of questions, even in small projects.
• Write down, especially the most important (the principle of the checklist: don't write down all the small details and nuances from textbooks that are known, but write down the most important things that need to be checked - because without it the project will fail). Do not forget to check what is written, return to it again and again. Don't trust your brain (although specialists can remember all those nuances from textbooks of various practices, there is no need to write them down - but what requires some collective action or can significantly impact success, then it must be written down. Remember the booklet "The Checklist Manifesto" by Atul Gavande).
• There are quite a few people in the team, they all have their versions of checklists - it is not necessary for one person to develop these checklists and work with them. No, a large number of these questions are shared among people. However, the written checklists (most often in issue trackers or even in universal modelers, which are then linked to issue trackers for managing the resulting works) are fairly easy to discuss when distributing project works between its performers. Therefore, don't forget to write down practices, roles, and the performers of these roles.

If the team does not discuss achieving all these checkpoints and does not perform works to achieve them, the project may have significant (including fatal for the project) issues due to inadequacy, "just forgot to think, and therefore forgot to do."

The formulations of checkpoints in the standard OMG Essence (and, accordingly, in our course) are intentionally "fuzzy", undefined, and blurry. The authors of the standard say that this "fuzziness" encourages the team to discuss these checkpoints to adapt the formulations to the individual specifics of the project, and obtain an explicit agreement from the team that all team members equally understand these checkpoints.

To account for project circumstances, adaptation/change of all examples provided in our course is necessary: areas of project interests, the number and names of alphas, the number and names of states, formulations of control questions on achievement of individual states. Adaptation should be done to consider the meta-models of project subject domains: "how in the textbook" and "how in the enterprise," and do not use direct formulations from our course!

The texts from the course only provide types of meta-meta-model, they serve as tools to focus the team's attention on objects in their subject area! The team must agree on what to keep an eye on in the project, who in the project takes responsibility for advancing the states of which alpha - and have clear formulations for this. These alphas (and their sub-alphas) then become objects of cases, and the course on systems management explains how to build various models of organizational units (project or enterprise work team) in universal modelers like coda.io or notion.so based on them.

Essential alphas in the chains of creation as objects of attention in the project will not be sufficient, the resolution is too low, you need to see more details in the project. Therefore, increase the resolution of your attention: focus not only on alphas but also on sub-alphas. The team takes these sub-alphas from disciplines/theories/principles of accepted practices, and again makes them objects of cases::works: if there is an object of attention that has some states, then there should be practices/methods that move this object of attention from state to state, and to make this actually happen, some works need to be done according to these practices.

For example, in the project management practice of the critical chain method, an alpha "project buffer" is introduced and then its state is tracked - first, this project buffer is created, then gradually used up during the project. The alpha "project buffer" may be a sub-alpha of "project organization work." The answer to the question "in what state is the project work?" could include a separate description of the state of the "project buffer." This is precisely why it is convenient to define a sub-alpha not through a part-whole relationship; ontologically, the "project buffer" is certainly not a part of the work (ontologically, the project buffer is a description of the work, although it can also be interpreted that this is a "potential work"). Anyway, it's hard to imagine the "buffer" as being a true part of the "work." However, as a sub-alpha - yes, this is convenient.

When talking about alphas, it is not necessary to pronounce the word "alpha" every time. Just as people don't say "airplane system," "kettle system," not adding the word "system." When they want to emphasize considering it as a system. Likewise, in a project, people don't say "work alpha" and "team alpha," they say "work" and "team" (the word "alpha is added only when they want to emphasize working with the alpha as a type, a role object). But your machine of types should work in your head all the time: You should keep track of mentions of alphas and sub-alphas!

We propose using the practice of adapting the project system scheme: consider that all these are projects for changing the world (engineering projects), think about all these projects in an engineering way (the same types of meta-meta-model as in our course for the engineering area of interest), but use terminology acceptable for the target subject domains in naming numerous sub-alphas (meta-model types). The general recipe: think the same way (mark the types of meta-meta-models involved in projects of various types, find the objects missed in thinking and action of the object types - but speak without pronouncing the terms of meta-meta-model). However, in communication with employees, do not use terms of meta-meta-model, use object types of meta-model. If in your head "target system" is an alpha you are tracking, do not say the words "alpha" or "target system," but say the system type taken in the subject area: airplane, skill, a gaming session. But realize this consciously: if you said "airplane," you should understand that this is a target system, which goes through various states in the project, but the main one is during use, when the airplane is flying. It is not necessary for employees to know how you think, but they must know the results of your thinking. Speak the results in the language of the meta-model, without uttering the words of the meta-meta-model. Of course, if the employees have passed our courses, the conversation with them will go much faster and easier (thinking in terms of meta-meta-models is more universal and compact), but if they have not passed our courses, the conversation using terms of the meta-meta-models will go much slower, they will not understand you and find you strange. Smart, not strange, they will consider you for expressing the results of your thinking in the language of the meta-model, i.e., in the language accepted in your project's subject areas or even in your company's language (meta-world model). Keep the types of this model in your head and speak in this "bird's language" only to employees who already understand this meta-meta-model language well. Remember about metanoia: what seemed natural to you, when you were learning it, and you even had difficulties in learning. Other people are just the same.

There are numerous subject areas for engineering, and the language of the conversation about each of them will be different. Applied engineers of the target system will be absolutely different, for example, in bioengineering, there may not be "developer" and "architect."

Management is more or less the same, with the difference in the terminology of one or another management school. Although the types of objects from our management course are known to many employees, be attentive: they can define these types very differently than you do based on the materials of our courses. "Operations management" is about the same in engineering, medicine, trade, education. But your employees may not even know that they are working with case management, although they spend half a day with an issue tracker. Therefore, clarify the language you are using in the conversation with employees: it is correct to speak the meta-model language, and if you want to change this model - discuss it in the language of the subject area model, meta-U model from the modeling course content, keep the