More money and time gets wasted trying to automate project portfolio management (multiple projects) than on any other project management tool. The reason for the waste is that decision-makers lose sight of the purpose of portfolio management. Other agendas, purposes and goals take over and lead to all the waste and kill the effort. These killers include:
- giving everyone access to all the project data
- giving the accountants earlier control of expenditures
- improving the communications between project team members and project managers
- letting the sponsor spot problems before the project manager see them
The process of project portfolio management should have these objectives:
- Managing the utilization and availability of people working on projects
- Allocating resources to projects based on their priority as set by management
- Reallocating resources based on new projects, change requests and variances
- Tracking actual results versus the plan and distributing the results to managers and project managers
Project Portfolio Management: Software Selection
Searching for the best project portfolio management software can be a daunting task. Many choices exist and many people have their own requirements. But there’s one piece of advice I always use in these situations. It’s the answer answer of my university professor when asked whether there is a best programming development language out there.
“The best tool does not exist. The better tool is the one that serves you best in the situation at hand.”
There are a rapidly growing number of tools currently available to help organizations manage projects. Some are provided by big market names, others are cloud-based services or open source. Project Schedule & Software Main Page
I will not talk about comparing the tools; I do not have such knowledge. My point today is to tell you a story of how we have used simple tools to achieve our short term and mid-term goals. And we got rid of the added complexity of an off-the-shelf software.
In 2008 we had to work with many parallel projects in a matrix organization with resources shared among several projects. Demand, especially for specialized resources, had increased steadily over the preceding years. At the point when the demand outgrew the capacity, the lack of a proper portfolio and resource management methodology became obvious and painful. We had issues with over-promising, managing priorities, impact analysis of changes, and the snowball effect of delays in all the projects sharing the same resources.
We established the Project Portfolio Management role to streamline the process. The process we designed established a work pipeline matching the PMI project phases. All the new project requests were queued at the start following initiation, planning, work-in-progress, quality control/management and close out. On the other side, we created the catalog of resources and skills in order to calculate the “supply.” This would serve as our supply-demand chain. The available free capacity would be shared with the senior management to help the decision-making for new projects and approval of changes.
The first question from the portfolio team was, “What tool do we use to manage this complex process?” We started to use MS Project. As it came out, rolling out a brand new, still unstable process, directly into a complex tool was not such a good idea. I think the tool is a good one but instead of helping us move faster, it was getting in the middle. Instead of focusing on the process, we were spending our energy on discussing the technology. It became a source of excuses and justification for failure. We heard things like, “I could not do my work because the tool is not good.”
After 4 months, we made the decision to drop the system for the time being and focus hard on the process. To tackle the need for reports and KPI’s, a simple Microsoft access database was created. It contained all the milestones of the projects, their interdependence and the assigned resources. We kept information in the portfolio database only to the level of the WBS and milestones, not to the full details of a project plan. It meant more manual work, but it was a simple tool, flexible and adaptable to the fast changes of the process. And it left no room for excuses. The tool, together with the process and the maturity of the team, kept improving and growing.
Today we are using commercial software to manage single projects but our capacity for planning, portfolio management is still running on a custom developed system. It has evolved much from the first version but is still simpler and more flexible compared to the commercial systems we have evaluated. It incorporates our specific requirements for reporting, risk management, internal workflow, organization structure, approvals, status reports, escalation, etc.
As a final note, technology is very important, but in the end it has to serve you, not the opposite. And it’s a technology guy who says this.