There are likely as many different ways to put together a project schedule, than there are Project Managers that manage them. The same can be said, for project plans. This is the point in the article whereby many are asking the question – ‘aren’t they the same thing?’. Some organizations and project managers interchange the two routinely, which can lead to some confusion for everyone. Within the 4th Edition of the PMBOK® Guide, there are clearly identified processes for the development of the project schedule and is described as follows:
“[1]Develop schedule is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule.”
Which brings us back to the question at hand – then what is the Project Plan? When asked for a copy of the project plan, many PM’s will deliver the project schedule. The ‘context’ of the request, must be clearly understood, so that the PM does not find them self in an uncomfortable position. Therefore, it is important to understand what constitutes a Project Plan.
Back in the 90’s, there was a company (LBMS) that created a set of process and project management tools that at the time were based upon best practices of many of the leading technology companies in the world. Fortunately, I was part of a team that was primarily responsible for selecting and implementing such a toolset within our company (Sabre Travel – which is now the Sabre Holdings Group). After an exhaustive search, and much discussion, the LBMS toolset was chosen and we started the process of developing an implementation plan, and the customization of processes that would be needed.
As part of that effort, a key primary deliverable that was included in the overall LBMS Project Management Process was the development and approval of a ‘Project Plan‘. This was in addition to the development and approval of the ‘Project Schedule‘. In short, the Project Planning document was based upon a standard template document, which contained the details on how the project would be managed. It defined the project organization, authority levels, key resource definitions (not individuals but rather roles and responsibilities), and many other items. It was a document, when completed, that any member of the project team or sponsoring organization could read and understand how the project was being managed.
In many organizations today, that type of document has been replaced by many other individual documents, which contain much of the same type of information. If you look at the PMBOK® Guide, you will find a specific deliverable and process for the development of a Project Management Plan, defined as follows:
[2]Project Management Plan [Output/Input]. A formal, approved document that defines how the project is executed, monitored, and controlled. It may be a summary or detailed and may be composed of one or more subsidiary management plans and other planning documents.
There are different approaches and deliverables which can be used, the key being that each Company, Department or Project Team likely will need to produce deliverables that fit their own situation. The overall maturity of your organization in regards to process development and usage, will determine whether you have one Project Management Plan, or whether you have many deliverables that comprise the overall Project Management Plan.
The importance is that whether you produce one ‘Project Plan Document’ (or Project Management Plan) that encompasses all of the different knowledge areas, or produce a number of documents, it is critically important to understand how the project will be managed. If you cannot show how the project is being managed, it is likely that many of your team members and the business units or groups that are dependent upon the overall project success, will have difficulty executing within the Project Organization, or following the progress and updates throughout the project lifecycle.
Lastly, if you find yourself in a situation where a project sponsor or C-Level Executive wants a detailed walk through of the ‘Project Plan’, they likely want a review of the Project Schedule. If there is any question at all, which is being asked for – make sure you get clear direction before preparing your presentation. It is not a very comfortable position to be in, explaining one document or set of documents, when another one was really being asked about.
[1] ©Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
[2] ©Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
{ 12 comments… read them below or add one }
I strongly agree with the above, project plans differs from Project schedule.
Project schedule puts up the time frame of the project in a logical manner along with the resources required to execute the tasks, this schedule is loaded with the cost of each activity forming a strong baseline for any project in terms of the duration required as well as the budget thus the cash flow expenditures. The project schedule is then updated on a biweekly or monthly basis; applying the actual dates, resources and the actual cost encountered thus producing the As-planned VS As-built schedule and the earned value analysis that shows whether we are falling ahead or behind schedule, over or under budget, thus producing the SPI “Schedule performance index” and CPI “Cost performance index” that have big weight in the overall project KPIs “Key Performance Indicators”.
We used to call the project management plan as PEP “Project Execution Plan” serving the same purpose, it`s a live document that is updated every quarter to accommodate any changes that have happened. It is a vital document that any Business plan can’t be submitted without.
Good stuff, John! In my experience, these terms are defined by a given organization within their methodology. In fact, the very term “methodology” has surfaced with different definitions on occasion! So – while there MAY be something like an ‘industry norm’ or a generally accepted definition for many (most?) vocabulary associated with project management, the REAL key is to get plugged in with your specific company / division / department definitions for these.
Hi John,
If you look at the project plan from a contractors perspective, you can see that the project plan is not only a formal approved docuent, but a LEGAL (contractual) requirement as well. (Reference CSI’s Manual of Practice, plus AIA and EJCDC standard documents)
But that aside, I would urge you to invest the time and effort to move beyond PMI, which IMPO, offers an overly simplistic and immature perspective on project planning and scheduling, and explore the much more technically robust, but poorly marketed content developed by AACE. (See AACE’s Certified Planning and Scheduling Professional (PSP) credential- http://www.aacei.org/certification/PSP/welcome.shtml)
Why do I prefer or recommend AACE over PMI? There are three major differences between AACE and PMI. First, what AACE urges us to adopt are “best” or at very least “recommended” practices, not “those used on most projects, most of the time”,
Secondly, AACE takes a much more in depth look at the technical aspects of project management- MUCH deeper than PMI. While PMI seems focused on vocabulary and a few formulae, AACE focuses much more on the underlying calculations and technical aspects of project management. Less theory and more application.
Lastly, while PMI charges for everything, AACE has made the the AACE Body of Knowledge- The TCMF- Integrated Portfolio, Program and Project Management Methodology http://www.aacei.org/tcm/ and their Recommended Practices (RP’s) http://www.aacei.org/technical/rp.shtml available on line AT NO COST.
Hope this will help people understand the nuances between planning and scheduling more completely.
BR,
Dr. PDG, from LA
http://www.getpmcertified.com
Dr. Giammalvo,
While I appreciate your comments, just because an organization ‘charges’ for their membership, access and publications, does not mean that everyone should just leave and go to some other organization that performs something similar for no additional cost. It also does not mean that the ‘no cost’ organization is wrong, or doing things badly.
Not having any knowledge or experience with AACE, I certainly would not want to cast any stones their way. However, throwing rocks at PMI and the work they do, is not at all what I would consider ‘good practice’. However, I approved your comments for publication without editing, for a different perspective should be available for all.
Best Regards.
The project schedule is just one component of the Project (Management) Plan. Without the other information (i.e. scope, risks, constraints, etc.) about the project, the project can usually not be managed effectively.
The Project Management Plan should be the “parent” document, from which a schedule, risk management plan, and other key documents / deliverables are generated. The Project plan captures the (initial) basis and expectations for the project, while the other documents should be kept “ever-green” and revisited during the life of the project.
While project success is in no way guaranteed by having this document being agreed to by the stakeholders, it does put it in a better position to do so. The Project Plan should be scaled to the project, be understandable by the stakeholders, and if possible signed-off prior to the project being worked on in earnest.
Hi all,
In my opinion, the “project schedule” is the document which shows the activities of the project, their calendar durations, their relationships and the start and end dates of the project. As long as activities durations are included as an input of the “project schedule”, resource estimations (or the resource plan) should also be included in the “project schedule”.
Assuming previous definition of the “project schedule” as a valid one, the “project plan” would have a wider meaning. It would include, not only the “project schedule”, but also the final versions of the plans for resources, costs, quality, communications, risks or procurement. In addition to this list, the “project plan” should also include the definition of the process of how the project will be monitored and controlled,
Best regards.
Is it not quite simple – the schedule generally covers “what”, “who”, “where” and “when”.
The plan additionally covers the “why” and the “how”.
The schedule is normally part of the plan, but certainly not the only part.
Another way of looking at it is that the schedule is more about project logistics and the plan is wider and includes principles, accountabilities and approaches.
My favorite story around a schedule versus a plan:
A project manager was assigned a simple enhancement project that would take about 4 weeks to complete with 4 part-time resources. Off he went to finish his planning and returned 2 days later with a project calendar. He announced to his boss he was done with planning.
The boss gently pushed back with questions like “How will you manage communication with the sponsor? Did you document and get agreement with the sponsor on communications?” His response to his manager’s questions was “But I have a task for that”. His manager replied, “Yes you have a task, but not an agreed upon process. You haven’t told me how you will communicate or gained agreement with the sponsor on how they wish to be communicated.” We agreed to defining processes and documenting them in the project plan.
The project manager returned proudly with a 10,000+ line project schedule that included daily and hourly tasks like “check for new risks”, “communicate via email with sponsor on status”, “update issue log”, etc. Virtually every little detail was a task on that schedule – I half expected to find a task for taking lunch and bathroom breaks. The project manager renamed is project schedule as project plan.
After another coaching session the manager explained the amount of work to keep that schedule up to date was insane (posting actual hours against all those tasks would have taken months to finish even for this small 4 week project). We created a separate document for the processes the project would follow for communication, status, time reporting, change management, etc. We pulled these processes from a standard set used by other project managers in the PMO.
The project manager’s sponsor and team were very impressed by his organization and were happy they could actually understand the project schedule / milestones. His sponsor got the difference between a plan and schedule. The project schedule was reduced from almost 50 pages to 5 pages. The project plan was 8 pages. The project completed within 5% of the approved schedule and budget.
And yes, this project manager learned a valuable lesson about planning. A project schedule is just the start of planning and certainly not the final destination. That processes used to manage a project can be reused but are always unique to the project depending on the projects size and complexity.
The Project Plan and the Project Schedule are two different things. The project plan contains the goals, objectives, resources, high level business requirements, stakeholders, etc.The project schedule is the set of tasks required and the resource assigned to those tasks with due dates, costs, etc.
Sometimes you literally need to do a little “show and tell” so that your customers can ’see’ the difference between the plan and schedule. Every project I have ever had I had to show them the difference because people would say Plan when then meant Schedule and thought the schedule was the plan. A lot of times they would joke about it but really they are two different things physically and conceptually.
All – for those that have access to LinkedIn, and the PMLINK Group, this discussion is being carried there and is marked as a ‘Featured Topic’. Below is the link:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=5320759&gid=35313&commentID=5650071&trk=view_disc
John, I think you explained it well: “The ‘context’ of the request, must be clearly understood”. One may simply be asking for the schedule when requesting for the project plan. It is the wrong terminology.
If I was asked for the project schedule, I would know what to deliver. If I was asked for the project plan, depending upon the context, the subject discussed, the requester, I would seek confirmation and ask if indeed it is the project plan that he/she wants to see or if she/he would rather see the schedule.
I agree with the above remarks and would add that you do not have a complete project plan without a completed schedule. Can one go without the other one? One impact the other and vice-versa.