Project Management for Beginners: A Simple Guide (2020)

[Music] hi I'm Lana alert deputy everything officer at Sodor and I've been involved in project management for more years than I care to think about you've probably landed here because you're new to project management and want to get an idea of what to expect in your new career so firstly welcome if you haven't already I highly recommend you check out my 12 terms you should know video it's a concise introduction into the sometimes confusing language of projects it will make you feel a bit more in control and less like you've landed in an alien environment in this video I'm going to talk you through what it means to be a project manager I'm going to cover the following topics what is a project how to define a project planning a project controlling a project and some common problems project management is everywhere from someone building their own home to a country pitching on a large high-profile event 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 a Loeb 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 50s post Second World War defense and aerospace industries so the first thing to get your head around is what a project actually is there are loads of great definitions out there but in a nutshell a project is something you do to solve a particular problem at this point the more experienced PM's among you will be laughing your heads off as everyone has ever been involved in projects has at least one example of a project that has been done over and over and over again and has still failed to achieve what it set out to do once you know what a project is it becomes much easier to identify water project isn't for example building and testing a new machine is a project but manufacturing thousands of them isn't and would be classed as business as usual you really 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 p.m. Bakken Argyl p.m. bak is a project framework and Princeton agile our methodologies the PM stock exchange is a great explanation of the difference between frameworks and methodologies they describe 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 whereas a methodology is a set of principles tools and practices which can be used to guide processes to achieve a particular goal projects also have defined life cycles usually something like define plan execute and closeout I'll be discussing each phase and secrets throughout this video so what do you do if you've been given a job of delivering a project and you don't know where to start don't panic and all that it'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 a new piece of equipment talk about panic I work for a small company at the time so help was non-existent and I just had to muddle through thankfully 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 organization 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 even have a project initiation document instead of a charter the same is true for all other stages as well each organization is likely to have its own way of doing things which is different from what I see here to get back on track this is where we hit the first part of the project lifecycle defining is at this point that the project manager you will have been formally appointed and you're given the go-ahead to write the project charter or the business case or the project initiation document basically whatever your organization calls it when you write your initiation document regardless of what it's called you need to make sure it includes the scope of your project and specifically say for s/n and most importantly what's out of school 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 actually doing the work a list of the key stakeholders high-level risks and some idea of how you're going to mitigate them the target project benefits high level budget and tolerances that the project manager can operate within typically a project initiation document has more detail than 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 and project controls writing these documents can take anything from a couple of hours to a couple of months the defined phase is finished when the document is approved the next phase in the project journey is planning I think that this is the most critical phase of the project as 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 planned the current phase in detail I put high-level information and for the next stage typically at milestone level and 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 women why would I think about the end my response is yup the endpoint what is it you want or in all honesty are being expected to deliver the answer to this is going to color everything else you do do this exercise write down a synopsis of the endpoint then go and read the business case and ask the project team to do the same exercise check that what you all understand the project or service etc to be is the same as what is documented if they don't broadly match then you have some work to do something I can't emphasize enough is you can't build a schedule on your own well that's not strictly true you can they'll 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 began 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 it 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's 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 you haven't even 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 loop reminding 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 tests and support teams as well as a user representative of 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 colored sticky notes the first step is to get the team to write down every single thing that they can think of which the project needs to do I get them to put the ideas into loose themes I emphasize that no ideas stupid or too small once that activity is finished I go around the room and ask everyone to share their ideas I begin to group the ideas into themes tasks groups or level one 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's usually a lot of chewing and frying with sticky notes being moved around and 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're 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 rules for example I know I'll need business analysts developers testers etc and then during estimation I can work out how many of each rule 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 it 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 found that estimates I received when I rushed people tend to be over-optimistic 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's the most time consuming but tends to give the most accurate result now it's time to take all the information you've 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 paths are golden thread is clearly visible and to put the name of the individual responsible for the delivery of the task group on the chart so what to do with it you have this gorgeous Gantt chart with all the tasks Kay linked and key information associated with it know what you'd be amazed at how many times this hard-won piece of work ends up languishing on a knit or dry somewhere never to be looked at again this is not what you should be doing with it I share gel as a living document and should be updated and maintained regularly I like to have mine updated at least once a week anymore 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 described as a love it or loathe an activity for me risk has become a lover 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 program of work the team was 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 program and risk was very much an hour ticking 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 categorized as mitigate but the mitigation plans were one or two lines at most with owners being identified by title eg program manager but no actual names so as always happens are risks that had been logged in the risk register came to pass the project had failed to engage the key stakeholder groups efficiently 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 meta Gatien plan to kick-start the resolution process only to discover that the rest predator had waited that risk is law with the medication plan of engaged stakeholders the risk owner was identified as the program manager but when the program 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 tens of millions to resolve cost a number of very talented people their jobs and delete the implementation of the solution by five 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 and 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 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 organization'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 a high impact it raises a few eyebrows but I personally know of two projects where it actually happened you also need to develop the risk treatment plan will you apply controls to decrease the risk transfer the rest to someone else accept the risk as the cost to mitigate 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 them 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 the 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 organization's corporate lawyer just make sure if the owner is outside the project team that you tell them that they are the owner and you involve them and 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 the register 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 Pecha risk management workflow and use it too often projects mock between work floors which creates confusion and can lead to risk escalation not happening properly if you think you have to convert a risk to an issue make sure you provide as much information as possible it's easy to forget the person you're escalating to would necessarily have a detailed understanding of the problem make sure you've 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 mate 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 everyone's mind be aware of risks outside of your project that may impact on your ability to do your job I normally log those risks in the register with an annotation of the relevant projects 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 communication 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'll report to your steering committee how will keep your wider stakeholders informed and how you'll deal with feedback from all 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 organization has a corporate communications team make sure you work with them not only will they be able to help you craft your messages they're likely to have templates and other tools that will make your job much easier if you're really lucky they'll 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'll be communicating with them regularly during the project so you need to make sure you understand how and when they'd like to receive information there's 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 if you want to get a particular group of customers to aim to their competition you'll approach would be very different to the way you approach your steering committee you need to think about how you're 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 and the foremast most relevant to 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 a relevant information make sure you setup 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're looking for it 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 lots of tools out there that you can use to make communication easier take full advantage of this and 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 it's 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'll pick up everything that effective quality so far that saves you having to check every single item an excellent example of this main set in action is the famous 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 ESCA don't you think nope it turned out to be a pretty slick way of performing quality of students on the concert venues work if there were brown M&Ms in the pool it gave the band a heads up that the production needed to be thoroughly checked as it was likely that some technical requirements would have been overlooked and 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 9 18-wheeler trucks full of gear for 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 one to six in the middle of nowhere was there will be no brown M&Ms 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 ball well lime check the entire production guaranteed you're going to arrive at a technical error they didn't read the contract not bad for devious rock stars so what kind of things should do quality plan having it if you talk about your approach to quality and how you make sure that your deliverables meet requirements it should mention the quality standards if any that you measure against of comply with eg 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 called review requirements variety projects building standards and internal checks for construction etc if your organization has a TEDA kated quality function get them to help they'll 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 as 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 one two three etc and then 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 start and end dates forecasting is normally the most difficult part its estimating how much it's going to cost or how you're going to for 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 lists all of the costs and income or your budget line items that you can think of then estimate the cost for each line item for all of the months of the budget group similar items together for example subcontractors 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 items forecasts can be added up into the subgroups and groups of the budget now this is done automatically in the sort of budget management module check that the budget totals don't exceed the budget expectations now let's look at the top-down approach this starts at the top with the overall budget allowance you break the budget down into large groups for example 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 then break each group or sub group into the number of budget line items estimate the costs or income for each line item for each of the months of the project then add up the items to get the totals for the sub groups or groups again this is done automatically in this order 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 a he all the project or program stakeholders you want to baseline the budget once the budget has been baselined only approved changes will be allowed the project baseline figure should not be changed again later on in the project if there are changes you need to get an additional sign-off for the changes to the budget these approved changes should be tracked separately now the planning is 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 this does happen and more often than you'd think if it does happen to you it's not necessarily a bad thing in fact as the Saint if I'm a true organization that's keen to minimize 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 and doing some work myself your golden documents at this point in the project is the schedule remember that thing 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 one day in two 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 feel because of pure schedule management one in particular that comes to mind was a telecommunications project where the work package owner in 180 I kept telling the project manager everything was on track he had a work package with a duration of 8 months and every update it was in progress come the weekend before bull life and the work package owner came to the project manager and told them he was in fact six 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 and damages you also need to make sure you keep a handle on your projects 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 you if you're 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 is forecast C is approved changes and a is actual expenditure then the variance V is calculated as V equals a minus open bracket F plus C close bracket if the variance is negative then you're spending less than your budget this can be a good thing if you're actually under spending but be careful that you haven't actually spent the money and just not being invoiced yet if the variance is zero then you're right on target with your budget if the variance is positive then you're spending more than your budget and we'll have to tighten the belt another financial metric that you might be asked to regularly report on is accumulated forecast versus accumulated actuals the accumulated forecast as the sum of all the forecasts up to the date under review so if the budget had been ten thousand dollars for each month of the project then the accumulated forecast will be ten thousand dollars on the first month twenty thousand dollars in the second 30 thousand in the third month and so on similarly the accumulated actual expenditure is a sum of the expenditure up to the day under review for example if the expenditure for the first three months of the project was twelve ten and eight thousand dollars then the accumulated expenditure would be twelve thousand for the first month 22 thousand for the second month and thirty thousand 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 visualize this makes it much easier to see how things are going on your project finances family the day you probably thought would never live to see has arrived you've got a final end date for your project so how do you close your project is a controlled way instead of just shutting up shop on the final day and by the way I have seen that happen start by sending notices to all your stakeholders about six weeks before the end it to let them know that the project is coming to an end make sure to include your resources managers so that they can be scheduled on to their next gig prepare the project closeout 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's no formal sign-off get everything signed off before the project ends this includes handing things over for example outstanding issues once the project's closed its out of sight out of mind and 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's documented and signed off do you sense a recurring theme here hold the lessons learned session with the project team and as many stakeholders as possible as even better if you can get your customers to attend of course if you maintain the lessons learned log during the whole project you can bring that along to the meeting make sure to prepare a benefits realization plan and to formally handle for the benefits to the business owner to ensure the maximum benefits possible are achieved once the products been handed over keep in contact with the customer and the support team for a couple of months in case of 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 closed end 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 so I have a favor to ask out of everything you've heard today what's your favorite tip a not building this schedule in isolation be how to calculate accumulated forecasts versus actual see the M&Ms for Quality Assurance or D something else and please let us know in the comments I hope you find this epic video useful go away and enjoy your beverage of choice after listening to me talk for the past half an hour you deserve it don't forget to hit like on this video and subscribe to our channel to find out about our latest new awesome video releases and as always if you're looking for a tool to help you manage your projects you can't go past order sign up for a free trial at www.sceeto.com you

Channel: Psoda

Views: 99,289

Rating: 4.8927741 out of 5

Keywords: project management for beginners, project management tutorial for beginners, project management for beginners course, agile project management for beginners, project management for dummies, project management tutorial, project management tutorial full, project management guide, project management simple, project management tips, project management tips for beginners, project management plan, Project Management, Test Management, Requirements Management, psoda, psoda videos

Id: oC9fUwQyriE

Length: 31min 51sec (1911 seconds)

Published: Mon Aug 20 2018