Alpha of the system ​

The concept of a system as an embodiment in the physical world is even more diverse: the states of system realization will be absolutely different for a nuclear power plant, a mobile application, a startup, a store delivery service, forest plantations, civil society. Here is an example of a very general list of states (defined by events reaching their milestones) for a "hardware" system in commissioned development, but it needs to be carefully adapted for each specific type of system. The embodiment of a "hardware" system (or its versions, or increments/features) can go through the following states:

• As raw material: materials for the realization of the system are available and allow creating parts of the system with the necessary characteristics; equipment for processing materials into parts is available; the production schedule and logistics of parts are coordinated; work on creating parts of the system is possible.
• As parts: parts of the system are created and/or purchased and tested; the schedule of integration/assembly/installation/construction from parts is coordinated; work on integration/assembly/installation/construction is possible.
• Demonstrable: the realization of the system can be tested in individual functions, and key characteristics can be measured; key characteristics can be demonstrated to external project roles; critical system interfaces have been demonstrated; the system is ready for verification; the necessary external project roles agree that the system needs to be verified.
• Ready: functionality is tested; defect levels for external project roles are acceptable; installation and other user and operator documentation is available; representatives/performers of external project roles are satisfied with the system; the composition of the delivered system is known; representatives/performers of external project roles are ready to operate the system; operational support is available.
• Operational: available to external project roles for operation/use in a working environment; there is at least one example of a working system; maintenance is at an agreed service level.
• Retired: The realization of the target system has been replaced or discontinued from use; the system is no longer supported; there are no "official" external project roles still using the system; no more improvements to the system will be made; all material components of the system are either reused or properly disposed of.

It is amazing that many people, when discussing system realization, never think about the physical reality, everything remains in the form of descriptions (a typical mistake: "the target system of our project is an analytical report," whereas a report is a description!). If your system realization is not in the material world, if you cannot specify the location of your system in space at certain times, then there is a high probability that your project is just a fantasy. And if you do make it, nothing in the physical world will change. So, don't do it, drop it, as nothing will change in the world! Make sure that in your project, the system realization is ultimately physical (maybe later in the complete life cycle than in the project life cycle you are performing, but you are making changes in the physical world, and everything else is just to support that change, not for its own sake).

When discussing the system realization alpha, pay attention to the creators in the chain: the descriptions of the system itself may be good, but you cannot make it: engineers have prepared descriptions without thinking about how the system will be manufactured, without considering how the system will appear in the physical world. And then it turns out that there are no machines for the "hardware," it's unclear how to teach for educational projects, there is no necessary computing power in computers for software engineering projects, and so on. If your focus is only on describing the system, remember that this description is only needed to the extent that the system will be realized in the physical world, taking its place in space-time. Track the system realization alpha throughout the project, from its very beginning, not just at the moment when it needs to start! And don't forget: the system realization is operational, everything is done for this state (not for the state at the completion of manufacturing or at the moment of sale. An airplane in operational condition flies, it is not "ready" or even "delivered to the airline"!).

The alpha of the system in the creation chain can be the project organization alpha, for brevity, we will call this organization a "team" (although it can be one person, a small team, "that can be fed with two large pizzas," a collective of several teams, a large enterprise, a cooperation of several enterprises). Here are the states/milestones by which you can track changes in the team alpha in the course of a system creation project (for a large team, it will inevitably need to be adapted, rewritten differently—remember that organizational changes in the course of continuous development have actually been omitted here, each of them requires creating a separate sub-alpha):

• Seeded: the mission/assignment/role of the team in the suprasystem of the team is defined; the limitations are known and explicit; mechanisms for team growth are in place; the composition of internal roles in the team is defined; the team's responsibilities are outlined in general; the level of commitments accepted by the team is clear; the required competencies are defined; the size of the team is defined; supervision rules are defined; the organizational type/form is chosen.
• Formed: a sufficient number of team members have been recruited; roles in the team are understood by its members; everyone understands how to work; team members get to know each other when meeting; team members understand individual responsibilities and how they relate to their competencies; team members accept the work results of each other and peers; external peers (organizations, teams, and individual people) are identified; communication mechanisms within the team are defined; each team member has committed to working as accepted in the team; technologies are deployed; resources for work are allocated, authorities are obtained.
• Collaborating: the team functions as a coherent organizational part; communication within the team is open and honest; the team is focused on achieving the team's mission/assignment; team members know each other and collaborate.
• Performing: the team continuously fulfills commitments; the team continually adapts to changing contexts; the team identifies and solves problems without external assistance; minimal rework of completed work; waste and reasons for waste are constantly eliminated.
• Adjourned: responsibilities have been fulfilled; team members are available for participation in other teams; the mission is completed.

When documenting the team description, a good idea is to use a table to describe roles from our course. Don't forget to check if team members (organizational units, role performers) have the skills in practices indicated in the "method" alpha. If a method requires programming in Julia, and in your team the master in operational management is assigned to perform this practice, saying, "OK, I will deal with it, I will learn to program in the process," then success in this project is not to be expected. Check where in your team description you can find answers to the questions needed to determine the state of the "team" alpha. For example, "open and honest communication within the team" — this cannot be inferred from a description given as a list of names, arranged by their positions, right? If openness and honesty in the team are not documented, they will remain invisible, and then no work planning will be done for certain leadership practices, and without leadership, the communication situation in the project will remain bad and tense. Not many people want to work in a bank with spiders, and it's unpleasant for few, which will reflect poorly on the project (in such situations, people are often "set up": they do things to make some project parts fail, and the blame is known. Do we need some project part to fail, even if the blame will be known?!). The "project organization" alpha will draw attention to this situation, prompting to plan work to solve this problem.

Methodology, system thinking, and other fundamental disciplines are about managing attention, about paying attention to the important. Alphas are the most important in the project that you must intensively change, and whose changes you must track and coordinate. They cannot be overlooked.

As an example of a sub-alpha for the "team" alpha, you can provide the "system creation and development method" alpha. This sub-alpha could have the following states (the focus here is not just on putting the method but on obtaining an organizational opportunity—certainty that people will actually engage in the method, not just work as it happens):

• Principles established: the team actively supports the discipline/theory/principles; external project roles agree with the principles; technologies/tools/equipment necessary for their support have been agreed upon; recommendations on the selected approach are available; the working context is understood; limitations of practices and the tools chosen within them are known.
• Foundation established: key practices of the method and their tools have been selected; practices necessary to start working are agreed upon; practices that will not be discussed and their technologies are identified; the gap between available and necessary organizational capabilities is defined; a way of working where all practices can be conveniently used is defined.
• In use: practices and their technologies/tools are used; the regular use of practices is checked; practices are adapted to the project circumstances; practices are supported by the team; mechanisms for feedback on practices work; practices are supported by team communication, the team collaborates in executing practices.
• In place: practices are used by the entire team; organizational capabilities are available to the entire team; they are checked and adapted by the entire team.
• Working well: project alphas progress predictably through the states; practices are applied naturally; technologies naturally support the established working discipline; continuous improvement is ongoing.
• Retired: the method and its practices are no longer used; lessons from using the method practices are published for use in future projects.