ultimate project success

Upload: vittorio-barattini-tenti

Post on 13-Oct-2015

27 views

Category:

Documents


0 download

DESCRIPTION

Project Management Success Guide

TRANSCRIPT

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 2

    Legal Disclaimers

    All contents copyright 2011 by Louise Ledbrook and http://www.ProjectCommunityOnline.com. All rights reserved. No part of this document or accompanying files may be reproduced or transmitted in any form, electronic or otherwise, by any means without the prior written permission of the publisher.

    This eBook is presented to you for informational purposes only and is not a substitution for any professional advice. The contents herein are based on the views and opinions of the author and all associated contributors.

    While the author and all associated contributors have made every effort to present accurate and up-to-date information within this document, it is apparent technologies rapidly change. Therefore, the author and all associated contributors reserve the right to update the contents and information provided herein as these changes progress. The author and/or all associated contributors take no responsibility for any errors or omissions if such discrepancies exist within this document.

    The author and all other contributors accept no responsibility for any consequential actions taken, whether monetary, legal, or otherwise, by any and all readers of the materials provided. It is the readers sole responsibility to seek professional advice before taking any action on their part.

    Readers results will vary, based on their skill level and individual perception of the contents herein, and thus no guarantees, monetarily or otherwise, can be made accurately. Therefore, no guarantees are made.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 3

    Table of Contents

    Legal Disclaimers ........................................................................................................................... 2

    About the Author ........................................................................................................................... 6

    Introduction ..................................................................................................................................... 7

    1. Not Taking the Time to Set-up Properly ........................................................................... 8

    2. Failing To Adapt Processes, Methodology and Approach to Project Size and Type ................................................................................................................................................... 10

    What are Fishbone Diagrams? ..................................................................................................................... 11 Brainstorming ................................................................................................................................................... 11 Gantt Charts or Critical Path Analysis Flow Diagrams ......................................................................... 12

    3. Roles and Responsibilities .................................................................................................... 13

    4. The Project Team Doesnt Really Know What The Client Needs ............................ 15

    5. Communication and the Rule of Three ........................................................................... 17

    6. Openness With Information ................................................................................................ 19

    7. Unrealistic Management Expectations ........................................................................... 20

    8. Time-Stingy Project Leaders................................................................................................ 22

    9. Poor Requirements ................................................................................................................. 23 4 Characteristics of Good Requirements ................................................................................................. 25

    10. Scope Creep ............................................................................................................................ 26

    11. Analysis Paralysis ................................................................................................................... 29

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 4

    12. Poor Management of Team Dynamics ......................................................................... 32

    13. Non-Acceptance by the Users/Those Affected .......................................................... 34 Resistance to Change ..................................................................................................................................... 34 Non-Acceptance of Deliverables ................................................................................................................ 35

    14. Underestimating the Time It Takes ................................................................................ 37

    15. Conflicting Requirements .................................................................................................. 39

    16. Admin Overheads For Key Resources ........................................................................... 41

    17. Key-Man Risk Not Managed .............................................................................................. 42

    18. Inadequate Change Control Process and Version Control .................................... 44 Business Evaluation ......................................................................................................................................... 44 Project Impact Analysis .................................................................................................................................. 45 Version Control ................................................................................................................................................. 46

    19. Overheads - Conflict Between the PMOs and Stakeholders Needs For Reporting ........................................................................................................................................ 48

    20. Choose Your Team Members, and Dont Be Afraid To Let Them Go ................. 49

    21. Uninterested Stakeholders Lead to Project Failure .................................................. 51

    22. Not Holding Strong On What You Know Is Right ...................................................... 54

    23. Quality Outputs ..................................................................................................................... 56

    24. Insufficient Change Impact Analysis .............................................................................. 58

    25. Uninformed Stakeholders .................................................................................................. 59

    26. Testing and Usability ........................................................................................................... 61

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 5

    27. Training and the Rule Of Three ........................................................................................ 62

    28. Are You Ready for the Change? ....................................................................................... 63

    29. Rollout and Implementation ............................................................................................ 65

    30. Excluding Project Team Members from Assessments ............................................ 67

    In Closing......................................................................................................................................... 68 Let Us Know What You Think ....................................................................................................................... 68

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 6

    About the Author

    Louise Ledbrook has over 15 years experience in business and project management. She has worked in a variety of industries, from Government Departments and Fitness to Financial Services and Information Technology. Louise spent years working with organizations on their projects, ranging from small businesses to large multinational corporations. She has worked on small one-person projects to multimillion-dollar programs of work, allowing her to develop and grow her skillset in many ways. Louise now spends her time working with people and projects. She helps people in various project practices and

    organizations to run more effective, efficient and successful projects.

    Her mission is to help these people enjoy what they do and empower them to have more time to do what they enjoy.

    Louise Ledbrook

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 7

    Introduction

    A project is a number of processes that are guided by the project manager from the beginning to closure. It has a number of characteristics, all of which make it a project and make it the complicated body of work that it is. It is temporary, it needs resources of various types, it has a unique purpose, it should have sponsors, stakeholders or customers and it is filled with uncertainty.

    The idea is to complete a number of tasks within the constraints of scope, time and cost to reach certain results in the end. To perform these tasks adequately, you need information, communication and commitment.

    A project can be fraught with danger, with issues and obstacles at every turn. The dream of a smooth, issue-free project remains an everlasting goal for most people. On the flip side, project work can be extremely rewarding and challenging and offer you a constant creative outlet. You have the opportunity to help others and experience and learn many new things on each project youre involved with.

    Project management is a vast topic and many books have been published on the topic. However, people still make many mistakes and their results are mediocre at best. Yet they have no idea why. There are many issues that could lead to a failed project; unrealistic expectations; poor planning; poor leadership skills; the inability to bring a team together; and so on.

    The good news though, is that all these problems can be solved, and in most cases it doesnt require you to make any sacrifices. With a little forethought, organization and good planning, every project youre involved in can be a resounding success and the stakeholders and management will be more than pleased with your results.

    Read on to discover some of the most common pitfalls and mistakes you can encounter in managing a project as well as how you can solve these issues.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 8

    1. Not Taking the Time to Set-up Properly

    So, you have been put in charge of a project and stakeholders want to see results as soon as possible. You havent yet put together your team, but you are feeling the pressure to deliver something. You find yourself in a rush and dont take the time to plan or set the project up properly. You dont put any thought into the resources you need or how to organize the project and how it will run, because you are trying to do the work of a whole team by yourself.

    This is a recipe for disaster.

    Surprisingly, though, many projects start off like this. This need for instant results leads to many short cuts, with one person filling the role of many because the team hasnt yet been recruited. Critical steps are being overlooked or delayed and the whole project begins to suffer. And this is all just to pacify someone who wants results today instead of tomorrow.

    This is mainly due to management having unrealistic expectations, but also due to the project manager who doesnt say anything. Remember, if you want your project to succeed the planning stage is one of the most critical, followed by a proper set up. Unfortunately, most people forget this and then wonder why their project was unsuccessful.

    So, whats the solution? Simple. Take the time in the beginning! It doesnt matter how you do it or where you find the time. You simply have to find the time to plan and prepare before you start working on the project.

    First off, you need to discuss things with the stakeholders or management and explain to them that if they want the project to succeed they need to give you the time to plan properly. Without an effective plan, there is no way the project gets completed on schedule and delivers the desired results. Of course, this is an ideal situation and it wont happen every time.

    Thus, if you cant get anyone to listen to you, you need to plan in stages and set priorities. Make sure that you cover every aspect so you dont miss anything and plan the next stage as you are working.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 9

    Categorize all the tasks according to their importance. Set up the most important first, such as methodologies and strategies. These need to be established first to avoid later confusion. Then work through the tasks according to their importance.

    Make sure that you add milestones and accountability to ensure that you complete all the activities. This helps you to guarantee that you wont put them off. You will be accountable to someone else and will have to provide a report.

    However, you should do everything in your power to convince the stakeholders to give you at least a few days or weeks, depending on the size of the project, to plan and set everything up.

    The return on the investment of time will be exponential and, in fact, they end up saving both money and time, as there will be fewer problems that need to be solved.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 10

    2. Failing To Adapt Processes, Methodology and Approach to Project Size and Type

    All projects are unique. Each one has different requirements, a different scope, different deliverables and so on. However, many projects fail to adapt their process and methodology to reflect these differences.

    You cant expect the same methodology to work for every project you manage. Its like doing the same thing over and over again and expecting a different result. Thus, each project needs to be treated like a separate entity and your processes and methodologies customized specifically for the project in question.

    For example if the project you are working on were an organizational change program delivering the complete restructure of a department, then obviously there would be no need to complete a detailed functional requirements specification. Or a project that has a budget of only $100,000 is not going to require the same level of governance and controls as one that is running with costs of $10 million.

    So you can see that the activities and deliverables required for different types and sizes of projects should cater to the need, but the deliverable itself should also be customized to the project.

    You may have an upgrade to a piece of software, which is quite extensive and requires a yearlong project; therefore detailed requirements specifications must be created. However, if it were a software upgrade that had the addition of 2 fields to a screen, I would imagine the specification could be a lite version.

    A good way to adapt each project to its size and scope is by using a systemized approach.

    Good project professionals have clearly defined systems that are comprised of individual tasks that are interchangeable. This means each project can be scaled with the tasks from start to full completion with the click of a few buttons.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 11

    Flexibility is key and if the project manager or his assistant is incapable of being flexible then it will put the whole project in danger of failing.

    The use of a capable project management software tool, or a combination of systems and tools are imperative. These can be things you have created yourself or used in previous projects as a guide.

    I suggest you consider using one or more of the common tools used in project management to define what the tasks and deliverables required are: Fishbone Diagrams, Brainstorming, Gantt Charts or Critical Path Analysis Flow Diagrams for example.

    What are Fishbone Diagrams? Fishbone Diagrams are named after Kaoru Ishikawa (1915-89). Ishikawa was a Japanese professor and a specialist in industrial quality management and engineering. He devised the technique during the 1960s.

    Also called cause and effect diagrams, fishbone diagrams contain a central spine (much like that of a fish). The spin runs from left to right. Around the spine are a number of factors that help solve the problem or reach the outcome. Each project contains the main bones of the fish spine (these are the contributing factors).

    Brainstorming Brainstorming is crucial in project management and planning. Usually it involves a number of things, but generally a number of people come together to discuss things in more detail. The process is as follows:

    The group defines and agrees on the objective. The group agrees on a time limit for brainstorming ideas. The group uses the information to condense, combine, categorize and refine. The project steps are then assessed and analyzed for optimum effect and possible

    results. The project tasks are prioritized. The group agrees on a timeframe and takes action. The project manager takes over control, monitors the process and follows-up.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 12

    Gantt Charts or Critical Path Analysis Flow Diagrams Both Gantt Charts and Critical Path Analysis Flow Diagrams are specific project management tools used to take a project from start to finish in clearly defined steps (tasks).

    Everything is detailed with precision, leaving little room for failure. Therefore project managers around the world still actively use these tools today. This may be created as an outcome of your brainstorming session.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 13

    3. Roles and Responsibilities

    I have read many post implementation review (PIR) reports on rocky projects that have shown a lack of clear roles and responsibilities. It is essential that every team member has a clear role and knows what their responsibilities are. They also need to be accountable and understand what goals they have and how their role contributes to fulfilling the team mission.

    If team members fail to clearly understand what his or her roles are, it eventually leads to team conflict. Everyone ends up running around trying to do everything, but nothing actually gets done.

    If a team works well together, they are highly productive and their performance borders on excellence. On the other hand, if there is conflict and team members are dissatisfied, their work suffers and the outcome of the project will suffer. For this reason it is essential that everyone understands what their role is and that everyone involved in the project is aware of their responsibilities.

    For every project complete the following:

    1. Define the key activities and outcomes for the type and size of project. This will help you understand what skills you require.

    2. Define what the types of skills/roles are required.

    3. Complete a Responsible, Accountable, Consulted, Informed (RACI) matrix for key tasks and deliverables.

    4. Complete brief role descriptions for each role. These are brief overview paragraphs. This can be used to communicate to various groups involved on the project what key functions each person has.

    5. Communicate to the project team and stakeholders the roles and responsibilities and who holds the role. Share the RACI with those in it.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 14

    The project managers coordination of team members activities must also align to the defined roles and responsibilities. If the project manager asks team members to do tasks that are normally allocated to another, as per the agreed Roles and Responsibilities, they will just create confusion; distrust and conflict within the team. Therefore its important you lead by example.

    A large or a long running project may change form and team composition numerous times throughout its life, so you will need to perform this process numerous times throughout the project. It is not a set and forget task.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 15

    4. The Project Team Doesnt Really Know What The Client Needs

    A good business analyst is essential to accurately define the scope of the project. Without an accurate scope, there is no way for you to complete the project to the clients specifications, even if the client is the one who proposes the solution.

    However, the problem is that many business analysts take what the client says at face value and do not delve deeper. Many clients arent really sure what they want or have an idea that might not actually meet their needs, but they heard someone used the system successfully for their own business so they think its a perfect fit for them.

    Thats why you should never simply accept the clients solution without ensuring you have a good understanding of the underlying problem. If you arent aware of the real issues that need to be resolved, you can end up with a deliverable that doesnt solve the problem or is only a temporary solution, which will lead to the client blaming you.

    By understanding the real problem you are able to more accurately define the scope of the project, which leads to fewer changes down the line, making life easier for you and resulting in a real solution to the problem.

    If you simply accept the clients proposed solution you can expect to spend a lot of time redoing work, and changing the project mid-stream, because none of the parties involved actually understand what the real goal is.

    You must be able to accurately articulate and have the client sign-off on:

    Problem Statement: What is the real problem youre trying to address? E.g. there is no way to track and manage trends of injuries on our ships.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 16

    Success Factors: It is important to be able to articulate what success looks like with a measureable description so you can test that the resulting solution links to the success factors description, e.g. we will have a means to identify areas of high risk and reduce injury occurrence on all ships.

    Objectives and Goals: What are the key objectives of each stakeholder? E.g. Stakeholder one would like to reduce broken arms by 10%, Stakeholder two would like to see all injuries gained on the masthead.

    The answer is to question the client intensively and ensure that you have a good grasp of all the project aspects, including the problem and the desired solution.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 17

    5. Communication and the Rule of Three

    Communication is the foundation of any successful relationship, whether it is personal or professional. Of course, this also applies to projects, where many people are involved. Thus, you can never have sufficient communication. Remember, sometimes it takes repetition for an idea to stick.

    Therefore, you want to communicate as often as possible. It can be done either formally or informally and in some cases both options are a good idea. The key is to ensure that every team member understands their role and what the desired outcome of the project is.

    Those affected by the outcomes of the project need to understand what the project is going to deliver, when and how it will affect their lives and what support will be provided to them. Additionally, stakeholders and other areas or departments working with the project also need to be aware of the progress and status of the project.

    Ensure you create a communication plan from the beginning, outlining whom you need to communicate to and what they need to know. This plan will grow and evolve over the life of the project.

    The more communication there is, the more smoothly the project will progress. This is also a way for you to protect yourself because if everyone is aware of all the issues and you have proposed solutions, there is no way for you to be blamed if the project is not successful.

    Remember, effective communication is vital to a projects success. Never leave anything to the last minute because then you will be the one to suffer as well as your team who might have tons of work to redo because the stakeholders werent informed of the progress.

    Communication can be done via different mediums. For example, when it comes to offering just the bare facts, then reports are your best bet.

    On the other hand, if you want an environment that is more creative, then meetings are a better option. Get creative with your communications.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 18

    You may want to create a great big notice board covered in colorful information, play videos with updates on the televisions around the building, or have drinks with speakers. Use your imagination. In any case, you want to have regularly scheduled team meetings and communications to ensure that everyone is on the same page.

    When you apply the rule of three to your communication you minimize the possibilities for failure. A good way to make it stick is by sending your messages three ways or three times. Research has shown that in some cases up to seven contacts are required to get a response, or for the message to sink in.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 19

    6. Openness With Information

    Transparency is vital to the success of a project. If you are uncertain of a certain issue or dont know how to complete a particular task, then you need to inform the people involved so that a solution can be found in a timely fashion.

    If you hide the problem, the likelihood of it backfiring is increased. Instead of working with your team to overcome the problem you end up running around in a panic to solve the issue on your own. This may be something that you cannot do.

    Remember that no one is perfect and there is nothing wrong with revealing to your team that you need help. In fact, its the best solution because two minds are greater than one when it comes to finding a solution for a problem. Ten minds are an even greater asset.

    Hiding the problem only serves to ruin the relationship with your team and stakeholders and you are unlikely to find a solution to the problem anyway.

    You should never assume that your team is on track with any of the tasks unless they communicate this with you. Information must flow at every stage of the project.

    Always ask them for status updates to keep the channels open or better still, use appropriate software to remove the hassle of to and fro communications by email. Better yet have a clearly defined and agreed process for communicating the progress from day one.

    Structure your team meetings in such a way that the important information comes out and is discussed. Use progress against the schedule and rising issues as standing agenda items.

    Create a comfortable environment within the team. Use openness and instigate a no-blame culture. Be open with management and stakeholders about how the project is progressing. If issues arise they will be comforted, knowing that you are capable to address these issues appropriately.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 20

    7. Unrealistic Management Expectations

    If theres one thing that most people agree on is that management often has unrealistic expectations of a projects delivery schedule and budget. The problem is that many project managers keep quiet and accept the expectations that are pushed on them without saying anything.

    They end up working themselves and their team to the bone, but are still unable to meet said expectations and deliver mediocre results because theyre rushed through the project. For this reason, it is imperative you communicate with management and make your case if you feel they are being unreasonable.

    Remember, the key to convincing management you are right is to provide evidence. Dont just say you cant do it within the budget and timeframe they stipulate. This sounds like you dont want to do it. It doesnt show them that you are speaking from experience.

    Instead, analyze the costs and time it will take for you to actually complete the project. Prove to the management, on paper, why the project cant possibly be completed how they want it done.

    Expect the management to try and negotiate, so give yourself some room. Its better to overestimate the time it will take for you to complete a particular activity or task than to underestimate it. Give yourself a buffer for the allocated budget and timeframe to ensure you dont have any issues later down the line.

    It is always a good idea to have considered alternatives prior to meeting management. If and when they start to negotiate you are in a position to put other options on the table. These could be to offer a phased approach, a promise to implement critical outcomes within their timeframe and then the others afterwards, or a reduced or modified scope option that could be implemented within their time and budget constraints.

    It is important here to hold strong. Show guts and be assertive. The person in that meeting who negotiates with management has the wellbeing of the whole project team in their hands.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 21

    If you are not able to come to a satisfactory conclusion about the outcome and management wont change their expectations, then fight back. Use your project management tools to the best of their ability. Raise high-level risks on day one and dont be afraid to make it a recorded issue. Communicate these on your status reports and report your project as red (in trouble) or amber (heading for trouble). You will be amazed how a big red circle on a status report can catch the eye of the right person.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 22

    8. Time-Stingy Project Leaders

    Theres nothing worse than dealing with project leaders who want everything done in five minutes flat. You sometimes wonder if these people live on the same planet as the rest of us. But anyone who has been involved in projects for any length of time knows that stakeholders, customers and even project sponsors tend to push for the project to be completed as quickly as possible.

    Dont fall into the trap of trying to give them exactly what they want because when you arent able to deliver you will be blamed for agreeing to the schedule.

    Make sure you accurately estimate the time it takes for each activity to be completed. Ensure that all factors have been considered and then add a 10% buffer. This guarantees there is no chance you will miss the deadline. If software projects are on the agenda it is recommended you add 20% or even up to 50% buffer for development. Many unknowns can occur in this phase.

    Of course, you will have to make your case to the project leader or to management and the best way to do that is with supporting documents. Dont say it cant be done in the timeframe they are asking without proof. Offer an alternative. It gives you a much better chance of gaining approval.

    If you simply say no, you sound like you are disagreeing simply for the sake of it. This often leads to conflict. On the other hand, if you offer an alternative, most people will relent.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 23

    9. Poor Requirements

    Poorly defined project requirements are not as uncommon as you might think and they are one of the main causes of project failure. Requirements are ultimately delivered by a finished project. If they are poorly defined then the whole project will suffer because the team isnt clear on what is expected of them.

    Common problems include confusion in regards to what deliverables are expected, a lack of communication between the customer and the project team in defining the requirements, vague requirements, a lack of prioritization, incorporating unnecessary functionality and so on.

    The key to resolving these issues is to ensure that the project manager consults with the customer or project originator to clearly define what their expectations are. Often, the needs your project addresses may not always be clear.

    For example, lets say that your project is meant to overhaul the financial system of your organization. The question is whether this overhaul addresses poor communication, a lack of organization or is meant to cut costs. This is why it is essential to understand the real desired results.

    The problem is that many customers reveal needs that arent relevant. It is the business analysts job to dig deep and discover exactly what the customers expectations are. This can be difficult because determining what people are thinking is difficult at the best of times. Sometimes people arent sure themselves what they want, at other times they prefer not to reveal their needs and sometimes they simply arent able to express themselves properly.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 24

    Some solutions to this issue include:

    Lengthy discussions or workshops with the customer, even if it means they keep repeating their needs. The more they talk, the better you will be able to understand what their expectations are.

    Clarify aspects you find unclear, even if you have to do it multiple times. Its better to ensure you fully understand what the client expects rather than walking away confused and botching up the whole project.

    Listen carefully to the client for any contradictions. If they contradict themselves, they might not be sure what they want and its up to you to point out the discrepancies so that you can resolve the issue, otherwise you might be blamed for poor results when the client simply wasnt certain what they wanted.

    Confirm the information you have from multiple sources. This could mean conferring with someone else from the clients team, or it could mean having another person from your team present when the discussions are taking place. This helps to confirm whether or not your understanding of the requirements is accurate.

    Use questioning techniques to dig down to the real cause or problems.

    Observe the client or user performing a process or using a system.

    Document the process. Understanding all the elements and people involved gives you a broader picture of the situation and environment, you may identify that the real root cause of the problem stems from poor quality information from a system used 5 steps ago in the process by another person.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 25

    4 Characteristics of Good Requirements 1. Ensure the requirements are clear, concise and measurable. For example, a requirement to

    improve customer satisfaction is not sufficient. You need to have a way to measure the success of the project. This can only be done with a measurable requirement.

    In this case, it could mean anything from being able to answer a customers question 1-second faster to improving system performance by 10%. You need to clearly define the requirement because if there are 10 people on the team, there will be 10 different interpretations of what the goals are.

    2. Ensure the requirement offer value to the project. In other words, if you were to remove

    the requirement in question, would the project change? If the project would remain the same, then the requirement in question is likely irrelevant and will simply add to the confusion.

    3. Make sure the requirement is stated in a way that everyone understands it. In other words,

    if five people read the statement, they should all understand the same thing. Diagrams, mock-ups and pictures are a good way to ensure a common understanding.

    4. The requirements need to be directly linked to the scope of the project. For example, if the

    scope of the project is to develop a new application that allows users to post to all their social media profiles from one window on their mobile device, then creating a list of the top five smart phones on the market is not within the scope of the project.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 26

    10. Scope Creep

    Scope creep is one of the biggest issues in modern projects because many projects never reach full completion stage. This isnt because the team is lazy or incompetent, but simply because the changes that are taking place far outweigh the progress that is being made. Simply put, the rate of change is greater than the rate of progress on the project.

    If the issue of scope creep is not dealt with properly, then the project becomes so big over time it turns into a huge burden for the team and never gets completed. Team members lose all motivation when they basically run to standstill. This is why it is essential for changes to be managed properly.

    An effective change control process needs to be designed, implemented and adhered to. An effective project change control process depends on a scope that is very well defined and supported by an achievable baseline plan.

    No matter how great your plan is though; remember that it wont do you any good if the scope isnt properly defined. Priorities need to be clear, the requirements need to well established, and a realistic project baseline with a clearly definite scope needs to be created.

    The goal is to protect the scope of the project, which requires a formal process to manage any changes to the specifications of the project.

    You need to inform the client of the importance of having a stable scope. You need to explain how any chaotic and poorly managed changes can derail the project and hurt the results.

    You then need to create a change control process. The key questions that need to be answered are:

    What will the effect be on the timeline?

    What will it cost?

    What are the benefits?

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 27

    The process needs to allow anyone to be able to propose a change. No matter from whom the proposal is coming from, they need to be able to provide a benefit to cost analysis. It is unlike in a court of law where you need to consider each change as being guilty before proven innocent. In other words the automatic response is to reject the change until the person requesting it can prove that it is imperative to the success of the project. Never accept a change unless it makes sense in a business environment.

    Changes can come from various sources, including from within the team or from the customer. When the suggestion comes from within the team you need to be even more wary. People often try to be too clever and come up with bright ideas that arent essential to the project, but will increase workload and put too much of a burden on the project.

    The changes that come from the customer or from management cannot easily be dismissed, unless there is a clear change control process in place from the beginning.

    Without a clear process that has been agreed upon from the beginning you will have a hard time saying no. Of course, a good process doesnt guarantee that you are able to deny the customer, but you have at the very least a greater chance of implementing changes that make sense.

    Each proposed change must be objectively analyzed to ensure that the benefits outweigh the costs. Remember to check how the changes in question affect the timing as well as the costs. Analyze any consequences that might inadvertently arise as a result of implementing these changes.

    Keep in mind that changes dont have to be accepted as they are or when they are proposed. As an alternative to outright rejection allow for the options to delay the change or to modify it. This way, some good ideas can be implemented, even if only a part of them make sense.

    You need to establish the people who are involved in the change control process and ensure that at least one person has the power to veto the decision. In other words, involve someone who has the power to say no and no one can overrule his or her decision. This is generally the project originator or a committee.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 28

    When you receive change proposals, ensure that all the relevant data is included and analyze each proposal in a timely fashion. This way you wont end up with a backlog of documents you have to deal with and accept changes without adversely impacting the schedule of the project.

    Make sure you update your team and communicate the changes that require implementation. Communication is essential to a successful project. This is why everyone needs to be in the loop and aware of what is happening.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 29

    11. Analysis Paralysis

    Analysis paralysis is a common problem in project management. It happens when the business analyst or team members get stuck in analyzing the data and never move further. The more information there is and the more complex it is, the higher the likelihood of you freezing up. When you focus so much on analysis you never move on to actually work on the project.

    The situation becomes even more problematic when the decision-maker, which is rarely the project manager but more often the client, takes their sweet time to make decisions for fear of making a decision.

    They end up over-analyzing and over-thinking the issue and when they do make their decision - even if it is perfect - it is often too late. And we all know a decision that happens too late can have a seriously negative impact on the outcome of the project.

    No matter how great the decision is, its better to have a timely decision that is not perfect than a perfect one that comes much too late.

    So, how can you resolve the problem of analysis-paralysis? Here are a few strategies that can help you.

    1. Remember the Pareto principle, also known as the 80/20 rule. The Pareto principle states that approximately 80% of the effects come from 20% of the causes or 80% of the results are generated by 20% of the work. This means that 80% of your results will be generated by 20% of the time you spend analyzing data.

    Prioritize the outcomes or objectives and focus your analysis on the most important or critical areas.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 30

    2. Set time limits for the analysis phase. If you leave the analysis phase open-ended, without setting a deadline, you find yourself wiling away the time. Before you know it you end up completely paralyzed by the analyses you think you need to do.

    The best solution is to limit the time you can spend analyzing information. If you know you only have a few hours to make your decision and analyze the information, you are less likely to get stuck.

    3. Understand that you will never be able to know absolutely everything about a project before you begin. You need to start with what you know and then build upward, making adjustments as you proceed with the project. You need to discover the information that is lacking and what obstacles are preventing you from moving forward, but this can only be done once you actually start work on the project. You need to create a good balance between forward movement and analysis.

    4. Employ the PDCA model, namely Plan, Do, Check, Act. The goal is to state the objective,

    gather the facts, create a hypothesis or plan of action and then act on it to prove or disprove it.

    When you take action you have more information on what is effective and what isnt, providing you with feedback. You can then analyze the results of your actions and decide what you need to change in your approach. Rinse and repeat until you reach the desired result.

    5. Perfectionism is detrimental to the completion of a project. You need to change your expectations from Perfect to Good Enough because if you keep pushing yourself to create perfection, you never take action because you always think you dont have enough information.

    6. The more decisions you make, the easier they become and the better you become at it.

    Remember, practice makes perfect. 7. Take the first step. Creating forward momentum is a matter of taking the first step. Once

    youve done that, you find the next ones are much easier.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 31

    8. Find someone who is a risk-taker to work with. If you are the type of person who avoids taking action before they have ALL the information, you can gain a lot from having someone on your team who is more impulsive. This way, you can balance each other out and become more effective.

    9. Think of airplanes. An airplane doesnt fly to its destination in a straight line. Once its up in

    the air, thousands of small corrections are made to the course until the airplane reaches its destination. The same is applicable to projects. You start working on the project and make corrections as necessary to reach the desired outcome.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 32

    12. Poor Management of Team Dynamics

    One of the biggest problems in project management is the temporary nature of a project and the impact it has on team dynamics. Many people dont realize how team dynamics can affect performance. In fact, many project managers arent even aware of these dynamics.

    Team dynamics are, essentially, unseen forces that affect the people or groups within a team. The way people interact with each other affects their performance, behavior and reactions.

    A common problem with projects is that most of the time the team is made up of people that have different personalities and havent worked together before. They havent had time to build up a strong relationship and learn how to work together properly.

    The problem is that project managers dont have the time to allow a team to gel before work commences. This is why it is essential for the project manager to properly manage team dynamics.

    Without adequate management, conflicts can arise which lead to stressful situations that can seriously affect the outcome of the project, causing setbacks.

    A number of factors influence the members of a team and a good project manager needs to be aware of these factors to be able to properly manage these dynamics. For example, personalities, team roles, processes, methodologies and even office layout can affect a team.

    A project manager needs to be able to help the team get along and do it quickly. The first step, of course, is to build a team with people who dont have conflicting personalities or, at the very least, run a team-building exercise that allows people to understand each others personalities.

    By understanding each other, friction and poor team performance can be avoided. When one team member understands how the other prefers to communicate and how they process information, that person can be more tolerant and understanding, allowing for a better relationship.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 33

    It is important to remember that conflict is inevitable in a team. Put two great friends in a room and leave them there for eight hours and they eventually disagree on something. However, not all conflict is negative because it can bring out the best in people and help them improve their working relationship, which improves the teams performance.

    On the other hand, when conflict begins to hurt the teams performance, it needs to be handled appropriately. For this reason, it is essential that project managers are able to identify and properly assess the nature of the conflict and its long-term impact on the teams performance.

    If the conflict has the potential to negatively impact performance, then the project manager needs to step in. It is important to understand that you cant solve the conflict yourself. You need to help the parties involved find their own solution. They need to be the ones to come to an understanding on how to resolve the conflict.

    You cant force people to get along or to work well together, which is why it is compulsory that they are the ones to come up with a solution.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 34

    13. Non-Acceptance by the Users/Those Affected

    Resistance to Change Many people like stability, and even though they get frustrated with current poor processes or an unstable system, you find people that resist change. This stems from the fear of the unknown or the thought of what might be. For example, some people fear that once the new fancy computer system is put in place their jobs become redundant.

    Expect resistance to change! Your best plan of attack is to accept that this will happen. Plan to minimize the likelihood.

    There are several options to reduce the impact of resistance or non-acceptance:

    Engage the end users or those affected early. Allow them to be part of the solution or in finding the solution and in testing.

    Communicate clearly, regularly and consistently. Make sure that no one is surprised by the changes and everyone is singing the same tune. You dont want to communicate one message and management tells another.

    Have effective and accessible training. Dont just run one training session on one day because the likelihood of everyone being available is slim to none. Be flexible and accommodating.

    Make sure that any reward and recognition programs are aligned to desired behaviors or new ways of operating. Make sure that the business is not rewarding people to behave one way or the old way when the project team is encouraging a different behavior.

    Do whatever it takes to provide comfort to the end user. Aim to put an end to any rumors or whispers in the hallway straight away. When people fear they will lose their jobs but its not going to happen, then tell them. If they may lose their jobs, then tell them all the things you provide as a result. You may provide a service where you help them find another job.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 35

    If you do not manage resistance to change, then the project ends up being a waste of time and a failure.

    Non-Acceptance of Deliverables Every project has acceptance criteria that must be well defined for the deliverables, due at the end of that project. Stakeholders expect to receive products or services at the end of the project, as detailed in the project agreement.

    Yet, there are times when the stakeholders may not accept delivery at completion of the project. This can happen for any or all of the following reasons:

    Poor quality; Timeliness issues; Insufficient quantity to meet project closure targets; End product did not meet project specifications; Misalignment of expectations versus to what was delivered.

    Non-acceptance of deliverables throughout the duration of the project needs to be addressed by the project manager. The project manager must request a formal acceptance from the stakeholder when deliverables are received via a structured review and sign-off process.

    Signing a written formal acceptance often prompts a stakeholder to identify and request changes if specifications have been missed or otherwise not addressed. If it were identified at initial review and sign-off then a formal change request would not need to be raised later. This is helpful feedback, as it keeps the rest of the project moving smoothly to the stakeholders expectations.

    By having sign-offs as checkpoints along the way ensures the stakeholders are fully aware of what is planned or is being delivered.

    Non-acceptance at the closure of the project may be a compensation event. A project manager may dispute the non-acceptance status of the project if all original project criteria have been met. A project manager may also negotiate with stakeholders to amend any oversights, correct any problems, or otherwise work towards reaching a viable solution for everyone involved.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 36

    There are unfortunate circumstances where you may have a lazy stakeholder who signs off without really making sure they understand what they signed off. To help avoid this run a walkthrough meeting or workshop where you explain the key points and provide them with an opportunity to ask questions.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 37

    14. Underestimating the Time It Takes

    Underestimating the time it takes for a certain phase or task to be completed is the downfall of many projects. It is rarely done on purpose and often the result of being overly optimistic. It is essential for project managers to be realistic when scheduling and estimating activities.

    It is imperative that your time estimates are based on how long you really think an activity takes and not how long you want it to take or how long someone else tells you it will take.

    If you struggle to estimate the time it takes you end up taking longer than necessary to complete a project phase. This can create havoc with your team and the stakeholders.

    Additionally, if people think that the time estimates arent realistic, they wont even strive to meet them because they already know they will fail. This can cause low team morale because they get the feeling they have not been set-up for success and are failing before they start.

    To accurately estimate the time it takes to complete an activity you need to consider certain factors and use your previous experiences, the experience of others, expert opinion and any other information sources to determine the following:

    How long it takes for other people to complete various activities including physical and mental tasks, such as report writing, brainstorming, researching and so on.

    Activities that need to be performed by machines, such as how long it will take to make 100 copies of the report, for example.

    Physical processes, such as waiting for paint to dry or for concrete to harden.

    Dead blocks of time, periods when nothing is being done whether due to lack of resources or any other reason.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 38

    It is important to not base your time estimation on how long it would take you to complete an activity, but on how long it would take another reasonable person to complete it. You may have a lot more experience or skill than others in particular areas. Using your time frame as an estimate is unrealistic.

    Take into account time delays for when an activity needs to be performed by a third party that is not part of your team.

    For example, if you need to get a building permit you need to take into account realistic experiences youve had previously. Dont be tempted to think wishfully because this is an activity outside of your control.

    Its pointless estimating that it will take three days to get the permit because thats what you want when your previous experience has shown that it takes at least two weeks. Doing this can completely derail your project and can lead to substantial loss of money.

    Be realistic when estimating the time it takes to complete certain activities as this leads to a much better outcome.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 39

    15. Conflicting Requirements

    Large projects tend to have an impact on many groups of people and not all the groups involved have the same expectations. In fact, quite often you find that they have conflicting requirements and the problem is that you need to manage these relationships in a way that offers all the stakeholders a positive outcome.

    Try to establish the requirements of each group beforehand and find a way to reconcile them. Of course, this entails you understand the problem that the project is trying to address.

    A great way to do this is by using project management software and tools that can deal with communicating these requirements in a fuss-free fashion. You should be able to save time and hassles with a software application and not spend more time trying to figure out where and how to set milestones and whom to invite to them.

    The use of matrices of requirements showing who requires each item can be useful to get a whole picture.

    Using a prioritization system on your requirements is critical in negotiating requirements. Where there is a conflict, if the requirement of one group is rated as critical and the conflicting requirement of another is nice to have it is a no-brainer as to which is included, and the stakeholders cant argue with the facts.

    By understanding exactly what the overall problem is, you will be in a better position to come up with a solution that meets everyones needs. You may have to carefully craft a negotiation meeting whereby you have pretty much determined the outcome prior to the meeting, based on a variety of criteria.

    For each of the requirements in question assess; priority, cost to implement, risk rating, impact on the business or users be that positive or negative and associated benefits. By having already determined the logical outcomes and alternative options you can go to the meeting fully prepared with facts and solutions.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 40

    Remember, the key is to ensure that everyone feels they are getting what they need and want and that means that you have to take the time to understand what each groups needs and requirements are.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 41

    16. Admin Overheads For Key Resources

    It is imperative that you analyze the value of your time. There are many administrative responsibilities in managing a project, such as setting up meetings, balancing budgets, printing documentation for meetings and so on.

    The problem is that these tasks can be very time consuming and if you are spending half of your time on these tasks, you are hurting the project because you could be spending your time on more important activities.

    For this reason, if you want your project to be more efficient, a good solution is to budget for a project assistant or coordinator who can handle administrative activities. It frees up your time to focus on more important tasks.

    If you need evidence to gain approval on the budget, record the activities you perform over a week or two, make sure to include any overtime, tally up how much time you spend on administrative tasks someone else could do. Work out how much that is costing and how much it would cost for an administrative team member and provide the information as evidence for budget approval.

    Another resource to consider is a number of software tools to make managing projects and team a lot easier than doing it by hand.

    Thankfully, in todays age and time there are 101 ways to simplify task management with the help of people and machines. Its the savvy managers way of handling things and it certainly frees up much of your time.

    Thus, instead of focusing on setting up meetings and printing reports, you can spend your time on activities that directly add value to the project, such as training, addressing issues, mentoring and providing guidance to the rest of your team and keeping in control of the project.

    The return on your investment will be exponential, especially since you will have a clear mind and wont be cluttered with menial tasks.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 42

    17. Key-Man Risk Not Managed

    There are many projects where there is one person or a number of people who have a particular skill set or certain knowledge that is critical to the success of the project.

    The problem is that their key role can sometimes lead to them becoming overwhelmed with the entire demands placed on them. If they cannot handle the pressure, there is nothing that can stop that person from leaving the project and leaving everyone else in the lurch.

    If you have people like this involved in the project, then you need to find ways to mitigate this risk by capturing as much of this information as possible. One way that is recommended is to spend a few days with the person in question and record all your interactions with them either on video or audio.

    During this time, ask them questions, interview them and try and learn as much as you can. By recording the information everyone will have access to it whenever it is required, and your project will not unravel at the seams if one person leaves.

    Remember that not all information can be molded into a template, which is why this approach of recording the information in a freestyle format offers a much higher rate of success.

    Also, consider cross training as another approach to managing key-man risk. You could also have an apprentice working with the person in question to learn all the ins and outs of what they do.

    It is practically impossible to capture everything a person knows and to figure out their thought processes. Its a good idea to provide them with all the resources they need to avoid the burden on their shoulders in becoming too great.

    If the person has a day-to-day job on top of the time required on the project, consider having someone else backfill their day-to-day job so they can focus on the project. Also build into your plan time for them to train the backfill team member and to allow for some extra support time for a period. Even just providing them with an assistant could relieve the burden.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 43

    Incentives are also a good way to minimize risk, offer a monetary incentive for them to commit to not leaving the project for a specified period of time, or offer an extra holiday when it is all finished.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 44

    18. Inadequate Change Control Process and Version Control

    Having a clearly defined scope is essential to the success of a project. However, there will be times when management or the client demand changes to the requirements, which can place a significant amount of stress on the team and derail the project. It can lead to mistakes that lead to more work for the entire team and anyone else involved in the project.

    For this reason it is essential to design and implement a rigorous change control process for all aspects of the project from the very beginning. This helps reduce scope creep as well as increasing the likelihood of the project being completed on time.

    As long as all parties involved in the project agree to the change control process from the start, it will be easier to either turn down the proposed changes or to incorporate those that have been requested.

    Changes to requirements can lead to the whole scope of the project changing. If it happens in the middle of the project, it often means that the team has to start all over again and that needs to be avoided at all costs.

    The first step is to, of course, ensure that the client is 100% certain of the requirements. Clearly defining the requirements from the beginning and ensuring they meet the real needs of the client is essential and reduces the likelihood of changes being needed.

    Business Evaluation The change control process needs to evaluate each change from a business point of view. In other words, does the change make sense from a cost to benefits point of view? If the change appears to have few benefits but increases costs significantly and extend the project timeline excessively, then it might be wise to discard it. For this reason, it is imperative that the process has clear evaluation and acceptance criteria on which everyone agrees from the start.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 45

    The analysis needs to be done objectively, without bias in terms of the additional work it might require or who is demanding the change. Just because management is proposing a change, doesnt mean you need to implement it if there is no justification for it from a business point of view.

    Make sure to give yourself a few alternatives when designing the change control process. In other words, instead of simply accepting or rejecting the change, give yourself the option of accepting the change with some additional modifications or to implement it at a later date.

    Project Impact Analysis When implementing changes to a project, it is imperative to analyze the consequences of implementation. If the consequences are not fully understood, it can lead to disastrous results, not only derailing the project but also having a negative impact on peoples jobs and lives.

    Change the control process to include a phase in which the consequences of implementing a certain change are fully analyzed.

    The procedure to assess the impact of any changes should include the following:

    Defining the extent of the proposed change;

    Determining the main differences between the current state of the project and the changes proposed;

    The possible effects of these differences;

    Sorting and prioritizing the potential consequences from the main differences based on risk level;

    Making a decision based on the results.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 46

    The first step is to gain a clear understanding of the proposed change, without which you cannot identify the risks. The more specific you are in defining the change, the easier it will be to see where the risks are.

    Next, you need to compare the current state of the project to the state of the project after the changes have been implemented. The goal is to discover all the differences between the two states of the project, which will allow you to research and discover what risks are associated with these differences.

    Once you have a clear idea of the differences you need to create a list of all the consequences that the changes have on the final outcome. These consequences need to be categorized according the type of impact they have on the project, whether it is neutral, positive or negative.

    They then need to be prioritized according to the degree of importance and a decision made based on the data that has been compiled. If there are too many negative consequences, then the change can be rejected.

    Version Control This seems like such a simple thing to do but so often it is not carried out properly. Many times it is because different people have their own preferences as to managing their documents, some people like to use the date as version numbers, other use a numbering sequence.

    Whichever method you use, make sure it is consistent and known throughout the project. Otherwise changes can be lost meaning requirements can be lost, or rework may be require to fix problems when the wrong version is worked on.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 47

    One possible version control method is a numbering system at the end of the document name.

    Working Requirements v0.1.doc, v0.2, v0.24 etc. is to be used for pre-release to review and sign-off or working versions.

    Sign-off Requirements v1.0.doc, v2.0 or whole numbers be reserved for documents sent for review and sign-off.

    Modifications after sign-off use v1.1, v1.6 etc. If it is to go back out for sign-off, use the next whole number.

    A consistent use of folders and making sure documents are accessible by the whole team not just the author saving it to their desktop is important.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 48

    19. Overheads - Conflict Between the PMOs and Stakeholders Needs For Reporting

    When there are a number of groups involved in a project, you often find that they all want different information or they want it in various formats that have nothing to do with each other.

    The problem is that if you try to make everyone happy, youll be spending most of your time on creating reports rather than on actually completing and managing the project.

    The first step is to establish what information is required and why. You can then determine what reports everyone wants ahead of time as well as the formats they want them in. Depending of what they want to do with the information they may want graphs, text etc. Of course, your ultimate goal should be to get the various groups to accept similar formats and information, if possible.

    Once the reporting system has been agreed upon, you shouldnt agree to include extra information just for the sake of it. If its vital and the stakeholders really need the information, then you can provide it but not if its just something they would like to have.

    A good way to determine this is to quiz them to determine why this information will be valuable to them. If they cant justify it then you can explain how the effort required to produce the report will result in little benefit.

    Also, try and reuse as many of the reports and the information as you can. For example, if you create a progress report for the PMO, you can then include the same report in the pack for a stakeholder meeting. Also, consider using a database or software, which will allow you to use the same information and present it in multiple ways.

    For example, by inputting all your costs into a database, you can generate profit and loss forecasts, current expenses and more from the same information with a click of the button. Remember, the key to efficiency is to work smarter and not harder.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 49

    20. Choose Your Team Members, and Dont Be Afraid To Let Them Go

    The success of a project is inherently linked to the team working on it, which is why it is imperative that you put a great team together. A project team usually includes people who have different skills and operating styles that might work in different parts of the organization.

    There is a chance you have had little interaction with these people on previous occasions yet you have a tight time schedule and these people might also be already working on other projects concurrently.

    This is why it is imperative that all members roles are clearly defined and that each person clearly understands and is comfortable with the role you have planned for them. The whole team needs to feel confident that everyone will deliver on his or her commitments.

    Choosing the right members for the team can only be done, in the beginning, by analyzing their skills and deciding whether or not they are a good fit for the role you have in mind. Of course, this means that you first need to decide which tasks or types of activities will be required to complete the project.

    Generally, you should handle the tasks that you do best yourself. For example, if you are an expert graphic designer, theres no reason to get another team member in to do it. However, if you are also a great typist that doesnt mean you should spend hours typing up the user manual for the application, as that is an unproductive use of your time.

    Additionally, the project manager should try and stay away from tasks that are critical to the project moving forward and try to delegate as many of these as possible. This is because if you have to deal with other issues on activities that arent as important, you will delay the whole project because you havent been able to complete the critical tasks on time.

    The project manager needs to be available to address issues as they arise and perform their role of managing, monitoring and controlling the project as a whole.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 50

    Make sure you never delegate tasks that you cant clearly put into words. If you cant describe an activity, then you wont be able to explain what needs to be done properly and someone else wont be able to properly complete the task.

    You save a lot of time by simply completing the task yourself because otherwise you spend much more time answering questions or fixing problems.

    You shouldnt be afraid of replacing a team member. This may seem callous or you might find it hard to do, but you need to be realistic. The time it takes you to try and help a member integrate or to groom their skills to be able to fulfill the role you have assigned them negatively impact the project by delaying it and maybe even increasing costs.

    Its often better to simply let someone go and find another person to replace him or her than to keep hoping that they will be able to deliver when they have clearly proven they are unable to.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 51

    21. Uninterested Stakeholders Lead to Project Failure

    It is imperative that you have the right stakeholders because without them, the project has little chance of being completed successfully. Of course, as a project manager, you have limited control over the stakeholders but you need to manage your relationship with them to make sure you are getting what you need from them.

    A good stakeholder needs to:

    Be willing to make decisions that might be unpopular, but are in the best interest of the project and therefore the business.

    Have a vested interest in the project to ensure its success.

    Actively participate in creating the vision of the project.

    Have the decision-making power to obtain resources for your project.

    Directly benefit from the results of the project.

    Be willing to support you with other managers to help you in obtain what you need from other organizations or departments.

    Be willing to meet on a regular basis to make sure work is going according to plan and you have everything you need to make the project a success.

    Thus, to ensure that your stakeholders are on board with you, you first need to make sure they are engaged in the project. This means meeting regularly to make sure that they know where the project is and offer you the support you need to keep things moving forward.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 52

    A good technique to use is working the success of the project into the stakeholders performance objectives, this keeps them interested as the success of the project could have a direct impact on their bonus at the end of the year.

    Make sure that you are clear on what your stakeholders expect from the start of the project.

    This way you will be certain you are all working towards the same end result and that the projects requirements conform to what the stakeholders want. Make sure to recheck expectations on a regular basis to ensure you can make the necessary changes to obtain the desired results.

    The key to good engagement from any stakeholder is their benefit from being involved. If a stakeholder has no vested interest in the outcome of the project, they are likely the wrong stakeholders. You must both have a clear understanding of the benefit to be gained by each stakeholder.

    Remember that your stakeholders are busy people, so you need to set up a schedule of communication and you need to stick to it. This ensures you avoid wasting their time and yours, which leads to a much better working environment.

    Ensure you are fully prepared for all interactions with your stakeholders so the time is spent worthwhile and ends up being valuable to you both.

    Inform your stakeholders of any issues they need to resolve in a timely fashion. You need to tell them exactly what you need for the successful completion of the project.

    A common strategy used of late by large projects or programs with numerous stakeholders, potentially with conflicting interests, is to place a stakeholder on the project that has no direct business benefit other than a performance objective or a monetary bonus.

    This stakeholder is someone at the same seniority level as the other stakeholders if not higher, so they have influence in the organization and they are there to mediate and play the devils advocate.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 53

    There will be times when the project struggles with conflict between stakeholders or delays if a large group is unable to come to a consensus. This is when this stakeholder comes into play. Their primary focus is the success of the project and nothing else. It is something to consider for large and complicated programs of work.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 54

    22. Not Holding Strong On What You Know Is Right

    There will be many occasions when you are called to implement a change, whether its to the budget, the schedule or the scope of the project. You know it will hurt the outcome of the project but you are tempted to go along with it just because the order comes from the top.

    You conform to what you are being told to do without saying a word and then, when the project fails, the powers that be blame the project and the project manager, rather than their unrealistic expectations or the changes they forced on you.

    This is why it is imperative that you have a change control process implemented that everyone agreed to in the beginning. This way, you can properly analyze the proposed change and its consequences. You get tangible evidence you can use to show that the proposed changes would hurt the outcome of the project.

    Of course, this means you have to stand up and tell the management or the originator of the proposed change that you disagree with their proposed course of action.

    For example, if you know a project is going to take at least 12 months to complete and its a timeframe that was previously agree upon but the management suddenly decides you need to finish in six months, you cant simply sit there and say yes, knowing that it is impossible to do so.

    Many people are afraid to speak up for fear of losing their job, but a project manager is just as important as any other member of a company and you need to speak your mind.

    If you provide valid reasons with tangible evidence that supports your views, you will be respected for speaking your mind, especially since it will be clear that you are speaking from experience and not just doing it for the sake of saying something.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 55

    Of course, you wont always win but there are always alternatives. For example, if the demand is to complete the project within six months instead of 12, compile an analysis of what resources would be required to pull it off, explain that there is no way to meet the new deadline with the resources that are currently available to you. The increased costs will act like a bucket of cold water and you have a greater chance of getting your own way.

    The worst thing you can do, though, is to agree to a change without first analyzing the impact it will have so if you arent certain, ask for time to conduct your analysis. Based on that you can then make an informed decision and the more the management sees that you base your decisions on cold, hard facts, the less work you will need to influence them in the future.

    The other circumstance is when you feel that a proposed direction or plan of action is morally or ethically opposed to your own values or is not conforming to policy or standard practice. This can be a difficult situation, but you cannot undertake a project you are morally uncomfortable with.

    It is important in these circumstances not to become emotional over the matter as this can easily occur. Remain calm and state your case in an assertive manner.

    You will most likely have all the justification you need, such as; the policy states, all the other teams are doing it this way, you will create a mass walk out if you do it that way etc.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 56

    23. Quality Outputs

    The ultimate measurement of the success or failure of any project is determined by the quality, the quantity and the timeliness of the items that need to be achieved by the end of the project. These end results are referred to as the project outputs or deliverables.

    The output may be represented in terms of a product, service or result, but may also come in formats that include written reports or documents, or other verbal means of reporting.

    Key project management processes must result in a quality output. Some examples are shown here:

    Project Management Process Quality Output

    Develop Project Management Plan

    Written project management plan Must be comprehensive and include key

    components

    Define Scope of Overall Project Statement detailing Project Scope Also include what is out of scope

    Collect Project Requirements Documentation for requirements Clear, concise, complete, easy to understand,

    no inclusion of vague or ambiguous requirements

    Define Activities Required for Project

    Written Activity List Attributes-list for each activity (who

    responsible, dates, prerequisites etc.) List showing major milestones

    The above may or may not be shown as a project schedule

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 57

    Estimate Resource Activity Written report showing activity resource requirements and breakdown of resource structure e.g. work breakdown structure

    Estimate Project Costs List of itemized cost estimates Basis for cost estimates Budget forecasts

    Determine Project Budget Document showing cost performance baseline Requirements for Project Funding

    Plan Project Risk Management Written risk management plan Should be complete and ratings given for each

    risk. A person should have been given responsibility

    as a risk owner

    Monitor and Control Schedule Measurements for work performance Change requests Project management plan updates Status reports

    Perform Quality Control Report showing quality control measurements Verified deliverables Verified amendments Change requests Recorded sign-offs

    On all outputs, not just those listed above you need to take the time to inspect what you expect. Request a review of an output early in its life so that you can offer guidance and direction as to what is considered a quality output. Provide examples and standards as guidance to the team.

    Good project management leads naturally to a higher chance of a good quality output in terms of the project being on time, within budget, high quality and acceptable to the stakeholder.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 58

    24. Insufficient Change Impact Analysis

    Managing the impact of the change on the business or end user is if not the most important part of the implementation process. If the impact on people, process and systems is not adequately understood the implementation can turn out to be a complete disaster. It can end up creating huge impacts on jobs and lives and even put lives at risk and ultimately cause the project to fail.

    The key things to assess are:

    Who is impacted? What is impacted? How are they impacted? What will be the impact on those people and things?

    You then need to address how you need to manage or mitigate those impacts. Management and mitigation require a defined plan. Activities could range from system modifications to training programs and phone support depending on the change and the impact.

    For example:

    If you are implementing a replacement for the Payroll system, you need to consider what other systems connect to that one system and who uses the system.

    Those other systems that send and receive information to and from the current payroll system will have potential impacts of a new system being put in place, these need to be managed.

    The current users of the payroll system will have to learn a whole new system and potentially make large amendments to their day-to-day activities; these also need to be managed.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 59

    25. Uninformed Stakeholders

    One common problem is that the project team busily works towards completing a project that stakeholders or customers dont understand and therefore have no interest in supporting or accepting the change into their lives.

    This lack of understanding usually stems from a lack of communication, which is why it is essential for the project to communicate regularly and effectively with stakeholders. Acceptance of any change comes from understanding.

    Essentially, you want to take them on the whole journey with you so they understand each step of the project and what is involved. The more they know about the benefit they will receive and the progress of the project, and the more you involve them, the more likely they are to offer valuable input and support when you need it.

    However, if you only communicate with them when you have problems, they will be more reticent and less likely to support you in your decisions. The key is to build a relationship and prove you are trustworthy and then the stakeholders will be more comfortable in providing you with the support you need.

    Additionally, it is also a time saving exercise because you wont have to waste their time and yours explaining why the change is necessary. They will be able to see it themselves since they will be familiar with the progress and status of the project.

    After all, the entire project only exists to benefit stakeholders. Many times the project team does not even see the project benefits be achieved as this can occur months and sometimes years after the project has completed.

    If your stakeholders are not excited about the benefits or cant tell you what they are you need to take action to get them engaged.

    Ensuring stakeholders understand benefits and progresses are key to success, but there are a couple of things rarely communicated to stakeholders that can reduce a bit of tension.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 60

    Help them gain some understanding of project methodology and justify why it is important to the success of the project every time you ask them to spend time doing something, they can get frustrated with documents to review, and their team members being tied up in workshops, so help them understand and life will be much easier for everyone.

  • Louise Ledbrook | www.ProjectCommunityOnline.com | 61

    26. Testing and Usability

    When planning your project, ensure that you allow plenty of time for testing, evaluation and correction of any defects. Never assume that the results of your tests will always be positive as this rarely happens so ensure you allow plenty of time for corrections and retesting.

    It is imperative that you establish a testing process from the beginning. In doing so you ensure that you know exactly what the performance and acceptance criteria are. These are matters that need to be established with your stakeholders so that everyone is on the same page.

    Additionally, consider conducting tests throughout every phase of the project, which will make it easier to correct any problems and lead to less work later on in the project.

    This means that you need to schedule periodic reviews with your stakeholders and customers and cover all interim deliverables to ensure that you are on track. To make life even easier, make sure that the people who will be responsible