Valuable Information When Managing Multiple Projects

Question

When managing multiple projects at once, what information would be most valuable to a project manager if the projects are related? Not related?

[Purpose is for the development of new project management software]

Edit: These are great responses! Thanks so much. Very helpful.

Edit: Clarification of question: I do understand the answer and it's part of our mission. There is no reason that project management software should get in the way of management or create a steep learning curve which prevents the true understanding of the software itself.

• "High Level"

  • Project 1
  • Project 2
  • Project 3

All three projects are under the supervision of a p.m. or a team of. Our team is curious what information is most valuable to see at "high level". Although the overall goals of the projects are important, I have a feeling more relates to their success than simply making sure that their large goals or milestones are hit.

Current health of the project in terms of deliverables, over/under budget, and over/under time are obvious to see at that level for each project in a unified way. We were curious what other things came up as a common desire to see at that high level out of project management software.

Answer 1

There are multiple ways of answering this question; one is mostly philosophical, which involves picking the right team leaders and the right kind of developers who can raise red flags at the right time. Also involves fostering the right kind of culture where everyone is allowed to raise their hand if they believe a project is faltering and making yourself available to people in all the projects. Let’s not elaborate that side here since you did mention that this question was asked because you could decide the features to implement in new project management software, so let’s focus on the parts that you could implement in the project.

1. Burn down charts are an awesome way to indicate velocity and health of a project at a high level so burn down charts of the current sprint of all the projects is something you can display to a program manager who is heading multiple projects. For more information on burn down charts see this link: http://www.tinyurl.com/burndownchartpost.
2. Build a “concerns” feature into the product which allows every single member in the team to raise critical concerns which the program manager can review like a hawk.
3. Ability to look at a monitor “functionally important” features that have been moved to the “next sprint” for more than two sprint. Usually teams tend to move features to the next sprint when they run out of time. If a single feature is getting moved to the next sprint for more than a couple of sprints the feature is either too complex or not important and probably can be dropped (thus reducing the psychic weight on the team).
4. Check-in pulse rate. Ability to hook on to SVN or source control system and see a quick graph of the rate of check-ins. In general small incremental constructive frequent check-ins is a good thing. If a project hasn’t checked in anything in more than a couple of days there is something wrong or they are working on a huge feature and probably trying to bite on more than what they can chew.
5. If you have build automation a quick graph from the continuous integration server showing how frequently your build was broken or healthy in the last month. Constantly broken builds are bad because they show lack of responsibility on the development team, and slow down other developers.
6. Test case reports specially if you have automated test cases. Your ability to monitor at a high level the percentage of test cases that passed and the percentage that failed on a per project level can show you the health of the project. For methodologies like Test Driven Development this might actually be able to show you the progress of the project as well.
7. A feature where the project lead or individual project managers fill in the classic stand up questions “What progress did we make yesterday? What progress are we planning on making today? Is there any external help we require?” on a very high level (not more than a line each) for every single project.
8. A Happiness index where every team member can click on a “mood” smiley, ranging from a laugh to a sad face. Average it out and show the mood of the project. The premise is that happy developers produce successful projects so why not average out the moods of developers and capture the mood of multiple projects when you are managing multiple projects. Along with other matric this could be a really useful metric.

Also note that NOTHING replaces talking to people and one on one interactions; the above points are there because I assumed that you wanted advice on “features” you could introduce in a brand new project management software that you are building. If the answer was generic it would have been very different and much longer. Hope this helps you in the development of the product. Good luck for your product.

Answer 2

I am sure this question can be answer in one of 100 ways, but I will give you make 2 cents on "valuable information" for multiple projects.

Resource allocation/capacity/availability

The program manager has 10 resources, with xyz skills. 2 of them are 100% on portfolio of projects x, 3 of them are 50% across project A on portfolio x, and project B on portfolio y. you get the idea. This is very difficult to get right in the real world.

Milestones

Important milestones that are late/on-track/early <- some system intelligence here will be nice.

Answer 3

Priorities. Definately the most crucial one. There is a slight chance that everything you run is important. You should never lose focus on getting priorities from your stakeholders.

Answer 4

Don't get dragged to deeply into the details. If you are managing multiple projects, related or otherwise, you need to keep the focus on the overall goals of the projects.

Answer 5

Specifically talking about related projects, I would love a great overview of the dependencies between them, the time they are expected and the type of the dependency (is it a specific deliverable required, a capability that one project needs to continue, or specific specialists, ...).

Including a quick link tot the specific risks involved with these dependencies and the mitigation strategy ...

Answer 6

Every project has its own objectives and constraints. Focus on them and don't get yourself confused by any sort of mixed objectives or constraints. Always isolate projects one from another.

When you see that they affect each other in some way - identify and document these conflicts as risks (both negative and positive). Risk management should be done more aggressively in your situation.

Answer 7

One thing I have only seen alluded to - managing multiple projects (both related and unrelated) is generally seen as "program' management.

In this type of management, the information needed is that which tells you, are these projects progressing towards the desired goals? Those goals could be profit, reputation, business value, innovation, etc. It's different for each company. But your company is engaged in these projects for a reason. So as the projects go, you'll want to watch schedule, resource allocation, budget, etc., with an eye on how they overall are affecting your company.

As an example - I typically manage 20+ construction projects (as a contractor). So I have two central focuses (focusii?). I watch the projects individually, but I also watch them in the larger context of how they relate to my division. Do we as a division have enough manpower to meet my schedule AND the schedules of the other projects? Enough equipment? How are my projects affecting our target margin goals? Cash flow? WIP?

When managing multiple projects you have to be aware of the other projects around you, even if seemingly unrelated, because if your company took them on, they;re all related. So if you're project succeeds and another fails, you're only half successful.