Criticism of modern project management systems
When I wrote an article on project management using MS Project , I had a steady feeling that I was writing something wrong. “Well, this can not be,” I thought, “so that such simple things are so difficult to be done in the program, which is one of the most common tools for project management.” I checked myself, repeatedly evaluated the relevance of my needs, studied other software solutions . And still I came to a disappointing conclusion: * I, as a project manager, have needs that are either forgotten or consciously ignored by the developers *. Despite the impressive list of capabilities of modern project management systems, there are tasks that I simply cannot solve without the help of aids due to the natural limitations of human thinking .
In this article I want to describe some of the important, in my opinion, gaps in functionality and suggest possible ways to implement.
Any system allows you to schedule the execution of tasks, specify the performers, deadlines, etc. As a rule, this means that it is possible to enter a task into the system. Only for some reason it is assumed that the users of such systems are clairvoyants and know in advance what tasks are planned for execution.
There is not a single intelligible proposal, how to move from vague ideas to a list or even a task tree of 100,500 items. Some elements of this approach are observed in the systems of the Application Life Cycle Management class, however, in all such systems, such an aspect as scheduling seriously sags.
')
I dream of a tool that allows you to manage a set of use cases, components, requirements, tasks and implementers in a single information space, with an overlay on the time scale, taking into account the employment of employees and dependencies between tasks. A simple list and even a hierarchy of tasks is not enough to get the full picture. After all, the structuring of tasks can be viewed from different points of view. The importance and obviousness of the tasks changes, depending on the angle at which we look at them. For example, when we look from the point of view of usage scenarios, we most likely will not forget about scenario testing, and when from the point of view of components, the task of designing protocols for the interaction of components naturally emerges. And after we looked at the project from all points of view and were convinced that we had not forgotten anything, we get a fairly decent plan.
When the plan changes regularly, the changes that you make are usually overwritten with past values. MS Project allows you to save the version of the plan (the so-called baseline), then to compare it with the current one. This helps a little when the structure of tasks does not change much. In practice, there is often a decomposition of one task into several others, the addition and deletion of links between tasks, the revaluation of deadlines. Quite often there is a need to play a little, i.e. make changes to the plan in order to see how this will affect the deadlines or cost of the project: add executors to the project, redistribute tasks between executors, add or delete tasks. When there are many such changes, a simple comparison with the basic plan is not enough to understand the essence of the changes that are taking place.
I really miss the change log of the plan, in which you can see what, when, and how it was changed. I would also like to be able to make comments to it, explaining why this or that change was made. Sometimes it is useful to see how the assessment for a particular task has changed over time, to estimate the rate at which new, unrecorded tasks appear. It seems that it should be possible to fix several different states of the plan, so that later you can return to them and compare your friend to a friend. A plan is a tool for a project manager. We live in a changing world, so it is important to be able to regularly make changes to the plan, which is a model of reality. At each time point the project plan consists of two parts:
Over time, the plan must change to meet these requirements. At the same time it should be possible to see how the plan was before.
Practically in all systems, performers are perceived as something easily interchangeable. While in fact, people are very different in terms of performance, and in terms of specialization, as well as many other factors. Simulation of such differences is widely used in computer games, and in project management systems, differences between people are simply ignored.
The use of even elementary information about specialties and employee productivity could help a lot in drawing up a plan.
Project management systems dump a lot of information on the RP and offer him to mess around with it, extracting the necessary information from the abyss of numbers and graphs. The maximum that can be expected is some summary indicators, such as overall project performance or a combustion diagram. But it is known that the devil is in the details. What is the use of seeing that the project * is now * being executed on time, while * the dynamics * of the execution speed is negative. After all, this means that in the near future the project will start to fall behind the schedule, and actions to prevent this problem can (and should) be carried out now, and not when everything has already happened.
I am convinced that a good project management system should analyze a number of important indicators characterizing both the properties of the project as a whole and its individual parts (for example, this may be the performance of individual employees, or the speed of implementation of individual components). Moreover, the analysis should be not only static, but also taking into account the dynamics of change (see above about changing plans).
This will enable the manager to respond to problems in the project not only after the fact, but also before they arise, thereby significantly reducing the degree of their influence.
All project management systems in accordance with the modern trend go to the clouds. Clouds are good, this is correct. But only as an addition to the usual solutions. It is very important to be able to take a project plan and play with it at your leisure, even without access to the network. It is very convenient when, after making changes, you can publish the plan in the cloud, and it will become available to everyone. But it is terribly inconvenient when data * is available only in the cloud *, which means that if I do not have access to the Internet, then I do not have access to my data.
I understand that the disappearance of the local copy of the data is due to serious reasons. If several people simultaneously make changes to the same part of the plan, then combining them in the cloud can be problematic. However, the fact that a problem is complex does not mean that it is not solvable.
It seems to me that for any cloud project management system it should be possible to work with project data locally, with subsequent synchronization, as it is done, for example, by Evernote.
Someone may get the impression that I want a system that will do everything for the project manager, and then his position will be simply abolished. This is absolutely not true. I want a system that automates the routine operations that accompany the activities of the project manager, unloads his brain from unnecessary details and allows you to focus on things that are much more important. Infinite task lists and progress charts prevent a manager from identifying the most important things, making him spend his time extremely unproductive. The project management automation system should not only simplify the execution of elementary operations with entities, but should also reduce the number of entities with which the manager simultaneously operates. This should be done by combining elementary entities into higher-level, abstract ones.
It seems to me that such a qualitative leap is possible only if there is a theoretical model for presenting the project, which will include different levels of abstraction and all the necessary indicators. This model should not explicitly require the use of a particular management methodology. The system will automate actions with the project within this model. No doubt, the project manager will need a clear understanding of the model, otherwise he will not be able to effectively use the system, on the contrary, it will seem to him infinitely complex and incomprehensible.
And what do you miss in project management systems?
What features would you like to add to them?
In this article I want to describe some of the important, in my opinion, gaps in functionality and suggest possible ways to implement.
There are no intelligible funds to help develop a project plan.
Any system allows you to schedule the execution of tasks, specify the performers, deadlines, etc. As a rule, this means that it is possible to enter a task into the system. Only for some reason it is assumed that the users of such systems are clairvoyants and know in advance what tasks are planned for execution.
There is not a single intelligible proposal, how to move from vague ideas to a list or even a task tree of 100,500 items. Some elements of this approach are observed in the systems of the Application Life Cycle Management class, however, in all such systems, such an aspect as scheduling seriously sags.
')
I dream of a tool that allows you to manage a set of use cases, components, requirements, tasks and implementers in a single information space, with an overlay on the time scale, taking into account the employment of employees and dependencies between tasks. A simple list and even a hierarchy of tasks is not enough to get the full picture. After all, the structuring of tasks can be viewed from different points of view. The importance and obviousness of the tasks changes, depending on the angle at which we look at them. For example, when we look from the point of view of usage scenarios, we most likely will not forget about scenario testing, and when from the point of view of components, the task of designing protocols for the interaction of components naturally emerges. And after we looked at the project from all points of view and were convinced that we had not forgotten anything, we get a fairly decent plan.
Inconvenient to work with a changing plan
When the plan changes regularly, the changes that you make are usually overwritten with past values. MS Project allows you to save the version of the plan (the so-called baseline), then to compare it with the current one. This helps a little when the structure of tasks does not change much. In practice, there is often a decomposition of one task into several others, the addition and deletion of links between tasks, the revaluation of deadlines. Quite often there is a need to play a little, i.e. make changes to the plan in order to see how this will affect the deadlines or cost of the project: add executors to the project, redistribute tasks between executors, add or delete tasks. When there are many such changes, a simple comparison with the basic plan is not enough to understand the essence of the changes that are taking place.
I really miss the change log of the plan, in which you can see what, when, and how it was changed. I would also like to be able to make comments to it, explaining why this or that change was made. Sometimes it is useful to see how the assessment for a particular task has changed over time, to estimate the rate at which new, unrecorded tasks appear. It seems that it should be possible to fix several different states of the plan, so that later you can return to them and compare your friend to a friend. A plan is a tool for a project manager. We live in a changing world, so it is important to be able to regularly make changes to the plan, which is a model of reality. At each time point the project plan consists of two parts:
- What was - the actual data on the timing of tasks, labor costs, etc.
- What has become - as we see ourselves further developments from the current moment.
Over time, the plan must change to meet these requirements. At the same time it should be possible to see how the plan was before.
It does not take into account the fact that all people are different
Practically in all systems, performers are perceived as something easily interchangeable. While in fact, people are very different in terms of performance, and in terms of specialization, as well as many other factors. Simulation of such differences is widely used in computer games, and in project management systems, differences between people are simply ignored.
The use of even elementary information about specialties and employee productivity could help a lot in drawing up a plan.
Little attention is paid to the diagnosis of problem areas.
Project management systems dump a lot of information on the RP and offer him to mess around with it, extracting the necessary information from the abyss of numbers and graphs. The maximum that can be expected is some summary indicators, such as overall project performance or a combustion diagram. But it is known that the devil is in the details. What is the use of seeing that the project * is now * being executed on time, while * the dynamics * of the execution speed is negative. After all, this means that in the near future the project will start to fall behind the schedule, and actions to prevent this problem can (and should) be carried out now, and not when everything has already happened.
I am convinced that a good project management system should analyze a number of important indicators characterizing both the properties of the project as a whole and its individual parts (for example, this may be the performance of individual employees, or the speed of implementation of individual components). Moreover, the analysis should be not only static, but also taking into account the dynamics of change (see above about changing plans).
This will enable the manager to respond to problems in the project not only after the fact, but also before they arise, thereby significantly reducing the degree of their influence.
Systems go to the clouds
All project management systems in accordance with the modern trend go to the clouds. Clouds are good, this is correct. But only as an addition to the usual solutions. It is very important to be able to take a project plan and play with it at your leisure, even without access to the network. It is very convenient when, after making changes, you can publish the plan in the cloud, and it will become available to everyone. But it is terribly inconvenient when data * is available only in the cloud *, which means that if I do not have access to the Internet, then I do not have access to my data.
I understand that the disappearance of the local copy of the data is due to serious reasons. If several people simultaneously make changes to the same part of the plan, then combining them in the cloud can be problematic. However, the fact that a problem is complex does not mean that it is not solvable.
It seems to me that for any cloud project management system it should be possible to work with project data locally, with subsequent synchronization, as it is done, for example, by Evernote.
Conclusion
Someone may get the impression that I want a system that will do everything for the project manager, and then his position will be simply abolished. This is absolutely not true. I want a system that automates the routine operations that accompany the activities of the project manager, unloads his brain from unnecessary details and allows you to focus on things that are much more important. Infinite task lists and progress charts prevent a manager from identifying the most important things, making him spend his time extremely unproductive. The project management automation system should not only simplify the execution of elementary operations with entities, but should also reduce the number of entities with which the manager simultaneously operates. This should be done by combining elementary entities into higher-level, abstract ones.
It seems to me that such a qualitative leap is possible only if there is a theoretical model for presenting the project, which will include different levels of abstraction and all the necessary indicators. This model should not explicitly require the use of a particular management methodology. The system will automate actions with the project within this model. No doubt, the project manager will need a clear understanding of the model, otherwise he will not be able to effectively use the system, on the contrary, it will seem to him infinitely complex and incomprehensible.
And what do you miss in project management systems?
What features would you like to add to them?
Source: https://habr.com/ru/post/152953/
All Articles