I was previously, a Project Manager, and now I have been catapulted into a position within my company as a PMO Manager on a change programme in a totally different division (I have had no choice and no experience as a PMO manager). There are about 28 projects in the change programme, and from what I can see it's all a bit of a mess. Just wanted to ask some advice really.
Firstly, none of the projects seem to have a clear up to date plan that shows the critical path. There is simple key milestone plan for each project, which is being used to monitor programme progress but that is it. The progress is summarised for management reporting on a monthly basis and each milestone is given a RAG rating. Surely, this isn't sufficient to monitor the overall progress of the programme? My thinking is that all projects should have individual project plans in MS Project (the software we use), which clearly shows the critical paths of each project. Further, from these I should create a master programme plan, that includes ONLY the critical activities and deliverables for each project (linked from individual project plans - is this possible in MS Project?), and will show the programme critical path (and most importantly, slippage of key activities) – am I wrong? Or is there a better approach?
Secondly, there is no appreciation of dependencies between individual projects so it is impossible to see at a programme level, dependencies and interdependencies. What is the best way of mapping these? Don’t want to create something that looks too complex or they will freak out. They keep saying they want everything simple, simple, simple. Has anyone got any good examples of dependency mapping good practice at a programme level or at least point me in the right direction?
Anyway, back to work tomorrow and getting anxious. Any help/advice would be much appreciated.
Saving Changes...
Sort By:
Anonymous
Mark, it sounds like you've identified many of the most important things needed to get a handle on your program (forgive the US. spelling) but want to get into the details of each project quickly. What I would do is treat all of the projects in your program (& other things if they exist) as deliverables of a larger project (the program) and determine their linkage to the program (dependencies). Once this is done (or as close as you can get), each project can be treated as a work package with its individual major parts that need to be completed to complete the work package. If you make it look like a project, you can do all of this in MS Project. My concern would be trying to get into the details of each project before having a good understanding of them as the "program."
Best of luck! Saving Changes...
Imran ManirSenior Project ManagerBurton On Trent, United Kingdom
Hi Mark, building on the approach that the change programme is treated as a project, as well as developing a programme plan with each project identified as a work package, you may also consider programme level risk and issue logs which provide visibility of high impact high/medium probability risks and high/medium impact issues. If project risks and issues are currently captured centrally then perhaps you can schedule a weekly extract - if not, then your "team leads" i.e. project managers need to forward these to you weekly. You will then have a single programme schedule, a single programme risk and issue log. In terms of financial/budgetary/schedule control, you could use EVA to analyse if the overall programme will deliver as planned in terms of time (schedule) and cost (budget). From the sounds of it, there is a wider need for training in project planning and scheduling at project management level - perhaps as PMO manager this could be one of your recommendations? Saving Changes...
Imran ManirSenior Project ManagerBurton On Trent, United Kingdom
BTW - MS Project will allow you to create a view to display only the critical path - this is one of the filters. Saving Changes...
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
Mark,
One fairly simple addition you can make is to get the PM's to include a new colum in their MSP PLan (e.g. Text 10) and customise the settings for the field to have a drop down for Programme/Program tasks (they can also include others like, Development, test etc for other stakeholders) .
You can then agree with the PM which tasks / milestones etc are critical to be tracked throughout the project and then you as the programme / PMO manager can then go into each msp/mpp file and filter that column on Programme only giving you a view of the tasks you need.
Next step you can link these then to your overall programme msp/mpp file using these tasks. Once all set up I would ensure you take a basleine 1 view of the programm/portfolio so you can track dates to see if there are any changes occurred over the days/weeks you monitor the programme.
For programme level you could include summary tasks from the project files, but if you link these in project you may get all of the sub-tasks listed in your programme plan so ensure you have the filter on in your plan also.
Saving Changes...
James DobsonOperations Manager| Synapsys NZChristchurch, New Zealand
Hi Mark,
Firstly, congrats on your new role (I think!)
In my experience the best thing you could do in your first month or so on the job is to identify the top risks across all projects and look for common mitigations
One of the key value adds of the PMO is the 'helicopter view' across all Project activities. If you can ideantify and work with the PM's on the mitigations for key risks across all projects you will be adding tangible (and timely) value
Good luck! Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
One of the things that has worked for me with managing dependencies is to identify the major ones for each project and then categorise them as upstream or downstream. In other words, am I dependent on someone else, or is someone else dependent on me? If you asked the project managers to identify two or three major dependencies for each project you could look at how they link together, and it would be very interesting to see if someone identifies a dependency from another project that that project's PM hasn't identified.
Good luck with writing it all down though. A list is what we used, because drawing it graphically took up too much space. Saving Changes...
