February 18, 2015 at 15:55Is Great Unification Possible in Project Management Theory? Part 1
Today, the world of project management is divided into two camps: peaked and blunt . Of course, not everything is as bad here as the great Jonathan Swift. But still, before the start of any project, the problem always arises : how to break an egg from the sharp or blunt end of choosing a software: based on classical or modern flexible techniques. The choice is just that: either one or the other.
Illustration: Alamy / PHOTAS
Fig. 1. Project management meetingPointed and blunt We
use a comparative analysis of existing project management methodologies, as set out in the monographRobert 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. And it’s a pity, the book is wonderful, apparently not in vain on the American Amazon, it has the 4th rating among Adjayl literature.
Before we go any further, I would like to warn the reader that in this article and in the following only issues related exclusively 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. The following is a somewhat simplified, in comparison with that given in the book of Vysotsky, comparative scheme.
Fig. 2. Types of project life cycles and management methods
As can be seen from Figure 2, the five types of project life cycles shown on it differ from each other in the ability (or inability) to “roll back” at one point or another to one of the already completed stages of the project. Following Vysotsky, this property of the project management methodology will be called adaptability. Or, in other words, adaptability is the opportunity provided by the project planning and project management methodology to make changes to the composition and work plan of the project at various stages of its life cycle.
The higher the life cycle model is located on the diagram, the greater the adaptability of the management technique based on it. So, for example, the extreme management technique, possessing 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 project goal.
Once again, slightly changing Vysotsky’s classification, we combine the above types of life cycle into two groups, highlighted in Fig. 2 different colors:
- classic: that is, those in which the fully prepared hierarchical structure of the work (hereinafter referred to as the WBS) and the project plan do not change during the course of the work. A small amount of changes may be allowed, but, as Vysotsky wrote, more likely as an exception than usually
- Agile: flexible modern techniques that allow you to "roll back" arbitrarily back at any time. This can be done, including periodically, in accordance with pre-planned cycles. There is no need for a preliminary full assignment of JIS.
Let's now build aLiliput map of 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 blunt advocates of classical and agile methods.
First we decide what we mean by the complexity of the projects.
By complexity we mean not so much the total number of works, but rather the complexity of the structure of relations between works, combining individual works in the JIS and the project. Actually, the project is defined in this way: it is not only a totality of work, but also a unique structure of relations uniting individual works into a project.
Let us 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 from
Figure 3: “Level 0” - the project itself and “Level 1” - project components. If you need to use a hierarchical structure with a larger number of hierarchy levels to describe a project, the project is complex. The more work, relationships, and hierarchy levels, the higher the complexity of the project.
Now we can return to our map - it is shown in Fig. 4.
Fig. 4. Project management methodologies
In Figure 4, the world of project management methods is divided into three rectangles of various 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 simplest designs. I am sure that any project manager with practical experience will agree that there are projects so simple that the choice of methodology is not very important for managing them. Everything will work here, both classic and agile.
A yellow rectangle is a classic technique. Project management of rather high complexity is available to them. The scope of classical methods is limited from above to the limit level of adaptability, which was mentioned earlier with reference to Vysotsky: the JIS and the project plan must be prepared before work begins. This border is somewhat blurred. As noted earlier, changes to the WBS and plan are allowed, but only as an exception.
What is the reason for this restriction? It is simple: when creating or modifying the WBS and the project plan, the relationship between work must be set manually. Imagine periodically, after each scrum, you must manually redo the entire communications system. 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 job. And the source of human errors, the number of which increases nonlinearly with increasing complexity of the project. It should be noted that the need to establish relationships manually is not only a limitation on the flexibility of classical techniques, but also a serious drawback that complicates the management of complex projects even in such classic areas of their application as construction and industry.
A small historical remark. The graduate of the St. Petersburg Practical Technological Institute, mentioned in the previous paragraph, Karl Adametsky in 1896 reported at the meeting of the Imperial Russian Technical Society about his invention of a diagram, later named by 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. What about project management theory? We still do the main work in the old fashion, manually. The remarkable achievements in the UI and UX of fashion applications and services of recent years, with 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 relationships manually limits the scope of application of classical techniques from above, as shown in the figure.
The scope of flexible or agile techniques - the blue rectangle in Figure 4, is also limited, but on the right. Let's try to answer the question: “What is the definition of this restriction, and where does this border intersect the horizontal axis of our coordinate system?”
Joel Spolsky once gave a very suitable wording for our purpose in his blog: “... the connections are so obvious that it makes no sense to waste energy on their formal tracking” Generalizing a little, we can say that simple projects containing only simple communication systems and a minimum number of hierarchy levels are allowed to the left of this vertical line. But there are no restrictions on the level of adaptability. The low complexity of the projects, or, as noted above, the 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), according to the quantitative assessment of Robert Vysotsky, it worked.
Let's go back to our drawing, more precisely, to the mysterious white area in the upper right. Perhaps the most interesting thing is exactly there, inside the white rectangle? I am sure so. This is the place for complex projects, the management of which can not do without flexible techniques. Complex software development projects are here. Also located here is the innovative hi-tech with its exceptionally high measure of uncertainty. Naturally, projects for joint development of hardware and software will also be located here. And the further we move along the axis of complexity to the right, the more interesting, more innovative and more expensive projects we will meet there. I believe that significantly more funds are invested in these remaining 20% than in the 80% mentioned above. And this trend will be valid for more than one year.
So, in order to travel comfortably inside a white rectangle, you need to be able to not only take into account the internal structure of projects, but also learn how to easily modify it on the fly. This will allow you to manage complex projects with any degree of adaptability.
You can not determine the SRI of the project before starting work? Don’t be scared, draw the missing components as you go. Do you want to abandon parts of already planned or even completed components? It doesn’t matter, just exclude them from the ISR. Want to change the development sequence by changing the sequence of relationships between the components of the WBS? You are welcome. Do you want to abandon a preliminary estimate of time or labor? Not a problem.
And even more than that. And if you don’t want, or maybe you can’t limit yourself in advance to the framework of one specific management technique? 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 implementation of the project or, even worse, after its completion, to understand that the choice was wrong? And that the project itself could end in a completely different way?
If so, try to ask the question: is an analogue of the Great Unification Theory possible in project management? Is it possible to combine all five different types of project development shown in Figure 1 in a universal, single, as flexible framework as possible?
What should ensure full versatility or maximum flexibility of using a single framework? Let's try to use the automation of linking for this. Let's see if it is possible to transfer this work from a person to a computer and whether we will achieve our goal this way.
As the reader can easily assume, the author has a suggestion on how to do this. But more on that in the next article.
Illustration: Alamy / PHOTAS
Fig. 1. Project management meeting
use a comparative analysis of existing project management methodologies, as set out in the monographRobert 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. And it’s a pity, the book is wonderful, apparently not in vain on the American Amazon, it has the 4th rating among Adjayl literature.
Before we go any further, I would like to warn the reader that in this article and in the following only issues related exclusively 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. The following is a somewhat simplified, in comparison with that given in the book of Vysotsky, comparative scheme.
Fig. 2. Types of project life cycles and management methods
As can be seen from Figure 2, the five types of project life cycles shown on it differ from each other in the ability (or inability) to “roll back” at one point or another to one of the already completed stages of the project. Following Vysotsky, this property of the project management methodology will be called adaptability. Or, in other words, adaptability is the opportunity provided by the project planning and project management methodology to make changes to the composition and work plan of the project at various stages of its life cycle.
The higher the life cycle model is located on the diagram, the greater the adaptability of the management technique based on it. So, for example, the extreme management technique, possessing 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 project goal.
Once again, slightly changing Vysotsky’s classification, we combine the above types of life cycle into two groups, highlighted in Fig. 2 different colors:
- classic: that is, those in which the fully prepared hierarchical structure of the work (hereinafter referred to as the WBS) and the project plan do not change during the course of the work. A small amount of changes may be allowed, but, as Vysotsky wrote, more likely as an exception than usually
- Agile: flexible modern techniques that allow you to "roll back" arbitrarily back at any time. This can be done, including periodically, in accordance with pre-planned cycles. There is no need for a preliminary full assignment of JIS.
Let's now build a
First we decide what we mean by the complexity of the projects.
By complexity we mean not so much the total number of works, but rather the complexity of the structure of relations between works, combining individual works in the JIS and the project. Actually, the project is defined in this way: it is not only a totality of work, but also a unique structure of relations uniting individual works into a project.
Let us 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 from
Figure 3: “Level 0” - the project itself and “Level 1” - project components. If you need to use a hierarchical structure with a larger number of hierarchy levels to describe a project, the project is complex. The more work, relationships, and hierarchy levels, the higher the complexity of the project.
Now we can return to our map - it is shown in Fig. 4.
Fig. 4. Project management methodologies
In Figure 4, the world of project management methods is divided into three rectangles of various 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 simplest designs. I am sure that any project manager with practical experience will agree that there are projects so simple that the choice of methodology is not very important for managing them. Everything will work here, both classic and agile.
A yellow rectangle is a classic technique. Project management of rather high complexity is available to them. The scope of classical methods is limited from above to the limit level of adaptability, which was mentioned earlier with reference to Vysotsky: the JIS and the project plan must be prepared before work begins. This border is somewhat blurred. As noted earlier, changes to the WBS and plan are allowed, but only as an exception.
What is the reason for this restriction? It is simple: when creating or modifying the WBS and the project plan, the relationship between work must be set manually. Imagine periodically, after each scrum, you must manually redo the entire communications system. 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 job. And the source of human errors, the number of which increases nonlinearly with increasing complexity of the project. It should be noted that the need to establish relationships manually is not only a limitation on the flexibility of classical techniques, but also a serious drawback that complicates the management of complex projects even in such classic areas of their application as construction and industry.
A small historical remark. The graduate of the St. Petersburg Practical Technological Institute, mentioned in the previous paragraph, Karl Adametsky in 1896 reported at the meeting of the Imperial Russian Technical Society about his invention of a diagram, later named by 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. What about project management theory? We still do the main work in the old fashion, manually. The remarkable achievements in the UI and UX of fashion applications and services of recent years, with 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 relationships manually limits the scope of application of classical techniques from above, as shown in the figure.
The scope of flexible or agile techniques - the blue rectangle in Figure 4, is also limited, but on the right. Let's try to answer the question: “What is the definition of this restriction, and where does this border intersect the horizontal axis of our coordinate system?”
Joel Spolsky once gave a very suitable wording for our purpose in his blog: “... the connections are so obvious that it makes no sense to waste energy on their formal tracking” Generalizing a little, we can say that simple projects containing only simple communication systems and a minimum number of hierarchy levels are allowed to the left of this vertical line. But there are no restrictions on the level of adaptability. The low complexity of the projects, or, as noted above, the 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), according to the quantitative assessment of Robert Vysotsky, it worked.
Let's go back to our drawing, more precisely, to the mysterious white area in the upper right. Perhaps the most interesting thing is exactly there, inside the white rectangle? I am sure so. This is the place for complex projects, the management of which can not do without flexible techniques. Complex software development projects are here. Also located here is the innovative hi-tech with its exceptionally high measure of uncertainty. Naturally, projects for joint development of hardware and software will also be located here. And the further we move along the axis of complexity to the right, the more interesting, more innovative and more expensive projects we will meet there. I believe that significantly more funds are invested in these remaining 20% than in the 80% mentioned above. And this trend will be valid for more than one year.
So, in order to travel comfortably inside a white rectangle, you need to be able to not only take into account the internal structure of projects, but also learn how to easily modify it on the fly. This will allow you to manage complex projects with any degree of adaptability.
You can not determine the SRI of the project before starting work? Don’t be scared, draw the missing components as you go. Do you want to abandon parts of already planned or even completed components? It doesn’t matter, just exclude them from the ISR. Want to change the development sequence by changing the sequence of relationships between the components of the WBS? You are welcome. Do you want to abandon a preliminary estimate of time or labor? Not a problem.
And even more than that. And if you don’t want, or maybe you can’t limit yourself in advance to the framework of one specific management technique? You do not want to choose in advance
If so, try to ask the question: is an analogue of the Great Unification Theory possible in project management? Is it possible to combine all five different types of project development shown in Figure 1 in a universal, single, as flexible framework as possible?
What should ensure full versatility or maximum flexibility of using a single framework? Let's try to use the automation of linking for this. Let's see if it is possible to transfer this work from a person to a computer and whether we will achieve our goal this way.
As the reader can easily assume, the author has a suggestion on how to do this. But more on that in the next article.