Today I’m doing something a bit different in that I’m simultaneously releasing the blog and a new video.
It’s a beast of a video and as the title suggests it’s a beginner’s guide to project management.
What is a project?
Project management is everywhere! From someone building their own home to a country putting on large high profile events like the World Cup they’re all using project management techniques in one form or another.
I’m not going to bore you with an in depth history of project management, but it’s good to know where the discipline began.
Although project management has been around since ancient times, arguably the biggest influencer was Henry Gantt. The inventor of the famous and still used – GANTT chart. He created his namesake charts around 1910 and they’ve been used in projects large and small ever since. Modern project management came out of the 1950s post 2nd world war defence and aerospace industries.
The first thing to get your head around is what a project actually is. There are loads of great definitions out there. In a nutshell a project is something you do once to solve a particular problem. At this point the more experienced PMs among you will be laughing your heads off! Everyone who has ever been involved in projects has at least 1 example of a project that has been done over and over again and still failed to achieve what it set out to do.
Once you know what a project IS, it becomes much easier to identify what a project isn’t. For example, building and testing a new machine is a project but manufacturing 1000s of them is not and would be classed as business as usual.
You really do need to understand the difference because projects are tricky beasts. Simply because they fall outside normal business operations and the normal rules don’t apply.
Projects are managed using frameworks and methodologies. You might have heard of PRINCE2, PMBoK and Agile. PMBoK is a project framework and PRINCE2 and Agile are methodologies.
The PMStackexchange has a great explanation of the difference between frameworks and methodologies. They describe it as “A framework is a loose but incomplete structure which leaves room for other practices and tools to be included but provides much of the process required. A methodology is set of principles, tools and practices which can be used to guide processes to achieve a particular goal.”
Projects also have defined lifecycles – usually something like define, plan, execute and close out.
How to define a project
So what do you do if you’ve been given the job of delivering a project and you don’t know where to start?
Don’t panic! That’s easier said than done but taking a deep breath and slowing down will help you in the long run.
I remember the very first project I was given to run. I hadn’t even been in the workforce very long and I was given the job of putting in a new piece of equipment. Talk about panic! I worked for a small company at the time so help was non-existent and I just had to muddle through. Thankfully it all worked out but there were some hairy moments. In particular, discovering that because the equipment was being installed in “clean space” it needed to go through special decontamination processes before it could be installed. Something no-one had told me about!
So how do you go about delivering a successful project?
Before we go any further I should say that everything I’m telling you now is based on my experience. Every organisation is different. Some have the business case written before the project is defined. Some have the business case written after the project charter and others do them in parallel. You might have a project initiation document instead of a charter.
The same is true for all other stages as well. Each organisation is likely to have its own way of doing things, which is different from what I say here.
To get back on track, this is where we hit the first part of the project lifecycle – define. It’s at this point that the project manager (you) will be formally appointed and you’re given the go ahead to write the project charter. Or the business case. Or the project initiation document…..
When you write your initiation document, regardless of what it’s called, you need to make sure that it includes:
- The scope of your project and specifically say what is in and, almost importantly, what is out of scope
- Who will be working on the project and what they will be responsible for. Don’t worry if you can’t name individuals at this point – role names are enough.
- The value proposition for doing the work
- A list of the key stakeholders
- High level risks and some idea of how you are going to mitigate them
- The target project benefits
- High level budget
- Tolerances that the project manager can operate within
Typically a project initiation document has more detail that a project charter. As well as the stuff I mentioned earlier it covers:
- Assumptions, dependencies and constraints
- The governance arrangements for the project
- Communications and quality plans
- Project controls
Writing these documents can take anything from a couple of hours to a couple of months. The define phase is finished when the document is approved.
Planning a project
The next phase in the project journey is planning.
I think that this is the most critical phase of the project. Anything you do here flows on directly to the execution or delivery phase.
I remember when I was working on a really complicated project, with loads of different work streams. The planning hadn’t been done very well and when the project manager left everything fell apart. The project ended up having to start from scratch!
When I plan a project I plan the current phase in detail, I put high level information in for the next stage – typically at milestone level and I put a placeholder for the phase after that. Just before the stage boundary I start planning the upcoming phase in detail.
Before you even think about creating the schedule, go right to the end of the project and think about what it is you’re going to deliver. At this point, I can hear you screaming “what, are you daft, woman? Why would I think about the end?” My response is Yup – the end point! What is it you want, or in all honesty, are being expected to deliver? The answer to this is going to colour everything else you do. Do this exercise – write down a synopsis of the end point. Then, go and read the business case and ask the project team to do the same exercise. Check that what you all understand the product/service etc. to be is the same as what is documented. If they don’t broadly match you have some work to do!
Work breakdown structure
Something I can’t emphasise enough is you can’t build a schedule on your own. Well that’s not strictly true – you can. It will likely be total rubbish, but you can do it. In all seriousness though, when you begin to build your schedule do it as a team. I like to get everyone into a room, begin with the exercise above and then start to work on the work breakdown structure. Getting the whole team together is both a chance for a get-to-know-you session, and sets the tone for the entire project. It also means you’re getting the experts involved early.
I like to have at least three scheduling meetings, as it usually takes that long to get the schedule into a usable state.
A work breakdown structure is normally one of the first deliverables of a project. It is a hierarchical breakdown of the deliverables of the project. It sounds like it should be really easy to create, but it can be an interesting exercise, as things that haven’t been considered often come out of the woodwork at this point.
It’s likely that when you go into the initial meeting you’ll have some ideas about how the project will be scheduled. Please, leave those ideas at the door and go in with an open mind. You’ll be amazed at the solutions your team can come up with which will solve what looked like insurmountable problems.
When I run a work breakdown structure meeting, I make sure I include a representative from the test and support teams, as well as a user representative if possible. These critical functions are often ignored until the very end, which can lead to overruns, delays and ill-feeling.
For the initial meeting I get the team to use different coloured sticky notes. The first step is to get the team to write down every single thing they can think of which the project needs to do. I get them to put the ideas into loose themes. I emphasise that no idea is stupid or too small.
Once that activity is finished, I go round the room and ask everyone to share their ideas. I begin to group the ideas into themes (task groups, or level 1 of the work breakdown structure) on a large surface – normally a wall. Once we’re all happy with the top level structure, we get down into the activities which make up the task groups. At this point there is usually a lot of to-ing and fro-ing with sticky notes being moved around, duplicated and removed.
I tend to stop the meeting once the initial work breakdown structure is complete. The next meetings get into resources and estimates, which leads nicely to the next topic.
During the initial scheduling of the project, you’re unlikely to know exactly who you are going to need to do what. This doesn’t mean you don’t need to think about your resource requirements – far from it. At this point, I tend to plan using roles. For example, I know I’ll need business analysts, developers, testers, etc. and then, during estimation, I can work out how many of each role I need and use that information to inform the resource managers.
Once you’re happy with the amount of resources you need for each task group, you’ll find you’re in a much better position to approach the resource managers to request specific people to work on your project.
Estimating the time it takes to complete a task can be a painstaking process. You can make it easier by following a few simple steps.
Always give people time to come up with the estimates. I’ve found the estimates I receive when I’ve rushed people, tend to be overoptimistic and often need to be changed at regular intervals.
Try to give the estimator as much information as possible up front. It’s impossible to give an accurate estimate without having all of the information available.
Make sure you ask the right people to give you the estimates. There’s no point asking someone who has never done a particular job before to tell you how long it will take. That might be stating the obvious, but I’ve seen it happen on more than one occasion, with the predictable results.
Get the estimators to provide three figures for each task – the best estimate, the most likely estimate and the worst-case estimate.
Try and use bottom up estimating where possible. It is the most time consuming, but tends to give the most accurate results.
Now it’s time to take all the information you worked so hard to collect and turn it into a beautiful GANTT chart. The amount of detail you include very much depends on what you think is important.
I like to make sure the critical path, or golden thread, is clearly visible and to put the name of the individual responsible for the delivery of the task group on the chart.
What to do with it? You have this gorgeous GANTT chart with all of the tasks linked and key information associated with it. Now what? You’d be amazed at how many times this hard won piece of work ends up languishing on a network drive somewhere, never to be looked at again!
This is NOT what you should be doing with it! A schedule is a living document and should be updated and maintained regularly. I like to have mine updated at least once per week. Any more and I’m getting too obsessed and need to back off. Any less and I’m likely to be losing control and oversight – which is never a good look.
The next big chunk of work is around risk management. I once had a project manager friend describe it as a love it or loathe it activity.
For me, risk has become a “love it” activity (sad I know). I’ll tell you why…
I was involved in a project that was part of a multi-billion dollar, multi-year programme of work. The team was a very gung ho, can do bunch, with combined experience in the hundreds of years. However, the environment was difficult, with multiple suppliers all having to collaborate to build the solution that was acceptable to the customer.
There was no risk manager, which in itself should give you an idea of the mindset of the programme, and risk was very much a tick in the box activity.
The risks that were identified in the register were very generic and had little or no substance to their descriptions. Most of the risks were categorised as mitigate, but the mitigation plans were 1 or 2 lines at most, with the owners being identified by title, e.g. programme manager, but no actual names.
So, as always happens, a risk that had been logged in the risk register came to pass. The project had failed to engage the key stakeholder groups sufficiently and there was a massive user backlash towards the solution during the initial pilot phase.
The team went back to the risk register to pull out the mitigation plan to kick start the resolution process. Only to discover that the risk register had rated this risk as low, with the mitigation plan of “engage stakeholders”. The risk owner was identified as the programme manager, but when the programme manager was approached he knew nothing about it and hadn’t done any work to ensure the risk, was in fact, mitigated.
To cut a long and boring story short, this one risk brought the project to its knees, cost the business 10s of millions to resolve, cost a number of very talented people their jobs and delayed the implementation of the solution by 5 years.
An independent review of the project in question flagged the lack of sound risk management as a leading cause of the project’s failure to deliver a robust solution on time and within budget.
This is why I’ve become a risk management convert.
So how do you avoid falling into the same trap?
Start with a risk workshop. Get everyone in the project in a room and include stakeholder reps if possible. Brainstorm every single risk you can think of and log it in the register. Work your way down the list and decide if the probability of each one happening is high, medium or low (or whatever your organisation’s risk framework uses). Then decide the same for the impact if the risk actually happens.
I always add a risk of the project manager dying to my register. It has a low probability but high impact. It raises a few eyebrows but I personally know of 2 projects where it actually happened!
You also need to develop the risk treatment plan. Will you apply controls to decrease the risk, transfer the risk to someone else, accept the risk as the costs to mitigate it are too high or avoid the risk by stopping the activity that will cause the risk?
Make sure you thoroughly document how you will treat the risks. A vague couple of sentences isn’t good enough, remember the example I gave earlier!
The last thing you need to do is assign each risk an owner. This person might not be on the project team but they will be responsible if the risk actually happens. For example, you might have a legal risk, so the owner would be your organisation’s corporate lawyer. Just make sure if the owner is outside the project team that you tell them they are the owner and you involve them in developing the risk treatment plan!
Remember, this isn’t a one off. Risk management is an ongoing activity. There’s no point capturing risks in the risk register and forgetting about them. They need to be actively tracked and reported on.
On that note, you need to make sure that the resister is accessible to everyone involved with the project so that they can add risks as and when they come across them.
To help you manage your risks effectively pick a risk management workflow and use it. Too often projects swap between workflows which creates confusion and can lead to risk escalation not happening properly.
If you find yourself having to convert a risk to an issue make sure you provide as much information as possible, it’s easy to forget that the person you’re escalating to won’t necessarily have a detailed understanding of the problem. Make sure that you have linked the risk being converted to the issue. It makes it much easier to find information and look at the history of the problem if needed.
Make risks a standing item on the project team meeting agenda. I bring the risk register to the meeting for discussion and it’s a great way to make sure risk management stays at the forefront of the team’s mind.
Be aware of risks outside of your project that may impact on your ability to do your job. I’ll normally log those risks in the register with an annotation of the relevant project’s ID and that’s about it. I then make a point of regularly catching up with the project manager to discuss those risks. That makes sure I’m kept up to date on any progress or changes that might impact on my project. Of course, I update my register after every meeting.
Another essential part of the project planning process is around communications. Getting communication right when running a project is a tricky business. It’s more than just pushing out the occasional project update. You need to think about everything from how you’ll communicate to your team, the way you will report to your steering committee, how you will keep your wider stakeholders informed, and how you will deal with feedback from all of those different groups of people.
A formal communications plan gets all these expectations out in the open and it makes scheduling the regular communications activities much easier. If your organisation has a corporate communications team, make sure you work with them. Not only will they be able to help you craft your messages, they are likely to have templates and other tools that will make your job much easier. If you’re really lucky they will assign someone to do the work for you.
Before you can build an effective communications plan, you need to understand the environment you’re working in. A military base will need a completely different communications approach to a building company.
Think about the different groups of people who will need and/or want information from you. Using a stakeholder matrix is a great way to do that. You will be communicating with them regularly during the project so you need to make sure you understand how and when they like to receive information. There is no point sending your PMO your status report on a Wednesday if they have to submit their report on a Tuesday.
You need to be really clear about what you want to achieve. This will help you focus on creating the right sort of communications. So if you want to get a particular group of customers to enter a competition, your approach would be very different to the way you approach your steering committee.
You need to think about how you are going to communicate a wide variety of information. From detailed project status updates, requests for the project team to update information to updates to external stakeholders. Using the work you did on the stakeholder matrix, you’ll be able to focus on presenting the information in the format most preferred by each group.
Stick to the plan. That always sounds really easy but when you’re under the pump it can be difficult. Keeping the message consistent is really important, as you don’t want to give people irrelevant information
Make sure you set up metrics and ways to measure the effectiveness of the plan before you start. Once the plan is up and running, monitor and measure the results regularly to make sure it’s doing its job. If the results are not what you are looking for, you can easily tweak the plan.
It’s not nice to hear negative things about what we produce. If you do receive negative feedback, use it to improve for the next round of communication.
There are loads of tools out there that you can use to make communication easier. Take full advantage of this, as it will make your job a heck of a lot easier and it will also help you monitor and measure the effectiveness of your communications.
Something that’s often overlooked but is critical to successful project management is quality assurance.
Over the years I’ve heard it described as a necessary evil and time consuming. But in most instances there are simple, and very effective ways to check quality without making a huge production of it.
When you’re writing the quality plan think about where there is a critical control point – and by that I mean somewhere, that if you put a check of some sort in you would pick up everything that affected quality so far. That saves you having to check every single item
An excellent example of this mindset in action is the infamous Van Halen concert tour contract rider. It specified that a bowl of M&Ms must be available in their dressing room – with all the brown M&Ms removed. Failure to meet that requirement could lead to cancellation of the show with full compensation.
So why would they do that? It’s a bit diva-esque don’t you think? Nope. It turned out to be a pretty slick way of performing quality assurance on the concert venues’ work.
If there were brown M&Ms in the bowl it gave the band a heads up that their production needed to be thoroughly checked, as it was likely that some technical requirements would have been overlooked.
In David Lee Roth’s autobiography he explained it: “Van Halen was the first band to take huge productions into tertiary, third-level markets. We’d pull up with nine eighteen-wheeler trucks, full of gear, where the standard was three trucks, max. And there were many, many technical errors; The contract rider read like a version of the Chinese Yellow Pages because there was so much equipment, and so many human beings to make it function. So just as a little test, article number 126, in the middle of nowhere, was: “There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation.”
So, when I would walk backstage, if I saw a brown M&M in that bowl . . .well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract.”
Not bad for diva-esque rock stars.
So what kind of things should your quality plan have in it? It should talk about your approach to quality and how you’ll make sure that your deliverables meet requirements. It should mention the quality standards (if any) that you’ll measure against or comply with – e.g. ISO standards. It will include the quality roles and responsibilities within the project team. Depending on your industry it will have things like software testing and code review requirements for IT projects, building standards and external checks for construction etc.
If your organisation has a dedicated quality function get them to help. They will most likely write the quality plan but they should also be providing you with someone to do the quality work on your project.
Now we move on to the money. One of your most important jobs as a project manager is to keep control of the money, the reason being one of the main ways a project is judged to have been successful is whether or not it was delivered within the approved budget.
The first step in defining your budget is to look at the project milestones and decide on the budget start date. If you don’t know the start date yet, you can work with generic Month 1, Month 2, Month 3, etc. and set the start date later on.
Your budget start date might be before the official start date of the project, especially if you’re going to incur expenses before the official start date. This is almost always the case!
Next, you have to decide how many intervals (or months) you need to budget for. You can use the project end date as a guide and calculate the number of months between the project’s start and end dates.
Forecasting is normally the most difficult part. It’s estimating how much it’s going to cost, or how you’re going to fit everything into the limited budget.
Remember that budgets can include both anticipated expenses, as well as projected income. In this case, you might put anticipated expenses as positive values and the projected income as negative values.
I normally suggest to start with a bottom-up approach, initially ignoring the fixed budget.
So how does the bottom-up approach work? As the name suggests, this approach starts at the bottom:
List all of the costs and income, your budget line items, that you can think of
Estimate (forecast) the costs for each line item for each of the months of the budget
Group similar items together, for example sub-contractors, materials, equipment hire, etc. Think of groupings that may be useful to report on.
For larger projects you can group the initial groups into larger groups
The line item forecasts can be added up into the sub-groups and groups of the budget. (This is done automatically in the Psoda budget management module.)
Check that the budget totals do not exceed the budget expectations
Now look at the top-down approach
This starts at the top with the overall budget allowance:
You break the budget down into large groups, e.g. Hardware, Licenses, Manpower, etc.; and allocate a portion of the overall budget to each group
For larger projects break each group down into smaller sub-groups
Break each group or sub-group into a number of budget line items
Estimate (forecast) the costs or income for each line item for each of the months of the project
Add the items up to get totals for the sub-groups or groups (again, this is done automatically in the Psoda budget management module). Just make sure that the totals don’t exceed the budget for the group or sub-group.
Once the budget forecast has been accepted and signed off by all the project (or programme) stakeholders, you want to baseline the budget. Once the budget has been baselined only approved changes will be allowed.
The project baseline figures should not be changed again later on in the project. If there are changes to the project, you need to get additional sign-off for the changes to the budget. These approved changes should be tracked separately.
Controlling a project
Now the planning’s out of the way it’s time to get to the good stuff – delivering what you promised in the business case.
It’s at this point you often find yourself chucking the business case away and starting from scratch. No, I’m not joking, that does happen and more often than you’d think. If it does happen to you, it’s not necessarily a bad thing. In fact it’s a sign of a mature organisation, that’s keen to minimise mistakes and focus on projects that will deliver value.
One thing you need to be absolutely clear about as a project manager is it’s your job to manage not to get into the weeds and do the job. That’s why you have work packages and work package owners.
Now this isn’t an easy thing to do. I remember when I first started that I was forever getting into how things were being done, interrupting progress and heinous of heinous crimes – doing some work myself.
Your golden document at this point in the project is the schedule. Remember that thing that you created way back when? Now it’s time to put it to good use and where you’ll see if all that planning you did is actually successful.
I like to have my work packages durations between 1 day and 2 weeks. This means I’m not getting bogged down in detail but I’ve got enough oversight so that if it looks like things are going off track I find out early enough to intervene.
I’ve known a few projects to fail because of poor schedule management. One in particular that comes to mind was a telecommunications project where the work package owner in one area kept telling the project manager everything was on track. He had a work package with a duration of 8 months and at every update it was in progress. Come the weekend before go live and the work package owner came to the project manager and told him he was in fact 6 months behind schedule. You can imagine the fallout from that one! Let’s just say it was epic! The work package owner and the project manager both lost their jobs and the company had to pay millions to their customer is damages.
Controlling the project budget
You also need to make sure you keep a handle on your project’s budget. As soon as you start incurring costs on your project, you’ll want to record these expenses so that you can track your actual expenditure against the original budget forecast and report any variance.
Variance is the difference between the approved budget and the actual expenditure. It’s a single number to tell if you are spending more or less than what you had planned.
To clearly understand variance, we need to do a bit of maths (sorry about that!). If we define the following variables:
F – Forecast
C – Approved changes
A – Actual expenditure
Then the variance (V) is calculated as:
V = A – (F + C)
If the variance is negative, then you are spending less than your budget. This can be a good thing if you are actually underspending, but be careful that you haven’t actually spent the money but just not been invoiced yet!
Your budget will be right on target if the variance is zero.
If the variance is positive, then you’re spending more than your budget and will have to tighten the belt.
Another financial metric that you might be asked to regularly report on is accumulated forecast vs accumulated actuals.
The accumulated forecast is the sum of all the forecasts up to the date under review. So if the budget had been $10 000 for each month of the project, then the accumulated forecast will be $10 000 in the first month, $20 000 in the second, $30 000 in the third month and so on.
Similarly, the accumulated actual expenditure is a sum of all the expenditure up to the date under review. For example if the expenditure for the first three months of a project were $12 000, $10 000 and $8 000, then the accumulated expenditure would be $12 000 for the first month, $22 000 for the second month and $30 000 for the third month.
By comparing the accumulated budget forecast and the accumulated actual expenditure you can see if your project is burning cash faster than it should. Using a chart to visualise this makes it much easier to see how things are going on your project finances.
Closing a project
Finally, the day you probably thought you would never live to see has arrived – you’ve got a final end-date for your project. So how do you close your project in a controlled way, instead of just shutting up shop on the final day – I have seen that happen!
Start by sending notices to all your stakeholders about six weeks before the end date to let them know that the project is coming to an end. Make sure you include the resources managers so that the team can be scheduled onto their next gig.
Prepare the project close out reports and make sure everything that needs to be signed off by the stakeholders is signed off. This is vitally important as you don’t want to have any problems a year down the line if the customer complains and there is no formal sign off. Get everything signed off before the project ends. This includes handing things over e.g. outstanding issues. Once the project’s closed it’s out of sight, out of mind & you have very little hope of getting anything signed off afterwards.
If you’re deploying a product that needs ongoing maintenance, formally hand the product over to the support team. Make sure it is documented and signed off (do you sense a recurring theme here?)
Hold a lessons learned session with the project team and as many stakeholders as possible. It’s even better if you can get your customer to attend. Of course if you maintained a lessons learned log during the whole project you can bring that along to the meeting.
Make sure to prepare a benefits realisation plan and to formally hand over the benefits to the business owner to ensure that the maximum benefits possible are achieved.
Once the product has been handed over, keep in contact with the customer and the support team for a couple of months in case of any hiccups. It might sound like overkill but it will do your reputation no end of good.
And last but not least. Party like it’s 1999! Nothing beats a project close down party. Just make sure it doesn’t get too outrageous! Of course, you built that into your budget at the beginning of the project. If not, then make sure you bring the project in under budget so you’ll have some party money left.
As always, if you’re looking for a tool to help you manage your projects you can’t go past Psoda. Sign up for a free trial by clicking on the big, red free trial button at the top right hand corner of the page.