Microsoft Project way doesn't work, here's what to do instead

Microsoft Project way doesn't work, here's what to do instead

I’ll get straight to the point: Microsoft Project does not work well for modern project planning, and Microsoft Project Server does not work at all for project portfolio management.

Here’s why.

Microsoft Project shift the focus to schedule

There’s a whole generation of project managers who think that a project schedule is a project plan.

In the past the same thing happened to the word presentation, which became synonymous to presentation slides, or rather even a PowerPoint file (“Can you please send me the presentation?”, “I have uploaded the presentation to the cloud drive” etc.). I have talked to people who think that a good presentation cannot be made without slides. Slides are not the only part, and even not the most important part of a presentation, and nevertheless these words became synonyms.

The same thing happened with a project plan. A project plan includes much more important information than the schedule - the project goal, stakeholders, constraints, risks, but the focus was unnecessarily shifted to the schedule, or rather even a Microsoft Project file. Many articles on the internet call this approach “classic project management”, although there’s nothing “classic” about it.

This focus on “when” at the expense of “why” and “what” is what causes projects to fail. It’s not directly a fault of Microsoft Project, but it certainly encourages managers to think “when” first.

The fundamental problem

A project plan ≠ schedule. Managers should keep in mind “why”, “what”, and “who” in addition to “when”, and during execution focus on risk management and communication as opposed to obsessive schedule planning, monitoring, and control.

A project plan can look like a set of wiki pages or documents, but certainly not as a schedule.

Microsoft Project plans are difficult to maintain

A new project schedule in Microsoft Project always looks so neat. All task durations and dependencies are nicely defined, resources assigned, calendars taken into account. Look how aesthetically pleasing these schedule examples below are.

But then the reality kicks in. There’s an urgent unexpected task Alex has to do, Betty is ill for the whole week, and Carl’s work takes more than anticipated. The neat cascades in your project schedule start to take ugly forms, automated calculations start to show crazy dates (because Betty’s work was on the critical path), and now you have two problems on your hands:

  1. What to do with the project work;
  2. What to do with your schedule that’s no longer up-to-date.

Sure, you have risk buffers, and you can probably run some tasks in parallel, which you previously thought to be strictly sequential, but all this planning with a precision of one day does not make sense anymore.

At this point you can make one of two choices about your Microsoft Project schedule:

  • Either forget about the detailed planning and work with higher-level milestones. If you decide to do that, ask yourself whether it was worth it to make this one-day-precision planning in the first place.
  • Or try to bring planning back to reality. If you do that, eventually you will find yourself in a situation where instead of doing real work you spend time to keep adjusting the schedule to reflect the real-life situation (which defeats the whole purpose of project schedule).
The fundamental problem

There are hundreds if not thousands articles about the issues with early work decomposition and excess precision in project planning, so here’s the short version:

  • The more precise your planning is (in terms of time, people etc.), the more “brittle” it becomes. Any small deviation, even insignificant for the overall result will lead to schedule changes. In the end, the work you put to create and keep this detailed schedule up-to-date does not justify the value of having such schedule in the first place. And most of your stakeholders won’t need this level of detail in any case.
  • WBS decomposition of all the work upfront is a long and costly process. While in some cases it may be necessary, keep in mind that future changes may render this work useless. Relying on early work decomposition makes your project management process significantly more expensive without adding a lot of value.

Microsoft Project Server for Portfolio management takes a passive approach

So Microsoft Project does not really work for project planning. But does Microsoft Project Server work for project portfolio management?

The answer unfortunately is also “no”.

Microsoft Project Server treats “project portfolio” as a collection, an aggregate sum of all the projects in the portfolio. The tools you are offered are mainly targeted at reporting, and not communication or decision-making:

  • You can see a simple non-customizable list of projects on the main screen;
  • You can make reports using Reporting and Analysis Services or another reporting / OLAP solution.

By putting together all the details of individual projects, a “portfolio” should come together. This hugely misses the point of project portfolio management.

The fundamental problem

Project portfolio management is not project reporting. Project portfolio management is about project selection, prioritization, and strategic alignment. Project portfolio management answers the question of where the organization’s limited resources should go to add the most value.

From the software standpoint, the data that project portfolio management system uses cannot be fully derived from the systems related to project execution. For example, project prioritization does not only / mainly depend on the project schedule and budget data.

By shifting focus from proactive decision-making to reactive reporting, Microsoft Project Server reduces project portfolio management to monitoring and coordination function.

If not Microsoft Project then what?

The optimal solution will depend on your situation, but here’s a setup that will work in many cases:

For project management use:

  1. Document management system / wiki pages, where you can keep and share important information about project goals, constraints, stakeholders, risks etc.
  2. Task management system, where you can manage task execution. Use “rolling wave” scope decomposition instead of trying to analyze everything upfront. If you are not working on too many tasks at the same time and your team is in one physical location, you can use a physical board too.

For project portfolio management use a dedicated project portfolio management system.

Example PM/PPM system setup

Shameless plug

We are making Portfoleon, a lean project portfolio management system with a strong focus on simplicity and visualization. It’s super-easy to get started with, and it will integrate into your IT landscape well using the open REST API and/or Zapier connector. It has a dedicated Jira connector as well.

We believe that a good project portfolio management is much more about visibility, transparency, and meaningful communication than about total control and complex calculations.

If you believe the same, we will be happy to help you, just click that button below:

Recent Articles

The Emperor's New Strategy

A good strategy is a strategy that may fail.

Agile Cult

The biggest harm for agile does not come from heretics, it comes from zealots.

Yes-managers, No-managers, 'Yes and No'-managers

Yes, No, Yes and No - a trio of ineffectual leadership styles that bring your company to a catastrophe.