Hi there! If you’re a project manager, do you have a set of “project management fundamentals” that you abide by? All good project managers have this fundamental body of knowledge.
Some pick it up through formal training courses (e.g. the PMP certification), others through their own learning and reading. Some project managers also accumulate their base body of knowledge through on-the-job training.
To help put some context into what “project management fundamentals” are, I’ll give you an overview in this article.
You can delve into much deeper levels of detail by browsing my website.
There are five “official” process groups according to the PMI Project Management Body of Knowledge (PMBOK), as shown in the diagram below.
The five official project management process groups
The “Initiate” process group relates to activities which define and authorize a new project. Before a project starts, you must make sure these activities are done as they are critically important start-up items. I’ve seen many a project fail because the initial activities of securing stakeholder support, understanding high-level project scope and so forth – were totally missed out.
What activities does it cover?
The “Initiate” process group requires that the project manager do the following activities:
Define preliminary project schedule, estimate cost and risk
Always, always make sure you define the preliminary project schedule. Then estimate the cost of doing the project and any risk factors you foresee.
I know some hard-nosed project managers sometimes skip this step, preferring to head straight into execution – DON’T DO IT. Take out that Statement of Work or work contract that you have, pick out the high-level timeframes, scope and cost and work out an initial schedule, cost estimate and risk factors. It will give you a solid view of what “what success looks like” for the project.
Develop project charter
You may have heard in project management circles an important document called the “project charter”. What is a project charter? I define it as follows:
Definition: A project charter is a “high-level project map”, a statement of a project’s objectives, scope, stakeholders and their roles and responsibilities.
It is a critically important document that you need to print and keep handy at all times during a project. I’ve been in projects (e.g. large core banking system implementations that can take two years or more) and people forget.
People forget why we’re doing this. People forget for whom we’re doing this. People resign, new comers join the project. And the project charter is THE document that will give continuity to a project’s overall vision and purpose. So keep it handy!
Case Study: I was the project manager for delivering a large-scale banking system for a private bank.
Banking systems are notoriously complex because you have to deal with functionalities like client account opening, product maintenance, credit monitoring, trade processing across all asset classes, reconciliations, payments, corporate actions and a whole lot of “other jazz”. I was the project manager (in a consulting company) overseeing the banking software vendor (our sub-contractor) and also the client (the bank).
Here’s what happened – the project began in 2009 and after we rolled out an initial phase of the system in 2010, the project sponsor in the bank quit. His successor joined in January 2011 and he too quit the bank. Another successor came along in April 2011 and was totally clueless what the project was about.
The unfortunate thing was that we never spent time documenting a solid project charter. Everyone was lost – my team of consultants, the vendor, the bank, and heck, even myself. Can you imagine the mess that project got into? The project was eventually called off by the bank.
So big lesson learnt – always document a project charter and get it signed off at the HIGHEST level of management.
Ok, project resources are very important for project delivery. We all know that. But very often, we ignore good resource management and think of it as an “optional extra”. Don’t fall into this trap!
Part of the “Initiate” process group is to get your resource plan ready. Find out who can do the specific tasks in your project. Do they have the required attitude, experience and capability? Communicate early to the managers of those resources when and for how long they will be involved in your project. Give them a good heads up on what they’re expected to do and what they can stand to gain if they participate.
Alrighty, then – onward to the “Plan” process group. This process group refers to activities which define and develop the project plan and establishes the project baseline.
A project plan is fundamental to any project. Some people do it in Excel, others use Microsoft Project, and still others use a piece of paper (erm – not recommended for large projects).
Whatever tool is used, you MUST have a project plan. It defines what activities are required to complete the project and when each task is expected to be done and by whom. It spells out dependencies between tasks and other projects and lets everyone see the “project path” at any time.
What does activities does it cover?
The “Plan” process group requires that the project manager do the following activities:
Define detailed project schedule, estimate cost and risk
We’ve worked out a high-level initial schedule, cost estimate and risk factors. Now is the time to bring these into a deeper level of detail and flesh out the components. Develop a detailed project plan. Work out the precise cost figures. And there can be a LOT of costs in a project (resources, hardware, software, expenses, transportation, accommodation, meals, IT expenses, etc.). You also have to deal with project profitability and resource utilization (especially if you’re in a vendor environment like me).
Develop project management plan (PMP)
Here’s where you typically whip out Microsoft Project and start working out your detailed Work Breakdown Structure (WBS) and assign tasks their duration, dependencies and project resources.
Tip: Microsoft Project is a great piece of project management software and I thank the folks at Redmond for it. But I’m not a fan of “over cooking” my project plans. I don’t play with complex resource graphs, program scripts into Microsoft Project to automate monitoring of tasks.
I’m more of a “semi-automation” fan. I enter my basic project plan into Microsoft Project, put in the tasks, durations and resources, along with their dependencies. Every few days I go into the plan, switch to Gantt tracking mode and monitor each task’s progress in percentage terms. That’s all. I don’t think we should “over cook” Microsoft Project plans. I feel you MUST have some human intervention in the software and not try to automate everything.
But a Microsoft Project plan is only one part of the overall “project management plan” or PMP. The PMP should comprise of the following in totality:
- Project management approach
- Project Work Breakdown Structure (WBS)
- Activity List
- Stakeholder register
- RAID – risk, assumptions, issues and dependencies
- Project estimates
- A Milestone List
- A Project Schedule (usually a simplified version of the overall project plan)
- Project roles and responsibilities
- Project budget
- Project resource plan
- Project communications plan
- Project work products or deliverables
Tip: It is important to sign-off your project management plan or PMP. Once it is baselined, it can only be altered when a Project Change Request is approved. All things in the project can be referenced back to the PMP in one way or another. It is a very useful tool for documenting and publishing project expectations and understanding. Learn to make use of it. When I first started in project management, I didn’t put much effort into this document, thinking it is just “documentation”. This is NOT true. Take that PMP with you everywhere and use it as a tool to communicate with all stakeholders!
We’ve talked about pre-empting project resources and letting them (and their bosses) know they’re going to join the project. At this stage, you actually “onboard” them into the project, brief them in-person on what they’re required to do. You listen to them and hear their concerns, sign on resource procurement forms and do the administrative tasks of transferring them into your project team.
With the “Plan” phase over, the next process group, “Execute” is where we integrate resources to deliver against the project plan.
Easier said than done! The execution phase of a project is definitely the most challenging – for large projects, we’re talking about YEARS of execution effort.
Think of building a new oil rig. Or building a stadium for the Olympics. Or rolling out a banking system for a bank across its branches and subsidiaries all over the world. Or creating a new, groundbreaking smartphone.
These things take years! Or at best, many months. You need a system, clear methodologies for making sure EVERY step of your project plan is run according to schedule. If anything is about to slip, you want to know about it early and mitigate the risk. If sometime has already slipped, you want to assess the impact to your project plan and see how you can recover.
What does activities does it entail?
The “Execute” process group requires that the project manager do the following activities:
Once you’ve done project planning and secured your resources, you should conduct a “project kick-off” when the project start date arrives. A project kick-off is not a mere formality where stakeholders and project team members get together to laugh, smile and “be nice”. It’s an important opportunity for project sponsors (and the project manager) to brief everyone on what the project is about.
More importantly, you get a chance to educate everyone on how the project can deliver its outcomes successfully and what each project participant’s roles and responsibilities are.
Once the project proper starts, you may never get a chance to address such a large group of project stakeholders face-to-face (or at least until the first major project status update meeting, which could be many weeks away). So make full use of the “kick-off” meeting and get all your high-level project messages across.
Perform project work
Ok, “perform project work” is just three words. It doesn’t do justice to the sheer amount of work activities under it!
At a broad level, when we talk about performing a particular project work activity, here’s what’s involved:
- The project team member reviews the work product(s) that he or she has to produce and any assigned activities in the project.
- The project team member performs the tasks in support of the assigned activities.
- The project team member reports to the project manager on progress against work assignments (hours worked this week, remaining hours to complete tasks). He or she communicates any issues and requests for change.
- Conduct a quality review of the project work product. If it is not approved, the project team re-works the work product. If it is approved, the project manager officially gets a sign-off on the project work product.
As you can imagine, there are usually tens, hundreds or thousands of tasks that will be performed over the course of a project. So the above “execution” steps need to be monitored closely by the project manager at all times. Which is the topic of the next section …
Monitor and Control
While a project is being executed, you, as the all-seeing project manager, will need to close monitor and control all work activities. This is the “meat” and also the tough part of project management. But take it as a challenge and understand this – if you can monitor and control a project properly, your chances of success are very high indeed.
What does activities does it cover?
The “Monitor and Control” process group requires that the project manager do the following activities:
Users and stakeholders change their minds over time. This causes project requirements to change over time. This is called “scope creep” in the industry and is the bane of all projects. If there is an increase of scope and you have the same amount of time and resources, your chances of successful delivery decreases. You MUST manage scope very judiciously during a project.
You know those task durations you assigned in your project plan? They are for real! Make sure your project team sticks to those deadlines.
At times, you may have team members who slip on timelines and don’t complete their work on time. It is your responsibility as a project manager to get them back on track. In fact, if you’re a really good PM, you would caught them before they slipped so that you could install mitigation steps to recover.
Watch over your project costs very carefully. In the consulting company I work for, the time that your project team members spend on the project are typically “clocked” to the project’s “job code”. If your project overruns, you will need more time than budgeted to be clocked into your project so as to finish the job. This represents a “loss” to the project and it’s something you need to avoid at all costs. In serious cases, you’re looking at a project profitability write-down which is, erm, to put it simply, not a nice experience to go through.
You, as the all-seeing PM, also needs to look out to the “horizon”. Be the captain of the ship and steer your vessel carefully. If you spot any upcoming obstacles or potential problems, make sure you put in plans to mitigate risk.
Looking out to the “horizon” may not always be easy. When you’re caught up with the details in a project, it’s tough to lift your head up and scan what’s coming up. For me, I like to schedule “timeouts” for myself. I find a regular time when I can lock myself up in a room, away from distractions, so I can focus on looking ahead and watching out for upcoming project deadlines and associated risks.
All projects have issues. The trick for a project manager is to stay on top of them. Not all issues will be resolved by the end of the project – and that’s ok. The important thing is to secure “buy-in” and make sure every stakeholder agrees that the issue is addressed or not addressed.
Project issues are usually management in a central repository (e.g. a project issue log, a project database). As a project manager, you should make sure these templates or project tools are ready for use before the project starts.
Manage stakeholders and project team
Your job as a PM also involves managing stakeholders and the project team. It’s about managing peoples’ expectations. Over-communicate to your stakeholders and team members. Keep them updated and make sure they know what’s going on.
There are a few other “Monitor and Control” activities, e.g. reporting project performance, perform project change control and conducting “project phase gate”. You’ll also find more content on these topics within the pages of my website.
When all project activities are complete and your work products or deliverables have been signed off, it’s time to celebrate! But wait … there are some project “close” activities that you need to perform.
What does activities does it cover?
The “Close” process group requires that the project manager do the following activities:
Perform administrative closure
There are lots of “admin” type of work related to project closure. For me, the most important administrative activities are:
- To perform an analysis of actual project progress against the agreed PMP and project baseline.
- Prepare a project closure document (e.g. handover instructions).
- Prepare, review and approve a “lessons learnt” log.
- Close out your project charge codes or project IDs.
Release project resources
The last step for a project is to release your project resources. Let their managers know they have completed the project, give them appropriate feedback on their performance. Oh, and before everyone departs your project, buy them dinner or celebrate with drinks!
For me, I like to take each of my team members out to lunch individually and thank them for their contributions. Your team members make all the difference between success and failure and it pays to show appreciation for their efforts. Who knows, somewhere later in your career, you may be working with (or reporting to) one of your team members too!
Wrapping Up …
And that’s it! A pretty long description of project management fundamentals. Always bear in mind the basic PMBOK process groups – Initiate, Plan, Execute, Monitor and Control and Close.
Now, all the articles I write in this website will link back to one of these process groups. Keep these fundamentals in mind the next time you’re starting a project – and your chances of success will definitely increase! If you’ve any questions on these project management fundamentals, do feel free to contact me. I’ll be happy to trade techniques (and war stories!) with you.