Blog Archive

Managing Multiple Projects (1/4): Experience in Automation of Managing a Pool of Simultaneously Implemented Projects

Any IT professional is familiar with such a person as Project Manager, or PM. His duties and standard algorithms of his work are listed by a number of methodologies. The range of issues is studied so profoundly that it has its own “classics” (PMBOK, Oracle AIM, or Microsoft MSF) and “image breakers” (Scrum, XP, and other Agile methodologies); whereas the number of programs automating PM’s work is beyond estimation.

All these methodologies and programs leave out an important class of managers who, in a sense, also manage projects, though their work differs drastically from the work performed by PMs. Here we speak about the managers who are responsible not for a single project, but simultaneously for multiple projects (may be, for tens and hundreds of them) implemented by their subordinate employees. There are many such managers in the IT community, including heads of development departments in IT companies, heads of small software developing companies, heads of internal IT departments and employees of project offices. They do not manage projects directly (it is PMs’ business), yet they do supervise projects selection, ensure common success and deal with problems arising “at the junction”. Further on we will provide a detailed review of tasks, which are typical for a manager who controls multiple projects, yet non-existing for PM within the framework of a single project. Speaking of direct control, we should note that such a manager controls project managers only, being, actually, “manager of project managers”, or MPM. This particular “ringing” abbreviation will be used further on in our article.

It goes without saying, that MPM bears more responsibilities than a manager of a single project, as he controls many more people, either directly or indirectly. He is much more exposed to notorious fluidity of requirements in IT projects, this fluidity being caused by customers’ misimpression that software code can be easily corrected at any moment. Thus automation of routine everyday processes is much more important for MPM than for PM. That is why it is so surprising that the market actually lacks software specially “tailored” for the needs of MPM.

“Oh, come now!” an attentive reader will return. – “There are those systems for project portfolio management, there is MS Projects Server featuring its wonderful workload diagrams. Even tracking systems have add-inns providing capabilities for managing multiple projects”. Nevertheless, as soon as you start applying these solutions, you will see that this functionality is “attached” to systems intended initially for a single project. These systems were not designed “from scratch” for dealing with particular problems of MPM, like “casting employees for new works”, “motivating of employees”, “new projects kickoff”, etc. That’s why such systems are not convenient for everyday use.

If we consider advanced project portfolio management systems, for example, Oracle Primavera or SAP RPM, they will certainly meet the requirements of MPM. However, their functionality is much wider; the systems are rather awkward and cause high introduction costs, both in terms of time and resources. Really, we can hardly imagine such a situation when a department head who needs to deal with his personal tasks quickly and at no cost would use a SAP or Oracle module for his 20 projects.

Standard Tasks and How to Complete Them

By the nature of his occupation, MPM should regularly perform various tasks. A specialized program should help MPM in completing these tasks in such a way, so as to provide him with the relevant information necessary for making managing decisions, and to warn him about any coming or existing problems. In practice, initial information on projects is often stored in different project management systems and even in tracking systems. Nevertheless, MPM needs this information to be presented to him in a consolidated and clearly evident manner.

        MSM Tasks

For each task we will consider:

  • a number of situations causing MPM to set and to solve the standard task in question;
  • possible options of dealing with the situation and the information which should be provided to MPM by the program in order for him to make decisions.
Only the registered users can create posts.

Reader Comments