Mark JamesProject Manager| VariousLondon, United Kingdom
Hello
I'm new to Programme Management and have just been transferred to the programme office of my company. I've been asked to work out and display the programme critical path and don't know where to start. There are 8 projects in the programme (non of which have the critical paths mapped). I was thinking that I should map the project critical paths in the first instance and then work out the programme one. Is that he correct approach - can I do the programme critical path in MS Project? Any examples/help would be appreciated. Saving Changes...
Sort By:
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
Mark,
Do your projects have plans with activities and do they have rolled up/summary tasks?
If so and if you are using MSP for your programme - In the programme plan you really only need to reflect the key summary activities of the project(s) detailing their duration and effort.
Then do critical path analysis o nthis informaiton. It is up to the PM's to be reflecting to the programme manager which summary activities are at risk/slack in them etc so the detailed view is down to them to manage (unless like I have sometimes managing both Programme & Projects!!).
You can add the projects tasks in manually taking the information from the PM PLans or as I have created in the past. A Master Programme MSP and insert a copy of the PM's Projects MSP with a non changing name in your programme folder (e.g. Programme XXX.MSP, Project A.MSP, Project B.MSP) then each week get the PM's to save a copy of their updated "accurate" project files to your folder with that specific name.
When you open MSP you get an overall view. Problem with this option is - what tasks do I want to focus on I have over 300....
So I would suggest the PM's adding a Text 10 or "non used text" column renamed to Prgm or something. Amend the properties to provide a drop down list Pgrm and/or anything else. That way you can filter the many projects you have inserted to only the tasks that you want to see on the programme plan. You inform them what tasks are to be set in the Text 10 column to Pgrm. Also they should inform you of any new activities being addedd to their projects so you can assess if they need to be reflected in your programme plan.
By the Way - I always amend the MSP PERT chart diagrams as they are not informative enought and I set them to a more formal display with the top row of Early Start | duration | Early finish, middle row Name, Bottom Row Late Start | Slack | Late FInish
Regards
Peter
Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
I would treat the projects as whole items and just map the critcal path of the 8 projects. Does Project A need to be completed before Project B can start? Can Project B get started, but has a dependency on the completion of Project A? Is Project B completely independent of Projet A?
One doesn't really need to have the critical paths of the individual projects. If the individual tasks of the projects are tightly coupled, one does not have separate projects. Just set out the critical path using the projects as the WBS items.
Saving Changes...
Darren KosaPlanning & Controls ContractorHampshire, United Kingdom
Hi Mark,
First of all congratulations on your appointment.
Your approach, get the individual projects to determine their critical paths is feasible. At the very least it would be of benefit to the project themselves to gain an understanding of which activities might be critical. I say might be critical, because with MS Project criticality is always Black or White, there is either positive float (slack) or there is not. In real life it’s more shades of Grey.
Amongst others, MS Project does not factor in whether the schedule logic is correct or even realistic, or that task constraints suppress float calculations, there are resource constraints, and level of effort or hammock tasks shouldn’t be on the critical path.
If you’re going down the route of first identifying project level critical paths, I would first run each MS Project file through a schedule analysis tool such as Acumen Fuse*. This will give you a good indication as to whether the MS Project schedules themselves will be of sufficient quality to enable a reasonable approximation of a critical path.
If you get the project schedules right, then you’re in with a shout of identifying a programme critical path, this is because programmes are a slightly different kettle of fish to projects.
With projects there is a finite amount of time to deliver the project. Once the project has been completed, then the PM hopefully gets a pat on the back for a job well done. But who manages the benefits? Who looks after the interim solution or architecture until the final project in the programme is delivered?
It could be that it’s part of the programme’s terms of reference, in which case you could amalgamate all the project schedules into a single one master schedule, but still miss out on vital activity. As programmes are driven by an end state, you may need account for the programme activity in your critical path as-well-as the project schedules themselves.
Another thing to bear in mind is your stakeholders. By presenting a programme critical path in a 10,000 line Gantt chart, do you think they’ll be able to follow it and make informed decisions off the back off it?
As a Plan B, I would try to use the information contained within each individual MS Project file to try and create a timeline for each project. With the help of a few strategically placed milestones and dependencies, you can summarise each project chronologically, and then show all 8 timelines - with a smattering of programme activity - on a single page.
Working with your PMs and programme director you can then create a programme critical path from the single page view - to save time you could make an educated guess as to what you think the programme critical path is, but I would always recommend validating any assumptions used as your director may have a different view of priorities.
Using each method, make an educated guess as to how long it takes to replicate, note the pros and cons for each process, and then make a recommendation to your boss as to which method you think will be least onerous.
Programme critical paths will always be subjective approximations. It may be that it takes too much effort to achieve a consolidated programme view and that the overhead outweighs any perceived benefit.
Regards,
Darren Kosa
* I’ve no affiliation with this software and there are other tools on the market that do the same thing equally as well. Saving Changes...
Hi Mark,
If I would be in your place, I would link these projects which each other and establish a project - subproject relationship, in a way that each sub-project would be a summary task of the main project. Then establish critical path for these summary tasks. This way my focus would be on jotting down the critical path for tasks rather than focusing on the fact that "am I doing it for a project or a Program".
P.S: OWB would be my tool of choice.
Cheers,
Kushal K. Sawarkar Saving Changes...
Alexander LehmingSr. Project Manager| UCLA HealthWoodland Hills, Ca, United States
Congratulations.
Some of these posts already point you in most of the right directions. One of the things you have to look out for though is resource planning.
As you load up the 8 projects into your master projects, run a resource report to ensure that you do not have resources overcommitted, especially along your critical path.
After you have gotten some of your baselines set up, you might also want to get together with your project managers and start looking at critical chain management rather that critical path.
