Blog Archive

Critical Remarks on Present-Day Project Management Systems

While writing the article on application of MS Project for project management, I was haunted by the feeling of writing something wrong. “It can’t be true”, I thought, “that such simple things are done in such a complicated way within the program being one of the most popular tools for project management”. I checked myself, evaluated relevance of my needs and studied other programming solutions. One way or another, I came to the following distressing conclusion: as a project manager, I have certain needs which are either forgotten or deliberately neglected by the developers.


In spite of impressive variety of capabilities featured by present-day project management systems, there are some issues I’m just unable to solve without auxiliary means due to natural constraints of human thinking.


I’d like to devote this article to description of some functional deficiencies which, in my opinion, are important, and to propose possible ways of dealing with the above-mentioned issues.


There are no adequate means facilitating project scheduling

Any system enables you to schedule task implementation, assign employees and timing, etc. As a rule, it means you can enter a task into the system. However, for some reason users of such systems are expected to be clairvoyants and foresee the tasks to be implemented. There are no comprehensible ways of coming from vague ideas to a task list, or even a task tree comprising 100, 500 items. Some elements of this approach can be found in systems resembling Application Life Cycle Management. However, all these systems feature poor scheduling.


I dream of a tool which will enable me to manage a variety of use cases, components, requirements, tasks and employees within a common information area, all this being related to a time-scale, taking into account availability of employees and correlations between the tasks. Just a task list, or even a task hierarchy, is not enough to get the complete picture, as task structuring can be seen from different points of view. Importance and obviousness of tasks tend to change, depending on our angle of view. For instance, when we look from the point of use cases, we will unlikely forget about use case testing, while looking from the point of components will naturally put forth the task of designing components interaction protocols. Thus, having checked the project from all points of view and ensured nothing is left out, we get a rather decent-looking schedule.


Working with a changing schedule is inconvenient

As a rule, when a schedule is regularly edited, newly introduced changes erase the previous values. MS Project allows keeping a certain schedule version (so-called “baseline”), in order to compare it to the current one later on. It helps a bit, when task structure changes little. In actual practice we often decompose a task into several ones, add and delete links between the tasks, re-estimate the timing. Every so often we need to “play” a little, i.e. to introduce some changes into our schedule in order to see the way final project timing or costs are affected: we may add some employees to the project, reallocate the tasks among the employees, add or delete certain tasks. In case of numerous changes, these changes comprehension requires more than just comparison to the baseline.


I really lack schedule change history showing what, when and how was changed in a certain schedule. I’d also appreciate the possibility of supplying this change history with comments, explaining the reasons for this of that change. Sometimes it is useful to see how the estimation of this or that task has been changing in time, to evaluate how quickly new, unforeseen tasks arise. In my view, there should be a possibility of saving several different schedule versions, in order to come back to them later and to compare one to another. Schedule is a project manager’s tool. We live in a changing world, that’s why it is important to have a possibility of introducing regular changes into the schedule, this schedule being a model of our reality. At any moment the project schedule comprises two parts:

  • Previous version — actual data on tasks timing, work, etc.
  • Current version — the way we see further course of events starting from the current moment.

In order to comply with these requirements, our schedule should change in time. At the same time we need to be able to see how the schedule looked like before.


The fact that all people are not the same is not taken into consideration

Virtually all systems consider employees to be easily substitutable. In fact, people differ from each other greatly in terms of efficiency, field of expertise, and many other features. Such differences are actively simulated in PC games, while project management systems just ignore diversity of people.


Application of just basic information on employees’ efficiency and areas of expertise could be of real help for schedule planning.


Little attention is paid to problem areas diagnostics

Project management systems just dump a pile of information in the head of a PM, and he is supposed to tackle it on his own, extracting the necessary data from the ocean of numbers and diagrams. If he is fortunate, he will find some cumulative factors, like project general progress or burn down chart. Yet, it is well-known that the devil is in the details. Where is the use of seeing that the project is keeping up to the schedule now, while trend of implementation speed is negative? In fact, it means that in the nearest future the project will be behind the schedule, and preventive steps against this problem may (and should) be taken just now, not when it all will have happened already.


I am sure that a good project management system should analyze a range of important factors reflecting the characteristics of the whole project, as well as of its separate parts (for example, these factors may include progress for separate employees, or separate components implementation speed). Besides, there should be not only static analysis; it should also take into account time dynamics (see above the paragraph on changing schedules). This will provide a manager with the opportunity to respond to problems in his project not only post factum, but also before such problems arise, thus decreasing their adverse effect greatly.


Systems are moving to the clouds

In accordance with the fashionable modern trend, all project management systems are moving to the clouds. Clouds are okay, certainly, but only in case they support usual solutions. It is very important to be able to take the project plan and play with it at leisure, even if you have no access to the internet. The changes introduced, it is really convenient to publish your schedule in the cloud, making it available to everyone. On the other hand, it is extremely inconvenient when data is *available in the cloud only*; in other words, for me no access to the internet will mean no access to my data.


I understand that local data copy extinction is caused by serious reasons. If several people will simultaneously change the same part of the schedule, it can be difficult to integrate them all in the cloud. Yet, a difficult problem does not imply to be insoluble.


I think that any cloud project management system should have the opportunity of processing project data locally, implying the following synchronization, as it is done, for instance, by Evernote.



Somebody may have an impression that I want to have a system which will do all the work for a project manager, thus simply eliminating his position. It is totally wrong. I want to have a system which can automatically perform the routine operations accompanying the work of the project manager, clear unnecessary details from his mind and enable him to concentrate on much more important things. Endless task lists and progress tables obstruct the core issues from the manager, making him waste his time. Project management automation system should not only simplify implementation of elementary operations with entities, but also decrease the number of entities operated simultaneously by the manager. This should be done via uniting elementary entities into higher level and more abstract ones. I think that such a quantum jump can take place only in case there is a theoretical model of project presentation, which will include various abstraction levels and all the necessary factors. This model shouldn’t expressly demand application of this or that management methodology. The system will automate the actions taken in relation to the project within the framework of this model. No doubt, project manager will need clear understanding of the model, otherwise he will not be able to use the system efficiently; on the contrary he will find it extremely complicated and incomprehensible.

Only the registered users can create posts.

Reader Comments