MS Project Best Practices for Very Large Projects

Question

I am looking for Best Practices for MS Project (2007, not Server baseed) for very large projects.  I have reviewed PMI's Practice Standard for Scheduling, but it was of limited use and I have not yet found a creditable document.

Our current multi-year project schedule was developed by the consultant we hired and does not follow many of our companie's scheduling best practices.  Their schedule consists of 24 sub-projects combined into one project weekly (by 20 team leads), which results in over 26,000 tasks.  There are approximately 175 FTE on the project.  The consultant is responsible for the project schedule. 

Our goal is to find generally accepted (or industry - IT) best practices for large projects, which will provide us addtional credibility to get the consultant to make changes in how they develop and update the project schedule.  There current scheduling process has not met our needs and been one factor in many missed milestones.  One person's best practices may not provide much creditability, even though the person is an expert in MS Project and the practices are very, very good.

Topics in question, include but are not limited to:  the best method to progress (update) the schedule, duration vs work hours based,  individual vs group resources, resource leveling or not, how to best create and update a very large schedule, should actual hours and remaining hours be recorded per task, the best report reports/charts/graphs, how to obtain a high level senior management data/critical path, fixed date constraints, lead/lags, rolling wave or not, etc.  The list is endless.

Thanks!

Answer 1

THe Dog -

Where to begin..

Generally you are not going to find scheduling standards for "small projects" and "large Projects"... all you will find are best practices or standards that relate to most schedules.  You mentioned the PMI Scheduling Standard.  Keep your eyes open as a new version is hitting the streets for "Exposure" review before the end of the year (I am not allowed to disclose the exact date, but I'd say keep your eyes open on the PMI website). I am on the team that is writing the new version along with 7 of peers from around the world.  The approach used by PMI (and many others) is "Most Projects Most of the Time" when they address "best practices."  The level of rigor applied is only somewhat related to size and complexity.  Don't confuse rigor with size.

In particular, I'd go back to the Version 1 of the PMI standard, and also contact the PMI "College of Scheduling". In the PMI standard, I would look at the conformance index items, particaullarly Chapters 4 and 5.  I work as a consultant in Project Management (Aerospace and HighTech) so my comments are going to be a bit slanted but here goes.  I would suggest breaking the schedule into Master and Subprojects for each team lead.  Use Physical%Complete as your earned value method, place costed resources in the schedule and have a baseline.  Save interim plans frequently.  Update weekly.  Never allow "unfinished work behind you" and also avoid "future actuals" ... you cannot claim anything other than 0% complete on a task unless it has an Actual Start no later than the data date.  Also, if the task was scheduled to finish "yesterday" then it better be 100% complete or you need a revised finsh date (in the form of remaining duration/work). Resource leveling is probably not worth it, but it is a best practice -- it does help but wakes up all sorts of gremlins. 

Your best friends are [Actual Start], [Actual Finish], [Actual Work], [Remaining Work], [Remaining Duration]. If your consultant keys a date into [Start] or [Finish] jump all over him as it creates artificial constraints.  Manage Total Slack and Free Float.  Watch your Schedule Performance Index light a hawk.  Date Constraints should not overly constrain the schedule and should only be applied if logic cannot get you the answer.

If you are going to use Resource Leveling, use individual names, not groups. Other than that, it is a personal choice.  We use names, not groups.

Unless you are using Proejct Server, recording actuals against discrete tasks is going to slow you down and annoy your team.  Take time card information at the work package (or summary task) levels and use that for actuals.  You can have a single task for each Charge Number (or what ever you call it) that contains only actual costs.  You can use that for the Actual Costs and then use the other tasks in the work packages  for collecting "anticipated spends" (that is called Planned Value or Budgeted Cost of Work Scheduled) and Earned Value (sometimes called Budgeted Cost of Work Performed) --- you get that by using Physical%Complete, having costed resourses, and a real baseline.

Establish a system of Givers and Recievers for hand offs of work between files.  Hold those Givers/Recieves under configuration control and keep them as milestones near the top of the file.  Make sure no one violates a Giver/Receiver date without management permission.  It will help you track who is really driving who.  I've seen where "Joe" was taken to task for being late when in reality he was executing per his schedule durations but was getting his inputs late from "Carl".

Best reports/charts?  We use the standard Earned Value charts from Project and export to Excel.  In addition, we use a product called Kidasa Milestones Professional to make "Eye Candy" for the executives.  That is perhaps the easiest way to make summary charts, etc.

Although my peers will disagree --- use of "Leads" is cause for trouble and typically indicates lack of sufficeint detail planning.  I will agree sometimes it is "the easiest way" to get the point understood. Personally, I only implement "Leads" with a sneer and a lot of grumbling.  But, they are common, and yes I have used them.  Fixed Date constraints such as "Must Start On" or "Finish No Later Than" ... oh, no ... run from those.  Consider using Deadline Dates and monitor Total Slack.

I have a couple of papes on my blog.  You may find two areas of interst: (1) What %Complete Should I be? , and (2) Predecessor and Successor Relationships.

Make sure you have the ability to group your project by various phases, etc.  That means you will need various numbering schemes in the schedule for sorting.  On that is highly recommended is something called "Integrated Master Plan/Integrated Master Schedule (IMP/IMS)"  It deals with Program Events, Significan Accomplishments, and Accomplishment Criteria.  It is imposed on US Government Defense contracts for the past several years.  It is tight, and seems to work OK for reporting towards events.

Rolling Wave.  That will probably be a necessessity.  We require detail plans for 90 days, planning packages after that.  That assumes Weekly status.  Use of Rolling Wave creates its own set of problems as it essentially sends the critical path through "summary tasks" and plays havoc with baselines and resource leveling.

What else, off the top of the gray hairs on my head... all tasks shall have a predecessor and successor, no logic or resources on summaries... tasks should be about the same duration (and usually not more than two reporting periods). 

You may want to visit my website and see if you can gather anything else.  You will also find my contact information there.

---

If this post was helpful, please click on something :) I am also at http://www.msprojectblog.com Jim

Answer 2

Jim --

I have started using your suggested approach and can see how it will really help, particularly with giving the sub-project team leads the insight they need without them having to dig it out of a large, complex, and unmaintainable overall program plan.

My one concern is about critical path analysis. Since the only things coming up to my top-level Project file are milestones and no dependency relationships, there won't be a place to see the critical path all in one place. My assumption is that I will probably be able to infer the critical path from the structure of the milestones and then go dig into the offending sub-project file(s). Is that a good assumption?

Thanks,

-- Gary

Answer 3

Hi,

Firstly I would ignore most of the PMI best practices. They appear to have majored in jargon!@@# I have scheduled refinery upgrades with MS Project and the best practices are basically what supports the business needs of the proejct manager and the contractors? Anything else is fluff.

So progress. Save a baseline each week before updating (use same one each week) then update. After update, there should be no incomplete work in the past and no incomplete work in the future. Compare current dates to teh baseline for that week to see if ahead or behind schedule.

Duration vs work hours can only be answered based on the scheduling maturity of the project. If contractors can't/won't provide work then you will have to work with duration and guesstimate number of FTE required. Predicting and tracking work is more accurate.

Group Resources shouldn't be used, but welding gangs or any team that only does anything as one unti should be treated as a resource.

Best chart reports etc must be totally driven by business needs. For teh refinery project critical path was King, so I generated critical path reports in Excel (total slack for each vessel, key area etc trended in excel.) Every proejct will differ. I also found that reporting needs changed over life of each phase and teh project itself, so custom reporting skills essential.

No fixed date constraints expcept to delay work to next week or for genuine constraints that should be grouped under Constraints summary tasks and notes explaining constraint.

Yes teh list is endless, but get all teh schedulers together weekly for per reviews, reporting ideas, ways to automate and simplify and more. I managed to remove 2,000 tasks just by moving pipe fabrication to Excel trackers. There are no best practices here, employ the best, and provide business guidance on what's top priority, what are key success factors and KPI's etc and evolve your schedules.

Answer 4

I retired a few years ago after 15 years as an MS Project consultant, so was interested when I stumbled across this topic whilst I was trying to solve a file acccess problem.  I found Jim Aksel's ideas very close to how I used to manage situations like this. I just wish that I could have stated them with such clarity.

Answer 5

The Dog,

My first observation is that you either hired the wrong consultant or you did not sit down and discuss your corporate needs with him/her in the beginning. I don't do Project Server myself but based on your description I wonder if it might be something you need to consider, particularly if multiple team leads are updating files. You might want to post to our server forum at, http://social.technet.microsoft.com/Forums/en-US/projectserver2010general.

Trying to come up with a comprehensive list of best practices is probably out-of-scope in this forum. Your company like most has some very specific requirements. Since you already have a consultant, the best thing you can do right now is to sit down with your consultant and all the appropriate people in your company and lay out a plan for your needs. If the consultant doesn't want to do that, then fire him/her immediately. However, if the consultant is worth his/her salt, they will be more than happy to lend their expertise about what Project can and cannot do and how that will dovetail with your requirements.

If you find you need a new consultant, we can help with that.

John