Descriptions and Documentation of Various Areas of Interest
At the end of the subsection “How to Think About Systems?”, we explored approaches to describing any system as a “black box” or a “transparent box.”[1] We covered this in previous sections. In this subsection, we will examine specific types of descriptions across different areas of interest in project activities.
The point is that in project activities (or within an enterprise), you are surrounded by a wide variety of documents describing many different systems[2]. At the same time, many projects are underway within an enterprise, and you may participate in several of them. In your daily work activities, you do not necessarily—or always—create descriptions of the system of interest. For example, you might be describing the client base, developing certain subsystems of the conveyor for producing the system of interest, or simply filling out financial templates.
Refer again to the 3x3 Table and pay attention to the list of work artifacts in each cell. Examine each cell and try to identify your own cell(s) and the work artifacts you work with and create.
For example, note that the system of interest as a “black box,” in terms of its role-based behavior (cell 1.2 of the 3x3 Table), is described as a “usage concept.” Although your particular enterprise may not use this exact term—“usage concept” might be called something else[3]. The exact name of the work artifact in each cell of the 3x3 Table also depends on the subject area and the chosen method of description. If you are developing a passenger vehicle, you will use one set of description methods for all cells; if you are developing an IT system, you will use another.
Systems thinking will help you communicate more effectively with specialists, but you also need to consciously[4] understand your subject area, including connecting to the physical world. In other words, you need to know from which cell of the 3x3 Table you are viewing other project roles[5] and which work artifacts you use to communicate with them.
If you do not know your subject area and cannot mentally connect to changes in the physical world (that is, to specific work artifacts), this is a direct path to failure. You will end up describing strange things, implementing random changes in the physical world, or not affecting the physical world at all with your ideas.
In our course, we simply draw attention to the fact that there are different areas of interest, and that in each of them, documentation is created using specific methods of description. Every enterprise has employees who specialize in certain subject areas and use methods of description to create this documentation.
For example, a marketer (in cell 1.1 of the 3x3 Table) creates a description of the target audience. And from our course, you already understand what this documentation is, what the role is, and for whom this work artifact is created. You should also already understand that the client base is a system in the real/physical world, and that a computer CRM system, in relation to this client base, is much like a photograph of a person is to the person themselves—a document with a description and convenient means of viewing the document.
However, you are unlikely to be able to create this “client base” system or even the documentation describing it unless you are a relevant specialist. The same applies to all other cells of the 3x3 Table. In our course, you have gained a high-level understanding of all areas of interest and studied a universal approach to modeling any system. But the actual modeling and creation of systems are carried out by applied specialists. The good news is that you now know how to interact with them. That is, you understand their subjects of interest, methods, work artifacts, and so on.
These approaches apply to the system of interest, the supersystem, our own system, or the creation system. ↩︎
At different system levels or stages in the creation chain. ↩︎
The documentation for the usage concept may be called different things at a given enterprise: standards documents, use cases, technical specifications, files with use case diagrams in various languages, or database fragments with the information model. ↩︎
Awareness arises when you focus your attention on your roles, best-in-class methods, subjects of interest and preferences, work artifacts, etc. ↩︎
All other team members or external project roles. ↩︎