Project Management

Please login or join to subscribe to this thread

Portfolio and Program Management Dashboards..Is there a difference?

linkedin twitter facebook   Governance  
avatar
Jeff Dahl Project Leader| Edward Jones Maryland Heights, Mo, United States
Good afternoon to all the learned people.

Recently I have been in discussions on how we are tracking our portfolio of projects, using individual dashbaords for each project, and if for our programs we should use the same dashboard format. This dashboard would be used exclusively for stakeholder communication inbetween regular update meetings.

I, for one, think that if a program is under way with serveral sub projects all focused on the an over all objective that the program dashboard should contain input from all sub projects, such as milestones and % complete. The question is which milestones should be reflected.

Looking at projects this way, portfolio and program model, is new to our organization so I have been asked to look into how other project managers / leaders report status on project programs. I have a pretty good handle on dashboards for our individual projects.

So I ask everyone, if you are leading a program with many sub projects running concurrently how do you report on the overall status of the program to the program's stakeholders.

Thanks
Jeff
Sort By:
avatar
Manjeet Singh Senior Program Manager| Cognizant Technology Solutions Paris, France
Hi Jeff,
Program progress can be reported pretty much in the same manner as projects.
You would want to give a RAG (Red-Amber-Green) status on the Schedule, Budget, Cost, Scope, Risks, Staffing, Dependencies (among constituant projects). You can also list main Achievements during elapsed time period, List of man milestones, List of top ten Issues & Risks, Achievements Planned for the next period, New Program Scope changes.
Hope this helps
Manjeet
avatar
Gabrielle Maher PMO Consultant| Independent London, London, United Kingdom
Hi Jeff

The main difference in project reporting - compared to programme reporting - is the PMO (Programme management office) should complete the programme level dashboard to reflect the 'true' status of the programme and its constitutent projects.

For project status reporting - Project managers should complete a highlight reports (or dashboard) for their individual projects prior to the PMO completing the programme level dashboard (balanced scorecard).

MI Reporting to senior management also needs to go through an assurance and review process. There tends to be 3 levels of reporting for Programme Portfolios - 1) Project level 2) Programme level 3) Programme Portfolio. Level 2 and Level 3 are subjected to a review process which the PMO should schedule - before they are distributed to management. The purpose of the review process is to 'assure' the accuracy of each level of reporting. This is a key function of a PMO.

Most organisations do a monthly reporting cycle - but some do it more frequently. The project level review process should review the status of each project - a) the plan - %complete in terms of delivery, milestones met. milestones slipped, dependencies, b) Risks, c) Issues d) dependencies, e) scope creep and f) finance.

Dashboards should be short documents - a few pages - which use RAG status (Red, Amber, Green) to indicate the overall health of a project. Typically the KPIs are a) RIsks b) Issues, c) Dependencies d) Change (Scope creep), e) Plans - if the project is on track, f) Resources, g) Finance (actuals v forecasts - cost to date h) Governance i) Compliance j) Quality k) benefits.

You would also need to track at a programme or portfolio level all project deliverables - and products. I also check if an MSP Plan exists (you would be surprised!), PID (Initiation Document), Finance template, Risks and Issue logs). I also highlight when a plan is baselined - this will show you if the end date is an early estimate or a more realistic end date that the PM feels they can commit to. If the project plan is baselined you can also track realistic start and end dates - and all stages of the project.

The most important issue for programme managment is dependency management - all dependencies need to be tracked closely (I do this using milestones for internal and external dependencies). Scope creep at every level is something you need to also track (project, programme and portfolio).

I also track key benefits to be realised - and track the delivery. Management like to see this level of transparency as it assures them that the investment they have made in projects and programmes etc. is realising the benefits they set out to achieve.

I also agree a standard set of milestones for each project - these should track the 6 stages in the project lifecycle (Startup - Analysis, Design, Build, Test, Implement) - or whatever lifecycle you have agreed. I use them to track the start and end of each stage in the lifecycle - they should also track all dependencies (inbound and outbound), all major deliverables and products. If you have a gate Quality process - you should also track when each checkpoint review is scheduled.

That should be enough to get you started - best of luck in your new endeavour. You will find that this level of focus and transparency will provide management with much more accurate and appropriate MI.
avatar
Mark Price Perry Business Driven PMO Evangelist| BOT International Orlando, Fl, United States
Hi Jeff,

Great post and replies. I would only add two things.

First, most folks view dashboarding as a way to provide an intuitive view of how things are going in a manner that presents the "least" amount of information to support the needs of the viewers of the dashboard, typically management and the leadership team. Please don't take this as condescending, but what you think or I think the dashboard should show is irrelevant. What is relevant is what the user (not provider) of the dashboards thinks. For example, the PMO of a very large Fortune 1000 firm that I know quite well actually reports to the COO, not the CIO. And, despite the fact that this company uses one of the leading high-end PPM applications, they actually do their Program Dashboards for the leadership team in PowerPoint and make them available via the Program Dashboard Page of the their PMO Best Practice Framework. These Program Dashboards are very high level, use RAG indicators, and speak to Program Overall Status, Cost Status, Schedule Status, Risk Status, Benefit Delivery Status, etc. And, for further insight into program component details, provided on the Program Dashboard is a link to the appropriate area of their PPM application. So, rather than dashboarding sub-component items, this detail is easily found. This can keep your dashboards simple. For example, if you have 15 programs that each have 10 component projects, that can be quite a bit of work to dashboard 150 components. And, let's say that your RAG indicators show 10 components going well (green), 3 components under cautionary status (amber), and 2 components under high alert (red). The odds are that the leadership team will only want (need) further information for the troubled Programs. Hence, from a Six Sigma (defect elimination) point of view, dashboarding all of the component projects would represent waste as this information is not needed. And, even when the leadership is made available some amount of component level dashboarding, they will no doubt want to see the details per the functional application, ie. the PPM tool or whatever tooling that is used by the Program Office. So, keep the dashboard as simple as possible. Provide what the user wants to see; this may or may not be the same thing as what the Program Office thinks is a good idea to provide just because they can and would like to. And, rather than overly complicate the dashboard, provide a link to the appropriate are of the PPM tool (or equivalent) to view further program and component details.

And second, I would just add that for many organizations, the terms program and portfolio management are used interchangeably and hence incorrectly. Getting back to the example of 15 programs each with 10 component projects, while there is typically a fixed relationship between the program and the program component, there is not necessarily a fixed relationship between the portfolio and its components. By that I mean for a given set of programs and projects, you can have multiple portfolio views. One view could portray the portfolio components by risk/return. Another could portray the portfolio by investment class, or by line of business, or by market segment, or by geography, or by business strategy, etc. The ability to present different views of the portfolio enable management and the leadership team to evaluate, prioritize, and balance and manage the portfolio amidst a variety of parameters. I just wanted to clarify this as many organizations see more value in executive dashboards when the dashboards provide these kinds of high-level insights into both Program Status and Portfolio Status as opposed to the other approach of proving a singular Program Status view with component project detail. Not knowing more of your organization, this may or may not be applicable. But, most executives would rather see high level status in a Program Dashboard accompanied by Portfolio Views aligned to the executive team's goals, objectives, and strategies. They don't need a duplication of detail that already exists in the PPM tool or equivalent.

Just a perspective. As always, I hope we hear and learn from others. ~ Mark

avatar
Syed Rehan Baaqri Senior Enterprise Portfolio Manager| PepsiCO Mckinney, Tx, United States
Good day All,

I urgently need your support in getting Excel made Dashboards if anyone has any!!...i really need it for an immediate assignment.

Please help!
...
1 reply by Michele Deo, MBA, PMP, ITIL
Jun 06, 2018 7:22 PM
Michele Deo, MBA, PMP, ITIL
...
Smartsheets has Dashboard capability and functions very similarly to Excel. you might want to give them a look.
avatar
Danie de Waal Experienced Project Management Consultant| KPMG (Pty) Ltd Ferndale, South Africa
I find it very important to focus Programme Reporting on the Benefits Realisation and Achievement of Capabilities. If you focus your reporting on the same criteria that you would use for projects, then the danger is always that your focus might shift to managing the programmes as projects, and you loose any of the benefits that you can achieve by grouping projects into programmes.
avatar
Vincent Guerard Coach - Trainer - Speaker - Advisor| Freelance Mont-Royal, Quebec, Canada
Great I would only add that Programme reporting is more than the sum of its projects.
Impact of one project to others need to be reflected

and yes focus on Benefits realization
avatar
Michele Deo, MBA, PMP, ITIL Technical Project Manager Principle| American Electric Power Sequim, Wa, United States
Feb 10, 2009 6:02 AM
Replying to Syed Rehan Baaqri
...
Good day All,

I urgently need your support in getting Excel made Dashboards if anyone has any!!...i really need it for an immediate assignment.

Please help!
Smartsheets has Dashboard capability and functions very similarly to Excel. you might want to give them a look.

Please login or join to reply

Content ID:
ADVERTISEMENTS

One man can be a crucial ingredient on a team, but one man cannot make a team.

- Kareem Abdul-Jabbar

ADVERTISEMENT

Sponsors