Is Grand Unification possible in project management theory? Part 1
Today, the world of project management is divided into two camps: the little ones and the blunt-ends . Of course, not everything is as neglected as that of the great Jonathan Swift. But nevertheless, before the start of work, the management of any project always faces a problem : how to break an egg, from the sharp or blunt end of the choice of software: based on classical or modern flexible methods. The choice is exactly this: either one or the other.
Illustration: Alamy / PHOTAS
Fig. 1. The meeting of the project management ofpoint and blunt ends
We will use a comparative analysis of existing methods of project management set forth in the monograph by Robert Vysotsky “Adaptive Project Management: Traditional, Flexible and Extreme Techniques”. The seventh edition of this book has recently become available to an English-speaking audience. As far as I know, it has not yet been translated into Russian. A pity, the book is wonderful, apparently not for nothing on the American Amazon she has the 4th rating among the literature on Ajail.
Before we go any further, I would like to warn the reader that in this article and in the subsequent ones only issues related to the framework, the theoretical foundations of project management techniques, will be considered. No other topics, including those related to the practical application of these techniques, will be considered.
')
Let's start by classifying the different types of project life cycles. Below is a somewhat simplified, compared with the comparative scheme given in the book of Vysotsky.
Fig. 2. Types of project life cycles and management methods
As can be seen from Figure 2, the five types of project life cycle shown on it differ from each other in the possibility (or impossibility) at one time or another to “roll back” to one of the already completed stages of the project. Following the Vysotsky, we will call this property of the project management methodology adaptability. Or, in other words, adaptability is an opportunity provided by the methodology of project planning and management to make changes in the composition and plan of work on a project at different stages of its life cycle.
The higher the life cycle model is located on the diagram, the more adaptive is the management method based on it. So, for example, the method of extreme control, which possesses maximum adaptability according to Vysotsky, allows you to “roll back” to the very beginning of the project life cycle and change a lot, right up to the very purpose of the project.
Once again, slightly changing the classification of Vysotsky, we combine the above types of life cycle into two groups, highlighted in Fig. 2 different colors:
- classical: that is, those in which the previously fully prepared hierarchical structure of work (hereinafter - the SRI) and the project plan do not change during the course of the work. A small amount of change may be allowed, but, as Vysotsky wrote, rather as an exception than, as a rule,
- agyle: flexible modern techniques that allow you to “roll back” arbitrarily back almost at any time. This can be done, inter alia, periodically, in accordance with pre-planned cycles. There is no need for a preliminary complete assignment of the IMR
Let's now build a map ofLiliput in the two-dimensional world of management techniques with coordinates: adaptability and complexity of projects. On this map we will place both camps of pointed and stupid proponents of classical and agile methods.
First, we define what we mean by the complexity of projects.
By complexity we mean not so much the total number of works, but the complexity of the structure of links between the works, which unites individual works in the SRI and the project. Actually, this is the way the project is defined: it is not only a set of works, but also a unique structure of relations, uniting individual works into a project.
We explain the concept of project complexity in the diagram shown in Figure 3 below.
Fig. 3. The hierarchical system of the project
The simplest project can be adequately described using only two levels of
Figure 3: "Level 0" - the project itself and "Level 1" - the project components. If for the description of the project it is necessary to use a hierarchical structure that has a greater number of hierarchy levels - the project is complex. The more jobs, links and levels of hierarchy - the higher the complexity of the project.
Now we can return to our map - it is shown in Fig. four.
Fig. 4. Project Management Techniques
In Figure 4, the world of project management techniques is divided into three rectangles of different colors: green, yellow, and blue, as well as a white area in the upper right.
Inside the green rectangle, which is the intersection of the yellow and blue rectangles, are the most simple designs. I am sure that any project manager with practical experience will agree that there are projects that are so simple that the choice of methodology is not important for managing them. Everything will work here, both classic and agyle.
Yellow rectangle - classic methods. They are available to manage projects of rather high complexity. The scope of application of classical methods is limited from above by the limit level of adaptability, which was mentioned earlier with reference to Vysotsky: the SRI and the project plan should be prepared before the start of work. This border is somewhat blurred. As noted earlier, changes to the SRI and plan are allowed, but only as an exception.
What is the reason for this restriction? It is simple: when creating or modifying the SRI and the project plan, the link between the works must be set manually. Imagine, periodically, after each scrum, you need to manually redo the entire system of relations. For almost 120 years after Karl Adametsky, nothing has changed. Only instead of a pencil a person needs to work with a computer mouse and keyboard. Frankly, this is a boring and painstaking work. And the source of human error, the number of which non-linearly increases with the increasing complexity of the project. It should be noted that the need to establish connections manually is not only a limitation on the flexibility of classical methods, but also a serious drawback, which significantly complicates the management of complex projects even in such classical areas of their application as construction and industry.
A small historical note. Carl Adametsky, a graduate of the St. Petersburg Practical Technological Institute, mentioned in the previous paragraph, in 1896, reported at a meeting of the Imperial Russian Technical Society about his invention of the diagram, later named after Henry Gantt. And in the same year, Henri Becquerel discovered the phenomenon of radioactivity. Over the past century, nuclear physics and industry have advanced quite far forward. And the theory of project management? We are still doing the main work in the old manner, by hand. Remarkable achievements in the UI and UX of fashionable applications and services of recent years, having hundreds of thousands of active users around the world, can only embellish this sad reality, but they cannot completely hide it.
So, we will assume that it is this factor: the need to establish links manually limits the scope of classical techniques from above, as shown in the figure.
The scope of flexible or agile methods - the blue rectangle in Figure 4 is also limited, but to the right. Let's try to answer the question: “What determines this restriction, and where does this boundary intersect the horizontal axis of our coordinate system?”
Joel Spolsky in his time gave a very suitable formulation for our goal in his blog : “... the connections are so obvious that it makes no sense to spend forces on their formal tracking.” Generally speaking, to the left of this vertical line, simple projects containing only uncomplicated communication systems and the minimum number of hierarchy levels. But there are no restrictions on the level of adaptability. The low complexity of projects or, as noted above, a complete or almost complete lack of connections is the price paid for ensuring high adaptability. And for 80% of the total number of projects (including software development), if you believe the quantitative assessment of Robert Vysotsky, it worked.
Let's return to our drawing, more precisely, to the mysterious white area on the right above. Maybe the most interesting is exactly there, inside the white rectangle? I'm sure so. This is a place for complex projects, the management of which can not do without flexible methods. Projects for the development of complex software systems are here. Also here is an innovative hi-tech with its exceptionally high measure of uncertainty. Naturally, projects of joint development of hardware and software will be located here. And the further we move along the complexity axis to the right, the more interesting, more innovative and more expensive projects we will meet there. I suppose that substantially more funds are invested in these remaining 20% ​​than in the above-mentioned 80%. And this trend will continue for more than one year.
So, in order to comfortably travel yourself inside a white rectangle, you need to be able not only to take into account the internal structure of projects, but also to learn how to modify it easily, on the fly. This will allow you to manage complex projects with any degree of adaptability.
You can not prior to the start of work to determine the project IMR? Do not worry, finish drawing the missing components in the course of execution. Do you want to abandon part of already planned or even completed components? It does not matter, just exclude them from the IMR. Want to change the development sequence by changing the sequence of links between the components of the SRI? You are welcome. Do you want to abandon the preliminary estimate of time or labor? No problem.
And even more. And if you do not want or, maybe, cannot preliminarily limit yourself to the framework of one particular management method? You do not want to choose in advancefrom which end to break an egg only one of the five frameworks shown in Figure 1? You do not want to spend money and time on the purchase of software, its implementation and training of employees, so that later, during the execution of the project or, even worse, after its completion, you understand that the choice was wrong? And that the project itself could end very differently?
If so, let us try to ask the question: is it possible to have an analogue of the Theory of the Great Unification in project management? Is it possible to combine all five different types of development projects shown in Figure 1 in a universal, unified, maximally flexible framework?
What should be ensured full versatility or maximum flexibility in the use of a single framework? Let's try for this use the automation of the installation of links. Let's see if it is possible to transfer this work from a person to a computer and whether we will achieve our goal by this way.
As the reader can easily assume, the author has a suggestion on how to do this. But more about that in the next article.
Illustration: Alamy / PHOTAS
Fig. 1. The meeting of the project management of
We will use a comparative analysis of existing methods of project management set forth in the monograph by Robert Vysotsky “Adaptive Project Management: Traditional, Flexible and Extreme Techniques”. The seventh edition of this book has recently become available to an English-speaking audience. As far as I know, it has not yet been translated into Russian. A pity, the book is wonderful, apparently not for nothing on the American Amazon she has the 4th rating among the literature on Ajail.
Before we go any further, I would like to warn the reader that in this article and in the subsequent ones only issues related to the framework, the theoretical foundations of project management techniques, will be considered. No other topics, including those related to the practical application of these techniques, will be considered.
')
Let's start by classifying the different types of project life cycles. Below is a somewhat simplified, compared with the comparative scheme given in the book of Vysotsky.
Fig. 2. Types of project life cycles and management methods
As can be seen from Figure 2, the five types of project life cycle shown on it differ from each other in the possibility (or impossibility) at one time or another to “roll back” to one of the already completed stages of the project. Following the Vysotsky, we will call this property of the project management methodology adaptability. Or, in other words, adaptability is an opportunity provided by the methodology of project planning and management to make changes in the composition and plan of work on a project at different stages of its life cycle.
The higher the life cycle model is located on the diagram, the more adaptive is the management method based on it. So, for example, the method of extreme control, which possesses maximum adaptability according to Vysotsky, allows you to “roll back” to the very beginning of the project life cycle and change a lot, right up to the very purpose of the project.
Once again, slightly changing the classification of Vysotsky, we combine the above types of life cycle into two groups, highlighted in Fig. 2 different colors:
- classical: that is, those in which the previously fully prepared hierarchical structure of work (hereinafter - the SRI) and the project plan do not change during the course of the work. A small amount of change may be allowed, but, as Vysotsky wrote, rather as an exception than, as a rule,
- agyle: flexible modern techniques that allow you to “roll back” arbitrarily back almost at any time. This can be done, inter alia, periodically, in accordance with pre-planned cycles. There is no need for a preliminary complete assignment of the IMR
Let's now build a map of
First, we define what we mean by the complexity of projects.
By complexity we mean not so much the total number of works, but the complexity of the structure of links between the works, which unites individual works in the SRI and the project. Actually, this is the way the project is defined: it is not only a set of works, but also a unique structure of relations, uniting individual works into a project.
We explain the concept of project complexity in the diagram shown in Figure 3 below.
Fig. 3. The hierarchical system of the project
The simplest project can be adequately described using only two levels of
Figure 3: "Level 0" - the project itself and "Level 1" - the project components. If for the description of the project it is necessary to use a hierarchical structure that has a greater number of hierarchy levels - the project is complex. The more jobs, links and levels of hierarchy - the higher the complexity of the project.
Now we can return to our map - it is shown in Fig. four.
Fig. 4. Project Management Techniques
In Figure 4, the world of project management techniques is divided into three rectangles of different colors: green, yellow, and blue, as well as a white area in the upper right.
Inside the green rectangle, which is the intersection of the yellow and blue rectangles, are the most simple designs. I am sure that any project manager with practical experience will agree that there are projects that are so simple that the choice of methodology is not important for managing them. Everything will work here, both classic and agyle.
Yellow rectangle - classic methods. They are available to manage projects of rather high complexity. The scope of application of classical methods is limited from above by the limit level of adaptability, which was mentioned earlier with reference to Vysotsky: the SRI and the project plan should be prepared before the start of work. This border is somewhat blurred. As noted earlier, changes to the SRI and plan are allowed, but only as an exception.
What is the reason for this restriction? It is simple: when creating or modifying the SRI and the project plan, the link between the works must be set manually. Imagine, periodically, after each scrum, you need to manually redo the entire system of relations. For almost 120 years after Karl Adametsky, nothing has changed. Only instead of a pencil a person needs to work with a computer mouse and keyboard. Frankly, this is a boring and painstaking work. And the source of human error, the number of which non-linearly increases with the increasing complexity of the project. It should be noted that the need to establish connections manually is not only a limitation on the flexibility of classical methods, but also a serious drawback, which significantly complicates the management of complex projects even in such classical areas of their application as construction and industry.
A small historical note. Carl Adametsky, a graduate of the St. Petersburg Practical Technological Institute, mentioned in the previous paragraph, in 1896, reported at a meeting of the Imperial Russian Technical Society about his invention of the diagram, later named after Henry Gantt. And in the same year, Henri Becquerel discovered the phenomenon of radioactivity. Over the past century, nuclear physics and industry have advanced quite far forward. And the theory of project management? We are still doing the main work in the old manner, by hand. Remarkable achievements in the UI and UX of fashionable applications and services of recent years, having hundreds of thousands of active users around the world, can only embellish this sad reality, but they cannot completely hide it.
So, we will assume that it is this factor: the need to establish links manually limits the scope of classical techniques from above, as shown in the figure.
The scope of flexible or agile methods - the blue rectangle in Figure 4 is also limited, but to the right. Let's try to answer the question: “What determines this restriction, and where does this boundary intersect the horizontal axis of our coordinate system?”
Joel Spolsky in his time gave a very suitable formulation for our goal in his blog : “... the connections are so obvious that it makes no sense to spend forces on their formal tracking.” Generally speaking, to the left of this vertical line, simple projects containing only uncomplicated communication systems and the minimum number of hierarchy levels. But there are no restrictions on the level of adaptability. The low complexity of projects or, as noted above, a complete or almost complete lack of connections is the price paid for ensuring high adaptability. And for 80% of the total number of projects (including software development), if you believe the quantitative assessment of Robert Vysotsky, it worked.
Let's return to our drawing, more precisely, to the mysterious white area on the right above. Maybe the most interesting is exactly there, inside the white rectangle? I'm sure so. This is a place for complex projects, the management of which can not do without flexible methods. Projects for the development of complex software systems are here. Also here is an innovative hi-tech with its exceptionally high measure of uncertainty. Naturally, projects of joint development of hardware and software will be located here. And the further we move along the complexity axis to the right, the more interesting, more innovative and more expensive projects we will meet there. I suppose that substantially more funds are invested in these remaining 20% ​​than in the above-mentioned 80%. And this trend will continue for more than one year.
So, in order to comfortably travel yourself inside a white rectangle, you need to be able not only to take into account the internal structure of projects, but also to learn how to modify it easily, on the fly. This will allow you to manage complex projects with any degree of adaptability.
You can not prior to the start of work to determine the project IMR? Do not worry, finish drawing the missing components in the course of execution. Do you want to abandon part of already planned or even completed components? It does not matter, just exclude them from the IMR. Want to change the development sequence by changing the sequence of links between the components of the SRI? You are welcome. Do you want to abandon the preliminary estimate of time or labor? No problem.
And even more. And if you do not want or, maybe, cannot preliminarily limit yourself to the framework of one particular management method? You do not want to choose in advance
If so, let us try to ask the question: is it possible to have an analogue of the Theory of the Great Unification in project management? Is it possible to combine all five different types of development projects shown in Figure 1 in a universal, unified, maximally flexible framework?
What should be ensured full versatility or maximum flexibility in the use of a single framework? Let's try for this use the automation of the installation of links. Let's see if it is possible to transfer this work from a person to a computer and whether we will achieve our goal by this way.
As the reader can easily assume, the author has a suggestion on how to do this. But more about that in the next article.
Source: https://habr.com/ru/post/286014/
All Articles