21 Steps to Successful Project Management | Wolf Matejek | Skillshare

21 Steps to Successful Project Management

Wolf Matejek, Entrepreneur, Business Coach, Author & Trainer

21 Steps to Successful Project Management

Wolf Matejek, Entrepreneur, Business Coach, Author & Trainer

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
24 Lessons (1h 36m)
    • 1. Intro

    • 2. What is project management

    • 3. Step 1 Stages of a project

    • 4. Step 2 Establishing Sponsorship and Leadership

    • 5. Step 3 Defining Business Objectives and Benefits

    • 6. Step 4 Planning the project

    • 7. Step 5 Ensuring the Project is Manageable

    • 8. Step 6 Defining the Project Budget

    • 9. Step 7 Managing the project risks

    • 10. Step 8 Engaging the Right Project Manager

    • 11. Step 9 Getting customer representation

    • 12. Step 10 Defining Team Roles and Responsibilities

    • 13. Step 11 Getting the Right Resources

    • 14. Step 12 Monitoring and Reporting Progress

    • 15. Step 13 Communicating Project Progress

    • 16. Step 14 Consultation and Leadership

    • 17. Step 15 Collecting Realistic User Requirements

    • 18. Step 16 Defining your Approach

    • 19. Step 17 Conducting Structured Testing

    • 20. Step 18 Creating an Implementation Plan

    • 21. Step 19 Conducting the Post Implementation

    • 22. Step 20 Realising the Business Benefits

    • 23. Step 21 Learning the Lessons

    • 24. Step 22 Celebrate the Project Success

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Projects are the way organisations/businesses do things and introduce change to their ways of working. This may include process changes or the implementation of new IT systems or software applications.

Either way, projects bring about change that improves services to customers, increase operational effectiveness and change processes and ways of working.

Employees in all kinds of roles participate in projects, so what exactly is project management and how is it being managed?

This course takes you through 21 steps of a project, from early conception and scope definition to evaluation and lessons learned. Throughout the course, you will learn about what good practice is as well as learning about some common mistakes that could be made along the way.

This course will help those new to project management to manage and/or contribute to projects more effectively, and for those people who have been involved in project management previously to brush up on their skills and knowledge.

Meet Your Teacher

Teacher Profile Image

Wolf Matejek

Entrepreneur, Business Coach, Author & Trainer


Wolf has for more than a decade been helping passionate people like yourself, in building their own successful and profitable service businesses.

He states his reasons for wanting to help people to be the best they can, as: "You are the person that inspires me to use my business coaching, mentoring and training skills in making your business a success."

As a trainer Wolf has travelled across the world, delivering programmes on a diversity of subjects including soft-skills, motivational programmes as well as bespoke IT applications.

His website can be found at http://www.business-success-unlimited.com

His books are published via Amazon at http://goo.gl/UtoHcj

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.



1. Intro: Hello and welcome to your 21 steps to successful Project management. Now this cause is for those people who want to start as a project manager All those people who already have some project management experience but want to find June their project management skills to achieve a successful outcome on any project they want to work up. Hello. And my name is Wolf Magic, and I am a project manager. I'm also a trainer, and I've delivered project management and training project to clients all over the world. So for my experience and from some research, I've put together these 21 steps that will help you to succeed in your own projects. Now, what is in the course? What will you learn from this course? Now, there is all 21 steps lined out on this particular screen. Now, I'm not going to read them all out because I don't want to bore you. But I suggest you quickly pause the video and have a look off. What subjects I'm going to cover in this detailed course. Now that you know what is covered in this course, I suggest you sign up to my course today and learn new skills or improve the skills you already have, and I look forward to welcoming here in this course. 2. What is project management: Hello and welcome. And thank you for joining me on this cause off 21 steps to successful project management just to recap up. Want to highlight once again the 21 steps we're going to cover in this particular training program? Or course, just pause the video read through the screen to learn what we're going to cover now before we kick off with the whole course. Here's just something I want to share with you. With regards to what project management actually is. Trevor L. Young is a famous writer on project management. He also was, for many years a senior consultant for the Industrial Society. He designed and conducted two major public training courses in project management techniques and project leadership, and he summarizes project management as a dynamic process that utilizes the appropriate resource is within an organization to use them in a controlled and structured manner to achieve some clearly defined objectives identified a strategic business needs. He also says very clearly that project management should always be conducted within a defined set off constraints 3. Step 1 Stages of a project: All right, everyone. Now it starts to get interesting because we are kicking off with Step one. The project stages now there are six stages to every project, and each of those stages is created toe a distinct set of activities that take a project from the first idea to its final conclusion. Each stage within the stages of a project is equally important, and each one helps to contribute to the overall success off the whole project. So let's have a look at the six stages off the project. The 1st 1 is the definition stage off a project. The next one is the initiation stage. The 3rd 1 is the planning stage. The 4th 1 is the execution off the actual process steps or project steps, and the 5th 1 is about monitoring and controlling the project. Number six is about the closure off the project right at the end when it's all being done. So let's look at each one in turn, starting off with the definition stage before a project starts, a project manager must make sure that all project goals objectives, the scope of the project, any risks identified within the project, any issues for seen within a project. The budget, the time scales and the actual approach have been clearly defined. Once that's done, it should be communicated toe all stakeholders to get their agreement off the definition off the project. And that should be preferably in writing. So there will be no come back afterwards where stakeholders may say, I never agreed to this. I didn't know about that, etcetera. Any differences off opinion must be resolved at this early start off the project and well, before you even start working on a project. The initiation stage is probably the most important stage off any type of project. Since that sets out, the terms of reference within the project will be run. If this initiation stage is not prepared or done well, there is a high chance that your project may actually fail. The initiates and stage in the whole context is where the business case is being declared. The scope off the project is being decided and stakeholders expectations off being set. So here is where we put in exactly what is in scope and what is out of skirt. So later on, a stakeholder can't come and say, by the way, I've just remembered something else that we should be doing in this project. If it's not in the initiation plan, then we won't be taking care of it. As the project rolls on, if we allow Project creep or scope creep to come into play, that means little things suddenly appearing in the project that haven't been clearly defined. We are setting out ourselves out to actually create more work across over off responsibilities and potentially a failure off the whole project, because the whole thing suddenly doesn't gel anymore. And we are introducing gaps and holes along the way. Time spend on planning, refining the business case and communicating the expected benefits for the business will help to improve the probability off success off your project, even though you may be tempted to start work immediately. Poorly managed initiation stage often leads to problems further down the line and, as I said, can even jeopardize your whole project Going forward. Number three. The planning stage. The key to everything we do is good planning. Creating a project plan is the first task you should do when undertaking any project, so now we've agreed what's in and what's out now we define the project plan, We talked to the stakeholders. What S M E areas within their respective area of responsibility form part off that project and we create the project plan. This is usually done within a software applications such as Microsoft Project. There, we can identify exactly the steps that are needed in the project itself, actions that we need to take or tasks that need to be completed in what time frame and by whom. Sometimes people tend to ignore the process off project planning in favor off just getting on with the job. But people do fail to realize the value off a project plan, since it will not only be saving you time and money, but also helps you to not have major problems along the way. Important tasks that tend to get forgotten about or overlooked. The execution stage is when we actually start the physical work on the project in hand. This is where we want to work on delivering the product, the service or work on the desired result that is carried out. Most of the work related to the project is realized at this particular stage, and it needs the complete attention from the project manager and also the involvement off the individual s Emmys, who will be working on the tasks within the project plan. And it's imperative at that point that the project manager knows exactly how much time those resource is. Those individuals are dedicating to the project, monitoring and controlling the project. Once the project has started to take momentum and it's running, it's important that the manager the off the project maintains complete control. This can be achieved by regular reporting, off issues, risks, progress reports and the constant checking off the business case to make sure that any expected benefits will be delivered and they are still valid for the business. Failing to monitor and control the project as it rolls on can also be a major obstacle in the success off the project as a whole. Lastly, the project is now run to its end and we're coming to the closure. It's important that you make sure a project is closed properly. Very often you may find projects may not have a clear endpoint because there is no formal signing off. I always encourage everyone to make sure that if you're near the end of a project. You do get a formal signing off an agreement from the Project Sponsor that what was set out in the initial project plan and in the initial initiation stage has been successfully delivered. You must get the customers agreement that the project has ended and confirmed that no more work on this project as it stands will be carried out. Remember early I mentioned Project Creep. So tasks creeping in or Qatar's that have may have been missed that now becomes a second re time off the project you made. Then initiate another project where additional tasks will be Roven into what's already being done part for that particular project that you've had according to your project plan . It's ended. It's finished. Get a formal sign off from the Port Project sponsor or the customer and once closed, the project manager now has to review the whole project. He or she needs to record any good or bad points that happened within the delivery off this project, so that in future successes and actions that were successful can be repeated and any mistakes or failures can be avoided. A project that is not closed will continue to consume. Resource is that means if the project just rolls on, it is not formally signed off. Then may still be people working on this particular project doing additional work that wasn't part off the project. But they just carried on because they felt compelled to deliver more than was expected in the original project plan. That, of course, will then cost time and money to the business. So remember signing off enclosing your project is vital. 4. Step 2 Establishing Sponsorship and Leadership: here we are now with step number two, establishing sponsor and leadership. Ask yourself, Do you actually have adequate business, sponsorship or and leadership? Because if you don't have that, you may actually be running against a brick wall. So how do we do that? There is some good practice I would like to share with you is senior business Once er should be identified at the highest possible level within the business organization, and this person should then be named in the Project Definition document. The project sponsor is perhaps the second most influential person on any project after the project manager, and in some cases may even be ableto wield more influence on potential project results. That's a statement made by Dave Nilsson. Now also, the steering committee must be set up and become operational right from the start off your project. The steering committee is responsible for taking all key decisions about the project, such as how it's being run, what's included what's excluded, and the steering committee should be composed off senior managers from within the business . Ultimately, the steering committee and the chair off the steering committee have the ultimate responsibility for any project. The project manager, on the other hand, leads the project and is thereby fully accountable for delivering the project and the outcomes off the project as described and agreed in the project definition document. While this is good practice, there are obviously some ways that we need to look at to proper project leadership. We need to create an atmosphere off trust that's not only with the people who work on the project, such as the S Emmys, but also within the steering committee. We need to build the right team. Put the right plate people in the right places. Within your project, you need to clearly outline everything to your team, and you need to do that up front. So you need to clearly identify which tasks you need everyone to complete. You need to be able and willing to monitor and give feedback on the progress off this project, thereby keeping all your communication channels open. So if there are questions along the project, you need to be able to have that communication back and forth so people feel confident to ask you without looking stupid or being judged in number six is you need to keep the end goal Clearly in mind some common mistakes that are being made in managing a project leadership. You may be wasting time and money on projects that do not have enough sponsorship, commitment or leadership to succeed. You hope that people who do not commit early may make time lay drop. And lastly, you may not be involving the sponsor with a set direction to keep the project on track. Now let me give you an example. I was hired to deliver a project for a well known brand. When I came onto the project, they already had set up the steering committee. They already had set up all the tasks that need to complete. Or should I say, they had an idea off the tasks that need to be completed, and they had some stakeholders on board who were representing certain areas within the business that were affected by the project. Lo and behold, a few weeks into the project, I was still chasing for the sponsors and the stakeholders to give me exact details off the task they wanted their team members to complete as part off their project. Unfortunately, after numerous requests and repeated emails, repeated requests to attend meetings. People just didn't find it necessary to partake in this project. They were more concerned about that day to day activities, doing that job. And, quite frankly, as a project manager, I felt there is no way that I can get the commitment, all the leadership to come together. So I walked away from the project. Why did I do that? Because I am not going to be a project manager on a project that is set up to fail from the moment I walked in the door. So I did leave the company unfortunately, and sadly so, because it was a project I would have loved to continue. But I didn't get the commitment from high up in the business to actually make this a success. So before you start your project, you need to find committed project sponsors who have enough clout in the business to make the project work. Your project sponsor will prove to be invaluable in helping you to overcome organizational roadblocks as and when they arise. If you find your project sponsor, the highest person controlling the project is not on ball with the project. When it's being implemented, you are standing very little chance to make the project a success project without a senior business sponsor are seriously at risk off failure. 5. Step 3 Defining Business Objectives and Benefits: Welcome to Step three off my 21 steps to successful project management. Step three is about defining your business objectives and the benefits before you embark on this Step three, you need to be clearly understanding the business objectives and the benefits and have them defined to its greatest detail. So what is good practice in this step? Now? A project definition document should be prepared early on in your project, and it needs to be formally signed off by your steering committee. Within this document, you need to define the goals, the objectives that benefits the deliverables that will be created, any exclusions such as what's not in scope. Any assumptions the business sponsors, their names and their roles and responsibilities as well as the project estimated costs the time scale for your project. And it holy serves the following purposes. Number one clearly defining the objectives and the skirt off the project, what's in and what's out off scope. It also provides management anti members with a common view and a clear understanding off the commonly shared goals. It provides a good starting point for any subsequent definition off. More detailed documentation, such as your project plan your project budget and any functional requirements specifications. Some common mistakes that I made in this crucial step is to starting to focus on solutions or how to do something rather, firstly gaining a clearer understanding off the total and whole business objectives that you want to achieve. Another mistake is failing toe. Identify the business sponsors needed to help in achieving those objectives within your project. Or another common mistake is that you're not returning a benefit statement during the project to make sure that common settings in the goals are still valid and achievable within your project. 6. Step 4 Planning the project: step for planning your project. Have you developed a detailed project plan? Now? Good practice means that a detailed project plan must be developed and signed off by the steering committee. Good plan provides the following benefits Number one. It translates the high level business objectives into a detailed roadmap off concrete deliverables. Number two. It provides a detailed list off resource requirements. Number three. It provides a realistic assessment off your project. Timescales number four. It allows an estimated project cost to be validated further number five. It allows for issues to be identified earlier on, such as. Some task may take longer than expected. Slippage may appear in the target dates and team members may not be productive. You should base your project plan on well known metrics I eat. How long did it earlier was similar project in the business? Take what was the UPS and the downs within that project they've done previously. What went right? What went wrong? Take all that information digested and see how that will fit into your current project plan . You also need in your project plan to involve all team members, not just to senior management and furthermore, a plan that you create should be created in iterations over several weeks. In that time, you want to be consulting with team members and also drawing on their own experience on other projects. They may have bean involved in or on the tasks they be required to deliver. This part of the project that you're setting up now, What are the common mistakes at this stage? Well, the most common one is having no project plan at all. Now, I would always advocate Don't step into a project without knowing exactly what's ahead of you. So make sure you do create your project plan. Or sometimes people create a wrong project plan. Do not be taking in by a project plan that has been produced to give the steering committee a warm, comfortable feeling where they go. Oh, it all looks so lovely, and it's wonderful, blah, blah, blah. If it's not based on reality, a wrong project plan is much worse than sometimes not having a project plan at all. We're not here to please. People were here to deliver something off value to the business, and therefore we want to make sure our project plan is fit for purpose, As with all methodologies, you do need to use your common sense and your pragmatism. Don't be too religious. The five day project may not require a very detailed project plan, but when we're talking about a major investment in a long term project that runs over many months, the more detailed your plan is there more accurately will be as a project manager to control your budget. Your resource is, and the deliverables within that plan do not new side off what your project is trying to achieve. Traditional project management techniques may encourage over planning or generate an excessive focus on micro level tasks at the cost off. The overall projective so do go deep enough to include all require tasks. But don't go down to the point off saying which color pencil should be used to fill in a document. Now that would just be straightforward, ridiculous. Disbelieving evidence from past projects and insisting that your current project can be done faster with fewer people is also a very strong miss belief, and it will be a very common mistake for many people because they compare one egg with the other, even though they're small eggs and logics. So always be careful that you're not pushing your project to a very unachievable limit. And lastly, committing to what base lining a project plan too early can mean trouble. So here, a couple of notes I want to highlight as well. If you're trying to manage large and complex projects without a project plan, it is like crossing an unknown continent without a member. You are basically running blind. You have no way off managing your team, controlling their efforts, expecting the outcomes to be met or the achievable to be met if you don't know what they are. The key action to get things right is the balance between planning and action. When successive project milestones are being missed, this is a sure sign that your project is failing. 7. Step 5 Ensuring the Project is Manageable: welcome to Step five, ensuring your project is manageable. Is it a manageable size? A large project should be cut up into multiple manageable sub projects, which only depend on complete itself projects those with a short term deliverable. It is really important that you don't look at your project as one big, large sheet off task to be delivered. They need to be divided into smaller chunks. It should be divided into a number off key milestones. So little checkpoints that you built into your project plan. So when one task is completed, you finish the milestone before you move on to the next subset in your project plan. This helps to provide continual delivery and is also making sure that your progress is measured regularly and accurately. Some common mistakes in project planning is that sometimes people tend to go for a big bang implementation. They're not being prepared to take the extra cost of splitting the project into separate stages. This sometimes underestimates the overall complexity and the interactions between Aled, the separate components within the project 8. Step 6 Defining the Project Budget: Hello. It won't come to step number six Defining your project budget. Do you actually know how much the whole project is going to cost? And have you defined a detailed budget for that project? Now, good practice means that you need to define all costs. Inform off a project budget. This then has to be signed off by your steering committee or any other authority in the business to make sure that any funds for that project are also readily available right at the start, not later, down the line that we drip feed into the project, your budget should include all internal as well as external costs. Internal cost is all the resource is, and everything else that goes with it and external costs include things like licenses is you may need for software. Third party services consultant consumables, etcetera. A few basic rules will make sure that you have an accurate and realistic budget, and you have it produced in readiness for your project. So let's look at some off. These basic rules assume that people will only be productive for 80% off their time. There is still an aspect off people. The resource is will be using that time for standard be a year. Business as usual activities their jobs effectively. People working on multiple projects may take longer to complete your tasks because they lose time as this which between different projects People are very optimistic at many times , and they often underestimate how long an actual task may actually take. So bear that in mind when you put a time scale to your tasks in your project plan and that also obviously affect the cost Ing's make use off other people's experiences and your own one. You creating your budget. Why not get some expert view on your project plan? Ask other people how they feel this project plan looks, and is it achievable within the constraints off time and budget. You also want to include any management time or costs in your estimate. Always build in some contingency for any problem solving for meetings and other so called unexpected eventualities or events costing each task in the work breakdown structure commonly referred to S. W. B s to arrive at a total for your project rather than trying to cost the whole project there and then it's easier if you do it through the W. B. S because that way you can look at the individual tasks and actions, and adding them all up makes it easier than just making up a ballpark. Figure what the whole project may actually cost. Agree on a tolerance with your customer for extra work that hasn't been defined at this moment in time and communicator your customer. Any assumptions, exclusions or constraints you have on this project provide regular budget statements to your customer copying in your team. So they are always aware off where they are in the current position progress and cost off the project they're involved in. He has some common mistakes people make when they budget for their project. Number one is the leg off budget ownership. Nobody wants to take charge off the financial aspect off the project or it's being referred to someone else, who then refers it to another person. And you just keep running in circles. The budget ownership should be clearly defined. Who the person is, who holds the purse strings for your project. Another mistake is to get drip fed on your budget. That means providing funds on an ad hoc basis once you've done the first thing. We'll give you some more money to do the next thing, and we'll give you some more money. Once you've done that, that's not going to work because sometimes you actually save money on some tasks. But other task may actually consume more money, then was originally estimated. So you want to know exactly up front what money is available for the whole of the project and then make sure that you keep track off your expenditure. Major costs not clearly identified early wrong can actually result in your project being canceled because there is no more money being made readily available to your project. So make sure all costs are covered. No control or monitoring off actual spend against your plan. Spend is another common mistake people make. They think the money will just continue rolling. Remember, there is a set amount of business had set aside for the project so much it will cost, or that's what they think it will cause. You budget your project accordingly, and if you need more money right at the start, ask for it. It's no good starting the project and then running out of funds halfway or 3/4 into the project. Somebody might actually say Sorry, the Paris is now looked and if there's no more money coming, your project will die a sudden death. 9. Step 7 Managing the project risks: Now we're reaching Step seven. Managing your project risks. Are you managing your project risks effectively now with every project. While we all expected to run smoothly, there are always risks attached to every project. Now, good practice says that the task of a project manager is to identify the most severe risks and to plan in minimizing them throughout your project. You should continue to focus on major risks that are facing the project, which can change or will change over time. This helps you to focus on the areas that need to be addressed. You should always consider using a risk mapping approach to number one. Identify the project Objectives number two. To prioritize the objectives number three toe. Identify the key risks to missing those designed and decided upon objectives. Number four to take preventative action and number five to track and update those risks monthly by using a risk tracking log, there are four risk management techniques. You may 12 years to manage the risks off your project effectively, so let's look at those four risk management techniques. Number one is avoidance. You can always use an alternate approach without the risk, but this may not always be possible. Some programs deliberately involved high risks in the expectation off high gains. In the end, this is the most effective risk management technique if it can be applied, Number two is to control the risk controlling risk involves developing risk reduction plan and then tracking to that plan. A key aspect here is the planning by experienced people. Number three is the assumption this means to simply accept the risk and continue as is. But there may be a tendency within organisations to gradually let the assumption off risk take on feeling on aura. Off controlled risk in number four is the risk transfer. This means causing another party to accept the risk typically by contract or by hedging. That means someone else will carry the can for you. Some common mistakes in managing the risk is the reluctance to focus on risk. It may just sound negative. There's also an assumption to the steering committee that they don't want to be presented with any threatening statements about a potential project failure, and they only want to hear good news. The project is not about good news. The project is about delivering the best outcome for the business. And sometimes you just have to be truthful and honest and say there is a potential because off x wise it and the project could go in the wrong direction. Never, ever glossed over the risks because somebody is just inclined toe want to hear the good news or waiting too long and then taking a reactive approach when the risk arrives. Weeting actually all scrambled together, and we start in the panic mode to do something about it rather than pre assume what could happen and then take action beforehand, not when it happens. 10. Step 8 Engaging the Right Project Manager: welcome to Step eight, engaging the right project manager. Now let's talk a little bit about who that right project manager person is. What is required off the project manager. Have you appointed an experienced project manager? That's the question that we need to answer. Good practices and experienced Project manager should always lead the project for large project. This should be a dedicated full time role. Full time and dedicated resource is will make sure that the continuous focus is kept on moving your project forward. In theory, all business projects should be led by the business, though many business functions do not have the required project management skills, the required experience or disciplined approach required for managing a project. A good working compromise, maybe to a point to people to work together in a partnership project manager and the use of representative. This comprehensive nature off these two roles should never be underestimated. It works very well for many businesses and for many projects, but it's not the only way it can be done. There are some top five project manager traits to manage the how off a project it requires . A collaborative management style. It also requires adaptability, the person has to fit in with the picture. It's also helpful toe. Have some figure it out. Resourcefulness. Highly developed communication skills will enter that trade for a PM, and there has to be a great deal off flexibility. Nothing is ever rigid or cast in stone. The PM has to be able to move with the project in different directions. But there are also 10 qualities that make up a good project manager. Now look at yourself and compare yourself to this list. Are you a successful project manager? Do you have to intend qualities or some off those qualities? Then you may need to work on some off those you don't have. Number one, a project manager, inspires a shared vision. A project manager is a good communicator. A good project manager shows integrity and enthusiasm as well as empathy. A project manager also has to be competent in what he or she does and has to be able to delicate tasks to those individuals. The resource is within the project. Project manager should also be unflappable, thereby calm under pressure and to have relevant team building skills. The project manager has do not dictate a team but worked with a team and build the team up toe work with him or her to successfully deliver that project and a project manager. Quality is also to have problem solving skills. Now. What are the common mistakes on project managers? Sometimes no project manager is being appointed to a project at all. That, of course, leaves the project similar to a ship in the open seas without captain or the project manager is appointed, who has no previous experience off managing any type of project, never mind a small or large one and sometimes miss taken enthusiasm for experience or seniority for experience. Just because somebody is enthusiastic and has been longstanding in the business doesn't mean he or she will be an ideal project manager or project managers appointed to lead a large project and then expert expecting him or her toe. Also manage and work on their existing responsibilities, such as that jobs on the B a U level and at the same time be responsible for managing this large project. Or sometimes businesses think, let's have to project managers working on this project, and they have more than one project manager appointed to one project. That usually creates a problem because project managers take ownership off the project. But they don't share that ownership with others. That just opens up a can of worms, where a blame culture may suddenly slip into the situation. When things don't go according to plan, the project manager is not fully responsible or accountable or end accountable for the project. That means some autonomy is taken away from the project manager to be controlled by somebody in the business again. The project manager is then left, sort of the go between something happening and not happening. But somebody else says I'm in charge off the project, but they're not. They are just taken on the role that it shouldn't have in the first place. So a project manager has to be responsible and accountable for the project he or she manages. 11. Step 9 Getting customer representation: step night getting customer representation. Do you have experienced ineffective user representation on your project team? Good practice says that an experience use a representative should be appointed toe work. In partnership with the project manager, the user representative will lead the user group and be responsible for all business information to the project. That means somebody will represent the business as a whole and work hand in hand with the project manager. It is important to keep the process user driven and ultimate ownership off. The project must rest with the business. You must make sure that you have enough use of resource is to drive your project forward. In the past, I found that sometimes businesses will set aside certain users or resource is toe work with me on a project. But they don't give them enough time out off that day to day activities to actually represent the business in the project. That can be a very difficult situation, and like I mentioned in one off the early episodes off this training course, I actually had to walk away from a project because I got less than 5% off user interaction for the project and that is a project that is doomed to fail, so make sure the enough user resource is is provided to drive your project forward. If this is not available, you should stop the project following no surprise approach with your user group. Maintain a regular communication and tell them like it is. It's no good glossing over anything that's important to be shared with your resource is or your user group. Common mistakes are that insufficient user resources are made available. Remember, it has to be a good level off interaction in your project from the user group or the resource is to drive your project. If that is not available, your project will fail. Use a representative only available on a part time basis is an absolute no no. Underestimating the amount of user information needed during all stages off the project is also a big warning signal business information ending without a user requirement specifications. That is a common mistake businesses make where they have no user recommend requirements specified for the project as a side note. As your project moves into the design, the development and use a pilot stages considerable and continuing business information is needed to define any requirements at a lower level of detail and to answer the many questions that rise for your project. Make sure all those are cleared up so you know exactly which direction your project is going. And once again, I can't say it often enough. Stay clear off any years of re sources that are not willing to be part off the project team or who are not being allowed enough time to be part off the project team. 12. Step 10 Defining Team Roles and Responsibilities: Welcome to Step 10. The definition off team roles and responsibilities within your project. Ask yourself the question. Have you clearly defined the project team rolls and the individual responsibilities? The good practice here says that a project manager must ensure that all roles and responsibilities within the project are clearly defined for the whole off the Project. Three. Organizational structure Within the project team What is a project should be kept a simple as possible. Now, the following structure that I'm going to outline works well on small and even large project, and it starts off with the executive sponsor. We already mentioned that person earlier on in the program, but let's just summarise what this responsibility for the executive sponsor entails. Firstly, it has to be the highest ranking manager on the project. He or she will ultimately be the vocal champion for the project at an executive level. He or she also has the power to secure the budget for the respective project, and he or she is the final decision maker for the project. The next part or person with in the project team is your business sponsor. He or she is the champion off the project who will receive the regular updates off progress within the project he was. She also approves the project's goals and objectives that we are setting out well that has been set out in the project definition. He or she attends regular project review meetings and is also an important decision maker for the project. He usually also steers the steering committee. The steering committee is the project board, and it's composed off senior managers from the business. The steering committee, as a group of people, is responsible for the oversight, the control and the key project decisions. By default, a steering committee meets usually every 4 to 6 weeks, but that it's liquid. So if it's a really huge, huge project, they could meet more often. If it's a project that is easier managed, they can meet even later than six weeks. But it has to have regular meetings to keep on track with the rest off the team to find out . Are we on track? Is everything going according to plan etcetera and thereby their help to resolve any issues they approve? Any last scope changes that may need to come in even though we don't really want to have scope creep appearing in the project, but they also offer guidance and direction off where the project will be going. The next bunch of people involved in the project is the project team itself who are responsible for the planning and execution off the project. These people are usually led by the project manager, who also reports to the steering committee. A project team must include the user representative in some cases even include vendor representatives when it's an installation off a new I T system, and it should also include any technical expertise as a representation. So if it's a new system that's being implemented, not only do we want a representation from the from the vendor off the system, but also highly technical people who can easily understand and explain what's happening at any given time. The next group of people is the user group. They are led by the Utes are representative. That is part off the project team and it has to include subject matter expert or SMEs from the business. So the user group, let's say we're doing a change for HR. It needs to include people from a jar. If it's wide of like reaching and it includes accounting or finance. It includes marketing. Then we have to have user representation from knows SME areas in the business. All those sm e subject matter expert people to be part off the user group. They are also responsible for the user acceptance testing off the new product or service that being implemented as part of the project. And if, as I said, there are vendors because we're installing a new I T system. They are the ones who are contractor to supply the products and services to the project, so they need to have a voice in this project team as well. The roles and responsibilities for managing the project must be fully documented, and they need to be adapted to the suit the size and complexity off the project as a whole and to meet and fulfilled skills within the organization. There are obviously always common mistakes that can be made. For example, there is no clear ownership for the project that would really be a problem, or there is a lack of leadership and commitment from the steering committee. Remember earlier Runner told your little story off where I was in a previous client situation where I didn't have that commitment, and I decided it's not going to work for me. I'm not going to put my head out on the block. So if there is a lack of leadership or commitment from the steering committee, that will be a big problem. If the roles and responsibilities are not clearly defined. That also is a problem in the sense that people will just do what they want to do or not do what they're supposed to be doing. And it's like little hands in a big heap, and everybody just runs after their own interest. That also is jeopardizing the success off the project. And if there is a disconnection between the project team and the steering committee, such as discussions not being open and honest, and things are being held back rather than being up front and say we have a problem, let's sort this out and it's brushed under the carpet That ultimately may lead to the failure off the whole project or huge gaps in the project that are being attended to. And if the business sponsor fails to attend our schedule project review meetings, that is a big warning sign that there is no commitment to this project and you are in some shape or form start to run blind. 13. Step 11 Getting the Right Resources: now in step 11. We need to get the right resource is for our project, and you need to ask yourself the question. Do you have enough experienced? Resource is good. Practice dictates that a major contributor to the success off a project is the availability off customer and supplier managers who have high levels off experience both in the business and with project delivery, and to have these people available right early in the project. Big projects require substantive and appropriate resource is dedicated. Resource is provide the time to think it'll through and to correct and guide the project in the direction it needs to go. Two or more people equal different experiences. They have professional networks, and they have a healthy debate. If it's just one person taking control of everything, we are going in a single line, and we may not get the open and broader view off the whole project. As it stands, getting good people appointed as dedicated resource is for your project in the early stages is a tough challenge, and some compromise may often be necessary in reality if only a minority off areas or departments provide dedicated resource is on a part time basis. This also may add to the overall time scale for the project to be exceeded by up to six months. Often the business culture and working practice may be heavily oriented to business functions, business as usual, and that may not always be conducive to the project based work and the team working within the project, the new Qatari said. Very cleverly. The challenge for the project manager consists off. Attracting the right resource is forming a cohesive team, keeping that team motivated, meeting individual aspirations and getting the work done, and all that within scope, cost time and customer satisfaction. Now that we know what good practice it looks like, common mistakes can be made, and that usually is around. Not having experienced, committed resource is from the business or the appointed resource is are over committed, and they're unable to devote enough time to the project. They're being asked to partake off resource requirements. Exceeding the resource availability is a red flag or a warning sign that we need to look at our team once more to make sure we have those right. Resource is in our project. Once we've Coverdell that and once we've got the definition the initiation and planning stages completed. The project is then ready to move on to the next stage, which is called the Monitoring and control stage. And we're going to be looking at all those parts within that stage to make sure that we don't miss anything off importance. 14. Step 12 Monitoring and Reporting Progress: welcome to Step 12. Monitoring and reporting progress are you monitoring progress regularly? Is the question you should ask yourself because your product plan should be monitored and updated every single week. This is important, since tasks are sometimes underestimated and many new task will be identified as the project moves along. This is commonly referred to as rolling wave planning. This is when you planned down to the level of detail currently known, but then you go back later on to plan deeper and deeper. Once more information has bean quiet. Usually rolling wave planning needs to stay ahead at least 2 to 3 months. But this may obviously vary slightly, depending on the industry you're working in and the project size that you're working on, Joy Gums once said. If you create plans in the beginning off a project, put them in a drawer and forget about them, my brother creating them in the first place. In poorly run projects, problems usually can go undetected until the project fails. It's almost like the drip drip drip off a leaky underground pipe. Money is being lost along the way, but you don't see it or notice it until there is a massive explosion. So here are the common mistakes. Project plans never get updated beyond the first draft. So much time is being spent in creating the draft off the project plan. But then it's forgotten about and never looked at it again. So it just runs along. According to the old plan. This is a huge mistake, since, as I just outlined, new things will be added to the plan Deeper and deeper tasks. They may become apparent as the project progresses or using non binary milestones. So they're not clear they could be this, or they could be that. So once you have no clear definition off milestones, you have no way of knowing if you are on track or you're lagging behind or you're completely, completely drifting off. Tangent reporting task may also be marked as partially complete. Low level task by default are not complete and tail or not signed office complete until they are completed, so they either 0% or 100% there is no 2015 30 50%. Low level tasks are either done or not done and ignoring warning signs and pressing on in the hope that everything will turn out light in the end is another huge mistake. Here are some off the other warning signs that you can look out for the number off Open issues continues to rise. That means it's become noted that there is an issue, but nobody seems to be taking care of it, so that list off issues becomes longer and longer and longer. And that's a clear warning sign that something is going a straight or another one is that your contingency plans are running out faster than the raid off progress on the project. So that means if you have plan A, which is your main project, but you have a fall back, which is Plan B or Plan C, and suddenly you're running out of Plan B and C, But progress on A is virtually non existent. Then you are running into a dark corner, and you really need to screw back and start again, looking at where you are, what's being done, what hasn't been done. What are the issues that are still outstanding and get to action upon that before your progress. Further along the project, 15. Step 13 Communicating Project Progress: Here we are. It's Step 13 communicating the project Progress. Ask yourself the question. Are you distributing regular progress reports? Since progress reporting is an important our part off a project management regular reports , anything that you can think off from a weekly to a monthly should be issued to your executive sponsor, the business sponsor, the budget holder, this steering committee, the project team that here's a group and, of course, circulated to all other interested parties in the project. That means anyone who has an interest minute or largely in the success off the project you're working on. But the report should be as brief as possible. It shouldn't be a 50 page document, but it needs to summarize all relevant key points. This ensures that all people involved in the project and interested in the project are being kept informed, involved and committed to the success and the outcome off the project. Frequent communication for the project is essential, and it's essential for the well being off any type of project, no matter how large or small. Regular progress reporting create a valuable written report or record off the projects life and later wrong. When the project is finished and other projects come along, it can be referred back to it. When another project is in the planning, there are 10 points that should be considered for the progress report format. Ideally, it shouldn't be any longer than two pages, and these reports, as I mentioned, can later on be referred back to and decide upon how to improve the running off any future projects. Metrics can also be developed to measure the project progress in any other way, such as earned value or activity flow statistics or whatever else the company seems off interest or value to the project format. So the 10 points that need to be included is number one. The report date the actual project status, which sometimes is in a traffic light system where we have rent green or amber. We have to project summary the key issues encountered as the project goes along. Any risks that were identified, any tasks that have been done or in progress off being done and any next steps, any decisions that are currently unclear or need to be taken, any key future dates and milestones that we working towards where we are in the budget it cost aspect for the project and the spend to date. Once we've got all that, as I said, put that in the report no longer than two pages and easy to digest. But there are sometimes common mistakes that happen within that reporting process. Number one we picked the wrong what poor communication channels. We need to be sure that the people who are receiving our report off the right people, we also sometimes like the honest communication, and we're not asking for help when it may be needed. The lack off honest communication goes around the point off the traffic light here below the unwillingness toe also communicate bad news. Sometimes we shy away from sharing with our audience that there is something that's gone horribly wrong, or something that is being overlooked, that now has an impact. But by not being honest and open about where we are, we try to sort of gloss over it or we leave it out completely. That is not a right way to approach this project progress plan or outline off. The report should always be transparent, so make sure the good and bad will be in your progress report 16. Step 14 Consultation and Leadership: Now we're looking at Step 14 consultation and leadership. And here is where you asked the question. Are you achieving the right balance, off consultation and leadership during all stages off the project, there should be a white but consultation with many parties. However, the project should ultimately be controlled by a small and dedicated core project team, which is focused on achieving a concrete result. This, in turn, will make sure that when difficult decisions have to be made, they are made clearly, forcefully and quickly engage in lots of consultation but avoid having too much democracy. Ultimately, if you want to achieve real business results in a realistic time frame, the small team operating on strict principles is more likely to succeed than having large committees acting like talking shops. This is especially important for regional cross sectional and global project management. Common mistakes here include making a decision and then start a debate. Once you've made the decision, that's it. The decision has been made. Don't start, then discussing it, milling over it for hours and days and weeks on end. Just make the decision and go with it. Another mistake would be that you don't get the rial agreement and then later on down the line, you have to go and revisit the issue and that people fail to stay focused on the goal in hand. And again, here's the unwillingness to communicate bad news. Make sure that you are staying true, honest and transparent on everything that you do. 17. Step 15 Collecting Realistic User Requirements: Welcome to step 15 collecting realistic user requirements. Ask yourself the question. All the user requirements realistic good practice here will say. For many projects, the total set off user requirements can be ambitious, making it difficult or even impossible to deliver a solution that meets all the requirements in a way that is robust, cost effective maintainable and can be rolled out quickly to a large user base. It is important to make sure that you matched the user requirements specification against the available technology and the solutions, which can be then implemented in a timely, robust and practical way. This may result in an agreement that some off the requirements let's say 20% may not actually be delivered, but such a compromise will make sure that the remaining 80% can be delivered quickly. This compromise is important for global projects with large user base is on such projects. The speed and ease off any implementation is an important consideration in creating and delivering the overall solutions. There are 12 simple rules to gathering user requirements. Number one don't assume that you know what the customer wants. Always ask Number two. You want to involve that users right from the start. You want to define and degree on the scope off the whole project and thereby to ensure that any requirements are specific, realistic and measurable. You need to get clarity if there's any doubt. If anything is not clear, you need to make sure that you get it sorted beforehand, creating a clear, concise and thorough requirements document and share it. Then with your customer base number seven. You need to confirm your understanding off the requirements with the customer by playing it back to him or her avoided any cost talking technology or solutions until all the requirements are fully understood. And get those requirements agreed with the stakeholders. Before your project starts, go forth and create a prototype, if necessary, to make sure that you can confirm or refine any off the customer's requirements. You is a recognized notation, such as a unique modelling language, the UML for modeling the software and then cross check the software design against the requirements and review them regularly and in an ongoing basis. Common mistakes at this stage could be basing a solution on complex or new technology and then discovering that it cannot easily be rolled out into the real world or not prioritizing the user requirements into the Moscow principle. The must have the should have could have and they will not have. Or you may not have enough consultation with the rial users and practitioners who will be using the new way off Working. Solving the problem before you know what it is is probably one of the biggest mistakes at this particular state in the project management process and lacking a clear understanding and making assumptions instead off asking for clarification. Remember, we said that right in the beginning, off the common mistakes if you don't have to clarity, find it. 18. Step 16 Defining your Approach: Step 16 defining your approach. That means have you based your development on a prototyping interrogative approach. Good practice will say developing a prototype will help you breathe life into the requirements gathering process. People by default may find it really difficult to engage in a dry, written document whereby his screen based prototype can bring a debate to life. People can visualize what they actually dealing with more easily than reading a dry and boring document. Context off prototype Development approach glossaries defines this as prototyping involves feedback from customers to develop us on a trial based product. Each time a new prototype is released, it is usually an enhancement off a previous one, the evolutionary prototype often becomes the final product. Prototyping was first recognised as a software development approach when developers found that they couldn't figure it out, what the requirements were until the work had actually started on the project. Another way. You can look at it and say, OK, let's look at the car industry before they're released a new car, they don't just go and draw it and built it and then say What do you think they go and prototype it? They create a mock up off what the final car will look like. They will give you examples off what it could do and will be able to do once it's going into production. This is how we look at it in project management. We want to use a prototype to bring something to life that otherwise is almost in everybody's imagination or in a drive document, and they just have to visualize it from reading it. Basing the development on a Siri's off prototypes, though, will help to create a perception off early delivery to the users and creates the feeling off involvement in and a commitment to the development process. You should involve a large population off USA's in any prototype reviews as early as possible. This ensures that the large percentage of users will already have seen the system through demonstrations and training sessions before the actual Goal Life date, and it provides a high level of confidence the system will meet end years of requirements are end user needs, and it highlights early on any problem. Areas that may need more attention by skipping this important step in going straight to build may actually result in a fast expense and a costly rework. So common mistakes will be that we're basing our user requirements on a large, dry and over technical document only, or by not using an alternative prototyping approach and that by not involving riel, end users and not enough of them. 19. Step 17 Conducting Structured Testing: Step 17 Conducting structured testing. Ask yourself, Have you conducted structure testing or have you at least planned for it? Good practices. You should test any deliverables early. One of the fundamental lessons drawn from delivering I T project is the later you leave the testing in the development cycle, the more it will cost to fix any issues or problems later on. The structure testing plan should be developed and then executed by people who are independent off the development team. Besides testing the deliverables, you should also test the overall infrastructure over which the deliverables will actually run. The major components in the architecture should then be tested before building the final deliverables. There are five main test development cycle elements that we need to look at. Number one. It's the testing plan or the test plan. Number two is the test specifications. What are we actually testing? Number three. Check the code and test the code number four, validating the test itself and number five running the actual tests. A test documentation is a necessary tool for managing and maintaining the whole testing process. Documents produced by the testes should answer the following questions. What is to be tested. How are we going to test it? And what results do we achieve at the end, off the test or with individual cycles off the test? Frank Paul said. When end users get involved in the final stages of testing, light boast will go on, and they often become noticeable when the ah ha moment happens. Unfortunately, that is often too late. The common mistakes when we talk about testing is that there are no test plans and therefore no testing takes place. We're just going to roll out the system and see what happens. It's likes flowing matter the wall and see what sticks testing conducted in an at Hawk unstructured way to be done by the development team. That again, is not how we want to approach the testing for a new software installation, or we wait until the deliverable is deployed before we actually consider testing that is more or less in line with the first point off not doing any testing before. Roll it out or we utilize outcomes engine see time and use that is testing time again. That should never be the case. The testing time is a separate entity by itself, and we should never cut into any other planned time in our project process to make up for that loss. Documentation or testing stages are sometimes cut short or left out completely to make up for lost time in our project, that is an alarm signal that will cause you not only cost but potentially fail your whole project. 20. Step 18 Creating an Implementation Plan: welcome to Step 18 creating an implementation plan. Ask yourself, Do you have a comprehensive implementation plan in place? Well, the good practice once again says for a large project with white user base, the implementation stage can often be more complex and time consuming than the actual development stage. The implementation stage can often benefit from being treated as a separate project on its own. The following idea is I want to share with You are worth considering, especially for large projects whereby you're introducing new business processes across multiple science and across various areas off the business. Number one. The implementation should be carried out by people who will live and work where the new system they will have, therefore, of strong invested interest in getting it right from the onset. Number two. You want to conduct a company survey for each site that meets the senior management, gained their support and fully understand the local working practices. This will help to make sure that new processes are fitted into the system seamlessly to the existing processes and thereby avoiding any nasty surprises early in the stage rather than too late. Number three, An implementation event for each science should include a presentation by the chairperson to the rest of the company to show the strong support from the top down off the organization. Number four is the comprehensive training for all yearsas with different sessions. If the process involves different types of users, such escape keepers, project leaders and team members realistically could never have enough training. And it's better to split training into several short sessions, such as providing a basic training and then maybe to follow up sessions or monthly intervals. Something that I've done in the past is to drop in sessions or bite size sessions where we take one tiny aspect off the new system that is potentially causing some confusion or some on sureness amongst the people. And we work with just that one particular action. So to make sure that we really embed the new knowledge and the new ways of working on the system Number five for multiple site implementations, why not use the idea of a showcase event where the conditions such as user by in the expertise and the motivation are good or even high? And a successful showcase and a showcase event will help to prove that the system and the processes are working and thereby the whole event will act as a centre of expertise for the remaining business sites or business areas. Number six. For multiple company implementations, you might want to consider running several workshops for the implementation stuff to allow them to learn from one another. A little competition between each different company or company area also helps to spare on this new implementation. This approach will help to make sure that any problems are results fast and that other team members quickly move toe. Also help removing any falls problems because force problems is where one person thinks, Oh, this shouldn't happen, whereby in the new scheme of things off the process that's being changed, this is actually now the new way off Working Number seven. Consider special measures to track the implementation progress. For example, you might want to use a traffic light system in this case gold, grey or black lists because people do not like to be singled out as poor performers. For this approach toe work, though, you must select a few simple key measures that cannot be challenged. It also has to be a scrupulously fair, objective and reject all bribes. Common mistakes in the implementation stage may include the failure to involve the end users. Remember these other people who will be going down the road with the new processes, the new ways off working the new system. And if we fail to include them at this stage, they will be struggling or even discount the value that's been put into the new ways of working into the new processes and into the new system. Furthermore, we must ensure that we have enough training so in adequate training, will not be a benefit long down the road, since people will be struggling and very quickly find ways off either cheating in the new system. If there is a gap to do so or more importantly, try to avoid using the system full stop. 21. Step 19 Conducting the Post Implementation: Step 19 Conducting the post implementation. Ask yourself, Have you conducted your post implementation review yet? It's good practice to go back and review Aled the progress made in delivering the project deliverables and the overall business benefits realization. The post implementation review should be time to allow final improvements to be made. To get the best benefits from the project as a whole, organizations are beginning to recognize the growing importance off knowledge management as a key to competitive advantage. We must therefore become better at capturing our learning and making this information available to the rest off the organization. This will increasingly become the duty off every manager and as a project manager, you are in the unique position to help your customers to gain the benefits detailed in the original business case. It may be an extra face once you have close to project or you can run it as part of the project itself. It may not follow on directly from the project end, and it may start a short period of time there later on. But before the post Implementation review, which typically takes place 3 to 6 months after a project has been completed, so we'll give it time to set down embed into the or user audience. And at the end of the day, then we go and find out. Is it delivering what we're looking to do? Opinion, though, seems to be divided as to whether active benefits realization is the domain of a project manager. But many projects declared a success, never actually delivered the plant benefits or the results that they wanted to achieve with the project. At the end of your projects, hold a formal debrief session, including a post implementation lessons learned review with the project ING. Common mistakes here could be to forget what has been done and discard any useful experience that has been gained on a very challenging project. Another mistake is that people are so relieved to finish, and it's time to just move on without taking time to review the project result. And one last one is to disband in the project team too quickly before the learning has been captured. That means we're letting people go before we know what their struggles were along the project and also what their successes were along the project. So next time, when we have another project. We can refer back to what we did well and what we should be doing differently to not re encounter the same headaches and problems and issues. 22. Step 20 Realising the Business Benefits: Step 20. Realizing the business benefits. Will the deliverables and benefits off your project survive on most projects? The team was disbanded soon after delivery. This can result in the solution implementation withering away, dying over time, especially if it has fallen on a stony ground. This can be true for any project that involves a change in working practices or revised business processes. A project should only be considered complete when the business benefits have been delivered and not when the project has been delivered. This will make sure that implementation problems are being so resolved to gain any benefits . There has to be a change, John Thorpe says. People must change how they think, manage and act in order to implement the benefits. Realization. Approach. Changing the way your people think work and manage is not an easy task. But without it, your project is in danger off joining another long list off successful project deliveries that never realized their expected benefits or results. You will need to have a dedicated change manager in your project team who will help to support the people aspect off the business change. This is very often overlooked or rammed into one when you look at the open job market very often, a project manager is the job title that people are recruiting for. Very often, though, the change aspect becomes a role for the project manager as well. It should never be lumped into one. They are very different strands. One is the project deliverables, the business benefits realization. But the change manager drives the people aspect involved in the whole project. That's a really important area not to overlook the realization off. The benefits can only be done if change takes place. So common mistakes he are that believing that project is over once the delivery and implementation has been done or expecting benefits, toe automatically a drop out of the project without any further effort and lastly, expecting benefits to stick without managing the change aspect where people have to change their ways of working and change follows the implementation 23. Step 21 Learning the Lessons: Step 21 Learning the lessons. Ask yourself. Have you looked at the lessons learned from your project? Every project has a potential to help your run future project even more efficiently. You want to take time to assess the project, whether it was a great success, the total failure, what, somewhere in between, you want to concentrate on the big, important lessons from the project, the ones that will have a significant impact on any off your future projects. But there are two common problems preventing us from learning valuable lessons from our past projects. And they are that we think the lessons don't apply to us. And number two, we want to get things done and finished. History, unfortunately, has a strange way of repeating itself. If we don't take the time to learn the lessons off the past and also act upon them, we will continue to commit to the same mistakes again and again and again. Don't ever think this won't happen to you. Trust me, it will. So here are some common mistakes. Being too busy to evaluate project when they have finished or reevaluating what was done in the past and then ignoring what we've discovered another one is moving on to your next project Before you reviewed the last, failing to learn lessons from past projects will usually come back to haunt us. Overall, stop and avoid making the same mistakes time and time again and not making lessons learned available to other people in your organization will potentially recreate the problems that were already encountered in previous projects. 24. Step 22 Celebrate the Project Success: well, here we are at the end off this training course we've reached Step 22. It's to celebrate the project success. You've done it, you're there. The project has bean done. It's all delivered and everybody has happy. And it's time to celebrate. Put on the music, have. But before moving on to your next project, it's worth spending time to celebrate your success. It provides a great way to say thank you to your team, and it helps with their and your own self motivation. Always publicize your successes, both inside and outside off the organization. This will hate help to raise your own and your team's profile and credentials for future projects. Don't ignore the team and the hard work that everybody put in to make your project a success. Let's quality on. But some common mistakes can be made here, and that's usually some ignorant project managers or businesses will not be paying the recognition to the project team. That's a big mistake, because next dollar project comes along. Whoever wants to be part of the project will probably shy away because they're not feeling valued from the last project. So let the party and I wish you all the best for your next project. Thank you very much for being here and allow the best good luck.