What you may not know is that there is some basic project management knowledge and terminology that is very useful when working with other certified Project Management Professionals. Having some basic project management knowledge is worth it. It might even help you become better organized and lead you to yet another promotion.
Basic Blocking and Tackling
Let’s cover some basic blocking and tackling of project management. If you read my last post, Winning Takes Care of Everything, you know I am not a fan of process for process sake. I do, however, believe in the necessity for project frameworks and understand there are a few key elements (tools, processes, techniques) that project managers must leverage to repeatedly deliver successful projects.
Specifically, I want to cover the Work Breakdown Structure, the Project Schedule, and the Project Plan. Many project managers use these incorrectly and interchangeably when they should not.
Work Breakdown Structure
Every project has a few core requirements. They are usually expressed as high-level deliverables. The work breakdown structure is a process—an actual form or document—in which the project managers, subject matter experts, and the team break large deliverables into smaller chunks or tasks. This can be somewhat compared to a sprint in the Agile world. Breaking large deliverables into smaller, more addressable parts allows project managers to better organize efforts, align resources more effectively and track progress with greater precision. A lot of project managers skip this because they believe it is tedious and don’t want to feel they are micromanaging. You must fight that impulse and realize it is tremendously effective for developing an accurate project schedule.
As an output of the work breakdown structure, your team must be able to identify the resources required, dependencies in-place and time needed to complete each task. With this information, the project manager can develop a project schedule the team can review and support.
Your project schedule is basically the list of tasks with a start and end dates, assigned to team members, and any respective dependencies.
A key point to remember is that the project schedule is a living document; it must be reviewed and updated throughout the project. A dependency may get removed, allowing other tasks to start sooner or some team members may become ill, pushing their task finish dates further out. Even with the best planning and collaboration, things happen. Make sure your project schedule reflects the actual and current reality of the project.
The project plan can be likened to an operations manual which describes the execution, management and control of each project aspect. Often confused with the project schedule, the PMBOK Guides and Standards definition of a project plan is,
…a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines.
Here are a few elements a project plan should include:
- Requirements Management
- Schedule Management
- Financial Management
- Communications Management
- Change Management
- Quality Management
- Procurement Management
Have managers or teams document procedures for their respective areas. Examples might include requesting changes, how funds are approved or released, and how project updates get communicated. Ultimately, should you need to leave, a new project manager ought to be able to read the project plan and pick up where you left.
Learn Project Management Basics
In many offices no one will notice or care if you call the project schedule a project plan. But, as your organization grows or depending on whom you work with, such as formally trained project managers, such gaffes may create confusion. If you work with certified project managers or PMBOK followers, it might even cost you some professional credibility. Learn these basic items and get them down. Leverage them on every project. Think of it as grammar for project management. It may not always seem important, but when you get called on an error it may feel rather awkward.