Mind Tools - Project Management

Project Management Tools As you move ahead in your career, you are likely to face more complex and difficult challenges. Some of these will involve the coordination of many different people, the completion of many tasks in a precise sequence, and the expenditure of a great deal of time and money. Whether you succeed or fail with these projects depends on how good you are at project management.

© iStockphoto

This section of Mind Tools teaches more than 50 individual project management skills. Start with our quiz , which helps you assess your current skills levels. Then explore the key areas of project management, learn how to schedule projects, and find out how to manage change so that your projects are accepted and embraced by the people they affect. The Browse by Category box below will help you target specific project management skills areas, while you can look through the full list of tools to find interesting topics. Enjoy using these tools!

Browse by Category Project Management Framework

Communication

Scheduling

Project Improvement and Review

Scope Management

Change Management

Building Support for Your Projects

Further Resources Bite-Sized Training™

Book Insights

Learning Streams

Expert Interviews

Project Management – Start Here!

How Good Are Your Project Management Skills?

Agile Project Management Organizing Flexible Projects

Program Management Structuring Projects as Part of a Program

The Iron Triangle of Project Management Balancing Your Budget, Scope, and Schedule

Words Used in Project and Program Management A Glossary of Terms

Project Management Framework Project Management Phases and Processes Structuring Your Project

The Planning Cycle A Planning Process for Middle-Sized Projects

Logframes, and the Logical Framework Approach Planning Robust, Coherent, Successful Projects How to Write a Business Case Getting Approval and Funding for Your Project

Project Initiation Documents Getting Your Project Off to a Great Start

Project Charters Getting Your Project Off to a Good Start

Request for Proposal (RFP) Documents Getting Better Terms with a Competitive Bidding Process

Risk Impact/Probability Chart Learning to Prioritize Risks

Project Issue Management Identifying and Resolving Issues

Business Testing in Projects Involving Real Users as an Important Testing Step

Benefits Management Getting the Greatest Possible Benefit from a Project

Rationalizing Your Project Portfolio Delivering Strategic Benefits with Limited Resources

Managing Project Finances Understanding and Controlling Project Costs

Project Close Activities Ending Projects Properly

Managing Project Uncertainty Planning for the Unknown

Scheduling Project Schedule Development Planning the Timing and Sequence of Project Activities

Action Plans Small-Scale Planning

Planning Large Projects and Programs Planning Large-Scale Projects

Gap Analysis Identifying What Needs to Be Done in a Project

Estimating Time Accurately Calculating Realistic Project Timelines

Gantt Charts Gantt Charts: Planning and Scheduling Team Projects

Critical Path Analysis and PERT Charts Planning and Scheduling More Complex Projects

Scope Management Business Requirements Analysis Clearly Agreeing What You're Going to Deliver

Work Breakdown Structures Mapping Out the Work Within a Project

Scope Control Avoiding Too Many Changes in Projects

Building Support for Your Projects Stakeholder Analysis Winning Support for Your Projects

Stakeholder Management Planning Stakeholder Communication

Project and Program Governance Using Senior Management Support to Ensure Project Success Working with Project Sponsors

The Responsibility Assignment Matrix (RAM) Knowing Where the Buck Ultimately Stops

The RACI Matrix Structuring Accountabilities for Maximum Efficiency and Results Influence Maps Uncovering Where the Power Lies in Your Projects

Communication Project Dashboards Quickly Communicating Project Progress

Project Milestone Reporting Keeping Projects on Track by Monitoring Significant Check Points

Change Management How Good Are Your Change Management Skills?

Change Management Making Organizational Change Happen Effectively

Overcoming Cultural Barriers to Change Moving to a High Performance Culture

Lewin's Change Management Model Understanding the Three Stages of Change

Beckhard and Harris' Change Equation Overcoming Resistance to Change

The Change Curve Accelerating Change, and Increasing its Likelihood of Success Leavitt's Diamond An Integrated Approach to Change

The Burke-Litwin Change Model Unraveling the Dynamics of Organizational Change

Kotter's 8-Step Change Model Implementing Change Powerfully and Successfully

Changing People's Habits Encouraging and Sustaining New Behaviors

Why Change Can Fail Knowing What Not to Do

SIPOC Diagrams Making Sure Your Change Process Serves Everyone

The ADKAR Change Management Model Using Goals to Accomplish Change

Bridges' Transition Model Guiding People Through Change

Project Improvement and Review After Action Review (AAR) Process Learning From Your Actions Sooner Rather Than Later

Post-Implementation Reviews Making Sure That What You Delivered Actually Works

Conducting a Project Healthcheck Finding Out How a Project Is Progressing

Why Do Projects Fail? Learning How to Avoid Project Failure

Bite-Sized Training™ What Is Project Management?

Stakeholder Management

Managing Stakeholders Scenario Training

Planning Small Projects

Winning Support for Your Project

Managing Change

Learning Streams Manage Change

Book Insights The Three Laws of Performance, by Steve Zaffron and Dave Logan Change By Design: How Design Thinking Transforms Organizations and Inspires Innovation, by Tim Brown Switch: How to Change Things When Change Is Hard, by Chip Heath and Dan Heath 99 Ways to Influence Change: The Essential Guide to Making an Impact at Work by Heather Stagl The Six Secrets of Change, by Michael Fullan

Expert Interviews Fast Projects, with Fergus O'Connell

Innovations in Office Design, with Diane Stegmeier

Where to go from here:

Return to top of the page

Next article

Project Management – Start Here! Project Management is a wellestablished approach to managing and controlling the introduction of new initiatives or organizational changes. Projects are finite in length, usually one-time pieces of work involving a number of activities that must be completed within a given time frame, and often on a fixed budget. Common Opening Day: Your project's complete! examples of projects are © iStockphoto/Ridofranz construction of a building, introduction of a new product, installation of a new piece of machinery in a manufacturing plant, creation of a new software tool, or the design and launch of a new advertising campaign. While the very simplest projects can be managed easily by applying common sense and just getting on with things, projects that are more complex need a great deal of planning, and benefit from a formal, disciplined management approach. From making sure that activities will actually meet the specified need, to devising a workable schedule, developing systems for reporting progress, and managing requests for changes – all of these issues require thoughtful consideration. Managing projects well requires a great deal of time, skill, and finesse. There are many sides to project management and this is what makes it so interesting and demanding. Project managers are expected to take an uncertain event and make a certain promise to deliver. They are also expected to do this within a specified time and within a limited budget. For a more in-depth overview of project management, take our BiteSized Training session What Is... Project Management?

Where to go from here:

Next article

View print friendly versio

Return to top of the page

Action Plans Small Scale Planning Whether it's sending out an email newsletter, putting together a presentation for senior managers, or working on a special request for a client, many of us have to complete simple projects as part of our day-to-day responsibilities. These small- to medium-sized projects may, at first glance, not seem to need much thought.

Simple projects can be completed with simple plans. © iStockphoto/AndrewJohnson

But, occasionally, we can overlook a key step or "to do" item that can derail all our efforts. For instance, how do you make sure that you've covered everything? Are there any actions that need to be taken early on in the project for it to succeed? And are you clear about when you need to do key tasks, in what sequence, to meet your deadline? Action Plans are simple lists of all of the tasks that you need to finish to meet an objective. They differ from To-Do Lists in that they focus on the achievement of a single goal. Action Plans are useful, because they give you a framework for thinking about how you'll complete a project efficiently. They help you finish activities in a sensible order, and they help you ensure that you don't miss any key steps. Also, because you can see each task laid out, you can quickly decide which tasks you'll delegate or outsource, and which tasks you may be able to ignore.

Using Action Plans Use an Action Plan whenever you need to plan a small project. To draw up an Action Plan, simply list the tasks that you need to carry out to achieve your objective, in the order that you need to complete them. (This is very simple, but it is still very useful!) Use the three-step process below to help you:

Step 1: Identify Tasks Start by brainstorming all of the tasks that you need to complete to accomplish your objective. It's helpful to start this process at the very beginning. What's the very first action you'll need to take? Once that task is complete, what comes next? Are there any steps that should be prioritized to meet specific deadlines, or because of limits on other people's availability?

Step 2: Analyze and Delegate Tasks Now that you can see the entire project from beginning to end, look at each task in greater detail. Are there any steps that you could drop, but still meet your objective? Which tasks could you delegate to someone else on your team, or could be dealt with by a freelancer? Are there any deadlines for specific steps? Do you need to arrange additional resources?

Step 3: Double-Check with SCHEMES Use the SCHEMES* mnemonic to check that your plan is comprehensive. SCHEMES stands for: • Space. • Cash. • Helpers/People. • Equipment. • Materials. • Expertise. • Systems. You may not need to think about all of these to complete your project. For instance, for a small internal project to streamline the format of your team's reports, you might only need to think about "Helpers/ People," "Expertise," and "Systems." Note:

Once you've completed your Action Plan, keep it by you as you carry out the work, and update it with additional activities if required.

Learning from Your Action Plan If you think you'll be trying to achieve a similar goal again, revise your Action Plan after the work is complete, by making a note of anything that you could have done better. For instance, perhaps you could have avoided a last-minute panic if you'd alerted a supplier in advance about the size of order you'd be placing. Or maybe you didn't allow enough time to do certain tasks. Tip:

If you'll be doing similar work again, consider turning your Action Plan into an Aide Memoire . This is a checklist that you progressively refine and improve to make sure that you remember to do everything important for success.

Managing Bigger Projects Action Plans are useful for small projects, where deadlines are not particularly important or strenuous, and where you don't need to coordinate other people. As your projects grow, however, you'll need to develop more formal project management skills, particularly if you're responsible for scheduling other people's time, or need to complete projects to tight deadlines. Tip:

Visit the Mind Tools Project Management section to develop your project management skills. In particular, see our article on Gantt Charts , and take our How Good are Your Project Management Skills test. Our Bite-Sized Training session on Planning Small Projects also teaches some useful project planning techniques. You can also use Action Plans in conjunction with your To-Do Lists or Action Programs .

,

Action Programs are "heavy duty" versions of To-Do Lists, which help you manage many simultaneous small projects. This is something that managers at all levels need to do routinely.

Key Points An Action Plan is a list of tasks that you need to do to complete a simple project or objective. To draw up an Action Plan, simply list the tasks that you need to complete to deliver your project or objective, in the order that you need to complete them. To do this, first brainstorm every step you'll need to take to follow your task to completion. Then, analyze tasks to see if there are any that can be pruned, or delegated. Lastly, use the SCHEMES mnemonic to double check that you've considered all critical areas. If you need to schedule people's time, or meet tight deadlines as part of your project, consider using the other project management techniques mentioned. * Originator unknown. Please let us know if you know who the originator is.

Did you find this article helpful?

Click to vote no

No Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Hi beyond_the_box, We have developed templates for many of our tools. You can find them here: http://www.mindtools.com/community/pages/article/ worksheetsindex.php I've forwarded your feedback onto our editorial team and they are actively working on new content all the time. It's great to hear from you. I hope you are making good use of the resources here. Best! Dianna October 23, 2013 beyond_the_box wrote It would be helpful to have templates associated with these articles. October 21, 2013 James wrote Hi Everyone

We’ve given this popular article a review, and the updated version is now at: http://www.mindtools.com/community/page ... HTE_04.php Discuss the article by replying to this post! Thanks James March 25, 2011 Dianna wrote Action plans are life savers. Without one a goal can easily get away from me because I get lost in the details and then can't seem to make sense of what I need to do. When I organize myself with a plan then I have a step by step process to follow that I know will lead me to the end result I desire. I find it so helpful for those projects that are too big to keep all the details in your head yet aren't big enough to warrant a full project management plan. Dianna May 22, 2010

Return to top of the page

After Action Review (AAR) Process Learning From Your Actions Sooner Rather Than Later A typical project review is done "post mortem" – after the fact, and well past any opportunity to change the outcome. You finish a project, and then you study it to determine what happened. From there, you decide which processes to keep and what you'll do differently next time. Useful in business, as well as emergency situations.

That may help the next project © iStockphoto – but it's too late for the project you've just finished: you may have use too much time and too many resources in the project being reviewed, and you could have avoided some of this if you'd done a review part of the way through. Wouldn't it be better to evaluate along the way – so that you can capture lessons learned after each milestone, and improve performance immediately?

Organizations of all types, across all industries, could benefit from an ongoing review process. The After Action Review (AAR) process was developed by the military as a way for everyone to learn quickly from soldiers' experiences in the field. With this system, critical lessons and knowledge are transferred immediately to get the most benefit. The "field unit" has an opportunity to talk about what happened, and other teams can then use this experience right away. In this way, the performance of the whole organization improves in a timely manner.

Benefits of an AAR AARs provide an opportunity to assess what happened and why. They are learning-focused discussions that are designed to help the team and the organization's leaders discover what to do differently. For example, when conducting organization-wide training, you might complete an AAR after the first training session to analyze what to do better in the next session. Or, if you're changing your manufacturing process, you could do an AAR after completing the first 100 units, instead of finishing the entire run. Depending on the nature and size of a project, you may actually do the AAR after completion. The common factor is applying the AAR process to all recurring, or repeating, events and activities, as well as those that pose a challenge. The AAR approach supports a

continuous learning culture – and the desire to find and use best practices and innovative approaches. It's important to note that AARs aren't limited just to large or formal projects. You can use them after staff meetings or regular operational functions, like month-end accounting. Also, when a safety incident occurs, an AAR can reveal important lessons. An added benefit of the After Action Review process is improved communication and feedback within teams themselves. Because the focus is on learning instead of blaming, the process itself leads to improved understanding of team performance, and helps people think about how best to work together to produce better results. The AAR process is related to the Deming Cycle, or Plan-DoCheck-Act (PDCA) , and it's a great addition to any continuous improvement initiative. The Deming Cycle is a broader approach to solving problems and managing change. AAR is a useful tool that works with PDCA, but they're not substitutes for one another.

Conducting an After Action Review An AAR is a structured meeting that does the following: • Focuses on why things happened. • Compares intended results with what was actually accomplished. • Encourages participation. • Emphasizes trust and the value of feedback. For the AAR process to be successful, the team needs to discover for itself the lessons provided by the experience. The more open and honest the discussion, the better. Here are some of the key elements of an effective AAR: • Discuss the purpose and rules – The AAR does not seek to criticize negatively, or find fault. The emphasis should be on learning, so make this clear right from the start to achieve maximum involvement, openness, and honesty. • Encourage active participation – When setting the rules, talk about trust. Emphasize that it's OK to disagree and that blame isn't part of the discussion. Personal attacks must be stopped immediately. Setting the right tone for an AAR is extremely important. • Use a facilitator – A neutral party helps focus the discussion. This person asks questions and can often lead the discussion in such a way that it remains nonjudgmental. • Talk about TEAM performance – The AAR is not about individual performance. Look at how the team performed, and don't assign blame. • Conduct the AAR as soon as possible – For feedback to be effective, it should be timely. By doing an AAR quickly, you'll get

a more accurate description of what happened. It also helps ensure that all (or most) of the team can participate. • Focus the discussion with skillful questioning – If you ask, "How do you think that went?" this can be too broad a topic to discuss. Instead, direct participants to think about specific issues or areas: "How well did you cooperate?" "How could communication have been better?" "What planning activities were most effective?" Discussion questions typically center around three themes: 1. What was supposed to happen? What did happen? Why was there a difference? 2. What worked? What didn't work? Why? 3. What would you do differently next time? Start by getting participants to agree on what was supposed to happen. If the original objectives were unclear, then it's unlikely that the project or activity was very successful. Once you have agreement, you can discuss actual versus intended results. You may need to return to the objectives as you move on to what worked and what you would do differently. Remember to ask open questions, so that participants don't think that there's a "right" or "wrong" answer: • What would you have preferred to happen? • What would you do differently next time? • How could the situation have been prevented? • In your opinion, what is the ideal procedure? Sometimes it's helpful to have participants each write down their ideas, and then ask everyone to share. This helps you avoid groupthink , and it allows quieter individuals to contribute. Write the key discussion questions on a whiteboard or flipchart. This helps participants focus on the main purpose of the meeting. • Let the team talk – This is an exercise in good communication, not just feedback and continuous learning. The better the team members communicate with one another and work out differences, the stronger they'll be in the future – as both individuals and team players. • Record the recommendations – Write down the specific recommendations made by the team. Then forward this information to other team leaders and stakeholders. This is how AARs contribute to organization-wide learning and improvement. • Provide follow-up and training – If no one follows up on the recommendations, then time spent on the process is wasted. Create a system to ensure that the ideas gathered in the AAR are incorporated into operations and training activities.

See our articles on running effective meetings and managing conflict in meetings to learn how to do these things effectively.

Key Points After Action Reviews provide an effective approach for capturing lessons learned from activities and projects. Rather than waiting until the end of a long project to evaluate how well the team did, AARs incorporate continuous learning right from the start. They're also great for ensuring that the lessons learned from one project or team are shared with the rest of the organization, with a view to improving overall performance. Continuous improvement helps us handle the changes that are happening around us. AARs help us keep open a steady dialogue about learning and improvement. They also allow organizations to learn and adapt, so that they can keep up with – and stay ahead of – change.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote

In a previous job I coordinated After Action Reviews for a large department. We looked at what worked well, what didn't work so well, where mistakes were made, where improvements could be done and concrete, specific, recommendations for the future. One of the key things in the process was ensuring the recommendations were implemented. I therefore created a document containing just the recommendations which was there circulated to the concerned parties. Rather than having to wade through a large document, this summary was a 'quick reference' of what had to be done and who was responsible for actioning an item. Then, about six months after the event, I would ask for an update. I then updated the document and recirculated it. It provided managers with a status of what was happening, as well as a nudge to get going with the recommendations they were responsible for. Regardless of work situation, sports situation or personal situation, we can all benefit from doing AAR after a big event. Midgie November 6, 2008

Return to top of the page

Agile Project Management Organizing Flexible Projects Picture a start-up technology business, where the founders are trying to carve out a sustainable business niche. The sector is changing fast, and they must quickly develop a service that users are prepared to pay for. This is tricky! Agile Project Management is about developing They can only find out so much successful solutions in a fast-moving environment. through market research, so © iStockphoto/aluxum they need to experiment. This means trying a variety of different offerings. Step-by-step, they need to learn from these and try improved offerings until they develop a solution that really works.

You can probably see that many work-related projects – particularly those involving complex, fast-moving situations – resemble this scenario. You can be working towards one deliverable or solving one problem, but then need to change course and revise your plans. If you're using a traditional project management approach, these revisions will lead to missed deadlines, inflated costs, and increased workloads. And, in a worst-case scenario, you can find that the situation has changed so much during the course of the project that your final product, when it is eventually delivered, is no longer relevant. Agile Project Management is an approach that helps you deal with these challenges. In this article, we'll describe what Agile is, and we'll explain why it's beneficial.

What is Agile Project Management? Agile Project Management is built around a flexible approach. Team members work in short bursts on small-scale but functioning releases of a product. They then test each release against customers' needs, instead of aiming for a single final result that is only released at the end of the project. The end product of an agile project may be very different from the one that was envisaged at the outset. However, because of the checking process, team members can be sure that the product is one that customers want. This makes Agile Project Management particularly appropriate for new or fast-moving businesses, for those in a fast-changing environment, or for highly complex situations, where managers are "feeling their way forward" to find the optimum business model. It's also helpful

with urgent projects that can't wait for a full, traditional project to be set up.

The Origins of Agile The elements of Agile Project Management have been around for decades. However, two events helped to lay the foundations for the approach. First, in 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article called "The New New Product Development Game" in the Harvard Business Review. In it, the authors outlined a new way of developing products that resembled a rugby match. They imagined a project management approach in which, just as on the pitch, team members would achieve their goal by constantly reevaluating the situation and responding accordingly. Projects would therefore evolve, but would lead to products that met customers' needs more fully as a result. The second event occurred in 2001, when a group of software and project experts met to discuss what their most successful projects had in common. They created the Agile Project Manifesto, which outlined the values and principles that underpinned Agile Project Management. Agile Project Management is built on the product development approach of Takeuchi and Nonaka, and incorporates the values and principles outlined in the Agile Project Manifesto.

Agile Versus Traditional Project Management Let's compare Agile Project Management with traditional project management to show how the approaches differ. Agile Project Management

Traditional Project Management

Teams are self-directed and are free to accomplish deliverables as they choose, as long as they follow agreed rules.

Teams are typically tightly controlled by a project manager. They work to detailed schedules agreed at the outset.

Project requirements are developed within the process as needs and uses emerge. This could mean that the final outcome is different from the one envisaged at the outset.

Project requirements are identified before the project begins. This can sometimes lead to "scope creep," because stakeholders often ask for more than they need, "just in case."

User testing and customer feedback happen constantly. It's easy to learn from mistakes, implement feedback, and evolve deliverables. However,

User testing and customer feedback take place towards the end of the project, when everything has been designed and implemented. This can

Agile Project Management

Traditional Project Management

the constant testing needed for this is labor-intensive, and it can be difficult to manage if users are not engaged.

mean that problems can emerge after the release, sometimes leading to expensive fixes and even public recalls.

Teams constantly assess the scope and direction of their product or project. This means that they can change direction at any time in the process to make sure that their product will meet changing needs. Because of this, however, it can be difficult to write a business case at the outset, because the final outcome is not fully known.

Teams work on a final product that can be delivered some time – often months or years – after the project begins. Sometimes, the end product or project is no longer relevant, because business or customer needs have changed.

Ultimately, traditional project management is often best in a stable environment, where a defined deliverable is needed for a fixed budget. Agile is often best where the end-product is uncertain, or where the environment is changing fast.

About the Process Agile Project Management is also different from other project management techniques in the roles and events it uses. We've outlined these below.

"Scrums" and "Sprints" The heart of Agile Project Management is the "scrum" framework. This uses specific roles, events, meetings, and increments to deliver a usable product in a specific time frame – for example, within 30 days. The framework involves three key roles: 1. The product owner is an expert on the product being developed. He or she represents key stakeholders, customers, and end users, and is responsible for prioritizing the project and getting funding. The product owner describes how people will use the final product, communicates customer needs, and helps the team develop the right product. His or her expertise also helps combat scope creep. 2. The scrum master is responsible for managing the process. This person solves problems, so that the product owner can drive development, and maximize return on investment. The scrum master ensures that each sprint is self-contained, and that it doesn't take on additional objectives.

The scrum master oversees communication, so that stakeholders and team members can easily understand what progress has been made. 3. The team is the group of professionals responsible for turning requirements into functionality. The team will work on each project via "sprints" – short phases of work which deliver completed, tested, documented, and functioning products at their conclusion. Each sprint begins with a sprint planning meeting. Here, team members decide what they can deliver within the agreed timeframe. They define the goal and assign task responsibilities. During the sprint, team members focus solely on achieving their defined goal. They will meet every day for a 15-minute meeting to report on progress, to discuss what they will work on that day, and to talk through any challenges that they're facing. (Meeting participants are encouraged to stand up so that meetings are quick and efficient.) These meetings are an essential part of the daily inspection process. Teams are free to change their approach, based on what works for the specific project.

Reporting In Agile Project Management, there are regular opportunities for reporting on progress. As well as daily scrum meetings, team members meet the product owner and key stakeholders after each sprint to present the sprint deliverable. In this meeting, the group decides together what they should change for the next sprint. After this, the scrum master (and sometimes the product owner) holds a retrospective meeting, in which they look at the process that they used in the last sprint and decide what they can improve for the next one. Tip:

If you're working with a virtual team, make sure that everyone is using the same instant messaging (IM) software to speed communication. Virtual meeting software is essential for daily scrum meetings. Social media can also be useful for helping team members collaborate between meetings.

Key Points Agile Project Management aims to deliver fully working upgrades of a product or process on a regular basis – typically, every 30 days. It's ideal for software development and other projects where requirements are likely to change during the project – for example,

in new or fast-growing businesses or in fast-changing business environments. Teams are entirely self-managed and have the freedom to change their approach when needed. This flexibility can save costs and ensure that the final product meets customers' needs.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... SimonICT wrote Just thought I'd share my experiences after my departments 1st anniversary of agile review session. Firstly, it's the best tool I've used for fast paced projects. However, there area a few areas we are adjusting or have learnt. In our environment their are 9 staff working on a multitude of different projects or activities simultaneously. 1) a strong scrum master / project manager is key. We have missed project deadlines when a team member doesn't claim to be blocked on their progress but doesn't complete their activities in time. Scrum master needs to pick this up. 2) Estimating is an issue, young inexperienced teams struggle

with any abstract concept, so you need to use man hours as a simple guide. 3) track time spent vs. the estimate. We have never done this but will start to. Basically when a very technical piece of work is estimated at 20 hours but takes 4 weeks, you need to reflect on why that is and have evidence. 4) The team must be committed to make it work. When you get attitude or poor performance sprints fail and scrum master is a very stressful job. 5) metrics. Can't say this enlighten that our biggest mistake was our failure to capture enough metrics or produce burndown charts. The more metrics you have the better you can plan. Also, in a multi-project environment you need to see the impact of blocks and under estimation on completion dates. 6) use the right tools, there are lots of good software tools to manage agile projects and you need to make sure you use one that fits your purpose. Hope that's of use to people Simon June 2, 2013 kjvishwa wrote Thanks James and rtab. May 14, 2013 James wrote Hi Flaffy My pleasure! I do encourage you to do this. It's an incredibly powerful approach, in the right situations. James May 14, 2013 flaffyeg2013 wrote Hi James, Thank you your reply is very helpful and I think I need to go more in depth in agile if I would like to use its methodology, thanks. Flaffy May 13, 2013

rtab wrote Hi Viswanath I think you would need to have a very good reason to swap methodology when a project is in flight. Waterfall and Agile is vastly different. Not only in deliverables but team dynamics, roles and responsibilities and technical practices. It would also be a huge change program for the project team and project stakeholders. Only if a project is in dire problem and the review and analysis has indicated that the waterfall methodology is an issue. On your other questions, I would argue that regardless of what methodology the project adopts, the outcome is known. A project has a product/ service to be delivered, business benefits have been identified but there are uncertainty on what the requirements are. Key activity at the end of each sprint is the playback. Where the project team or Product Owner showcases the deliverable of the sprint to the business stakeholders. This is not a replacement for system testing but shows what is delivered. Length of sprint varies and depends on the team, compexity of the product and a myriad of other factors. I love Agile as a methodology. I think its a great tool to have in your toolkit. Cheers rtab May 13, 2013 James wrote Hi Flaffy and Vishwanath Thank you for your reply, so the period of measuring sprints are tailored to match the business requirements and not fixed by exactly 30days. Yes. However, it's important that the length of each sprint is fixed (although not necessarily always the same) rather than being flexible - this means that people have a static deadline towards which they're working. This also helps to establish a regular "heartbeat" of releases which keeps a project moving forwards. I think that Agile projects are used mostly during developing new technology or product's on factories or manufactures stages when we don't know what the outcome will be? and need to inspect every stage to see if it works and meets customer requirements or not. Is it O.K? Yes on both points.

Would you please give me an example for the projects that you use agile for it within mind tools and how do you practically apply Scrums and Sprints on them? As examples, our iOS and Android development streams are run using Agile. You'll soon see a series of releases around the Personal Learning Plan that has been managed using Agile, and we've been running a major series of systems infrastructure projects using it. Our scrums are informal - many of our developers work in the same physical space. We manage sprints formally, with a presprint planning meeting a few days before the sprint, a mid-sprint update meeting, and a sprint close meeting to review progress. Is it possible to switch to the agile methodology for any in-flight waterfall project? Are there any best practices/case studies available for this? Hmmm. I'd look at what you're trying to achieve. If you're working towards a fixed deliverable to be delivered by a fixed date, I'd stick with traditional project management. If you're in an uncertain environment with an uncertain end product, then I'd look at Agile... They are very different approaches, and you'd need to look carefully at the specific situation if you were considering changing approach. I'm not sure if my answer helps... May 13, 2013 kjvishwa wrote Hi James - Is it possible to switch to the agile methodology for any in-flight waterfall project? Are there any best practices/case studies available for this? Thanks in advance, Vishwanath May 12, 2013 flaffyeg2013 wrote Hi James again, Would you please give me an example for the projects that you use agile for it within mind tools and how do you practically apply Scrums and Sprints on them? Flaffy May 12, 2013 flaffyeg2013 wrote

Hi James, Thank you for your reply, so the period of measuring sprints are tailored to match the business requirements and not fixed by exactly 30days. I think that Agile projects are used mostly during developing new technology or product's on factories or manufactures stages when we don't know what the outcome will be? and need to inspect every stage to see if it works and meets customer requirements or not. Is it O.K? Flaffy May 12, 2013

Return to top of the page

Beckhard and Harris' Change Equation Overcoming Resistance to Change Traditionally, "change projects" have often been driven by technology implementations or upgrades, with business processes and working practices being changed to fit in with the new system. In today's turbulent economy, however, change is just as likely to be driven by something else: a longCan people see that the alternative would be better? established competitor © iStockphoto/mikdam unexpectedly going bust, for example, or your bank calling in a loan, or a layer of middle management being made redundant. Whatever the situation, when change looms on the horizon, chances are that you'll hear things like: • "I can't believe that restructuring the sales force is really going to increase sales." • "Upgrading the system is such a disruption. I just don't see why we need to go through all that work." • "Our current system isn't great, but what's so wonderful about the new one? How will that be any better?" • "I know that Corascon going under should be good news for us, but I can't work out what I should be doing about it." With comments like these flying around, how will you get everyone to agree with the changes you have in mind? After all, you can't do this without them! This is where Beckhard and Harris' Change Equation can help. In this article, we'll look at this equation, and see how you can use it to roll out successful change in the future.

Explaining the Change Equation Richard Beckhard and Rubin Harris first published their change equation in 1977 in "Organizational Transitions: Managing Complex Change," and it's still useful today. It states that for change to happen successfully, the following statement must be true: Dissatisfaction x Desirability x Practicality > Resistance to Change Beckhard, Richard; Harris, Reuben T., Organizational Transitions: Managing Complex Change, 2nd, © 1987. Electronically reproduced by permission of Pearson Education, Inc., Upper Saddle River, New Jersey.

This seems to be a simple statement, but it's surprisingly powerful when used to structure a case for change. Let's define each element, and look at why you need it: • Dissatisfaction – Your team has to feel dissatisfied with the current situation before a successful change can take place. Without dissatisfaction, no one will likely feel very motivated to change. Dissatisfaction could include competition pressures ("We're losing market share") or workplace pressures ("Our sales processing software is crashing at least once a week"). Dissatisfaction can be any factor that makes people uncomfortable with the current situation. • Desirability – The proposed solution must be attractive, and people need to understand what it is. If your team doesn't have a clear vision of what things will be like after the change, and why things will be better, then they probably won't be willing to work to deliver it. The clearer and more detailed you make this vision, the more likely it is that your team will want to agree with the change and move forward. • Practicality – Your team must be convinced that the change is realistic and executable. • Resistance to change – Resistance to change includes people's beliefs in the limits of the change ("A new system won't fit with our unusual business process"), stubbornness toward any change ("I don't want to have to learn how to use a new system"), and general inertia or lack of interest at the beginning. And because there's a multiplicative relationship between Dissatisfaction, Desirability and Practicality, if one element is missing, that variable will have a value of zero – meaning that this whole side of the equation will equal zero.

How to Use the Tool Beckhard and Harris' change equation is most useful as a checklist in the planning and communication stages of a major change. When you're planning your change process, consider each variable to make sure your team (a) feels dissatisfied with the current situation and (b) believes the future state is both desirable and practical. Consider the sales processing system we touched on earlier, which is crashing regularly. Right now, the system might crash only once a week – this is inconvenient, but it's not painful. So overall, your team may be reluctant to go through the all the work involved in an upgrade. When you use the equation, you see that the number of crashes doesn't cause the team members to be dissatisfied enough to make the change. It's your job to give them a clear vision of what their lives would be like if they don't make the upgrade. For example, let them know that even though the system currently crashes only once a week, it will eventually start crashing every day – and then multiple times every day. When that happens, the team will get behind on their work, and they'll have to stay late to get it finished. A picture like this will probably increase their dissatisfaction

with the current system. (Of course, it's always possible that they're satisfied with the existing approach, that the change doesn't deliver sufficient benefits, or that the plan isn't practical – in this case you need to revisit the case for change!) Also, make sure you share enough details about the technical aspects of the change to help people understand how things will be better. Suppose the new system, in addition to fixing the current problems, also has the capacity to handle 500 times more transactions simultaneously. If people don't know this, they may not be convinced of the desirability of the upgrade! And finally, be clear about what you, and your team, will need to do to make the change from the current state to the desirable new state. In particular, identify first steps that will help you increase people's confidence in the practicality of the proposed change.

Key Points Implementing change is no small task. But using Beckhard and Harris' change equation during the planning process is a quick but effective way of ensuring that your team understands why change is necessary, why your proposed "to be" state will be better, and what they need to do about it now! When all of this is in place, you will greatly improve the likelihood that your change will be successful.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... bigk wrote Hi Ladyb Agree with your comments here. Priority can always be changed during the stages of a project or change for adequately justified reasons, mostly they do not. It can be an opportunity, now and ahead for developing good team relationships and development of people. Not sure what to call this... seems you are suggesting it runs in parallel through the project or change with the team relationship, both before and after the project or change which I agree would build a strong team, even if not working together after the project until another project. I could suggest it be called... supporting people and helping them get value for their contributions. Excuse my hesitation by looking for a kind of resource instead of a combined team and manager solution. I would always seek to solve with the team but add specialist input if needed. Excuse my forgetting, as it seems. I agree all the time is all the time, keeping the needs of people in focus are essential to help the manager and the people or team. Thanks for helping me find this. Growing seems logical again. Bigk August 4, 2009 ladyb wrote Hi BigK - you ask what time is best for team development? I say the best time is all the time. Whether you are part of a change project right now, considering a change project in the future, or just completing a change project, team development is a priority. Without the proper tools, training, support, and resources any changes you want to implement won't be as effective as they could be. Does that mean team development is your priority during a change initiative? No. But it does mean that it's something you should always have in your mind as you plan and prepare to implement changes. I think if we as managers can remember to keep the needs of our people in the forefront of our minds we will enjoy much better results and have happier and more satisfied people. Brynn

August 3, 2009 bigk wrote Hi Yolande A lengthy reply. These tools are helpful. I have worked through some of this already. But I will go over these again and see what improvements I can gain. I am currently doing some work with the project management tools and the change tools. These are useful and I find that although I can identify and use the ideas, I am left with some questions yet, but I will work through what I might need and reply further if there is something I have missed. It may be that another area is where I need to focus for the answer I am seeking just yet. Hope I did not confuse you with my earlier response and was not clear enough in my explanation. Perhaps the item I was trying to convey was about team member development and not just the team development or change management. I wanted to assess how the change curve needs a manager to accept some further responsibility for team members and the change dynamics in the negative curve of the change is part of human behavior that could be utilized as a strength in the team, rather than a weakness in the team at this stage and the manager could use this information to be more aware of how the change is progressing and how it is affecting individual members and the team. Maybe this would be a strength in the manager by giving access to support. At this point he or she could provide ways of giving better support to the team whilst acknowledging that the manager at this time might find he or she wants some additional support or consideration from management that there needs to be more human support if issues arise that are not part of the ordinary project change and expected project outcome. This might separate the team from the project but if the team performance is assessed as part of the project then giving the manager and the team better support or access to resources for personal development would be useful and would help the team deliver the results and deliver development needs for the team members that could be developed after the project. It would likely be development team work needed after the project change, but these might be team member development of personal development and not an outcome of project change delivery.

Maybe this could just be delivered as additional support from human resources? Do you feel these issues although mostly about team member development, could be handled at the time of project change? What other time would be a time for doing this except after the project completion? Thanks Bigk August 2, 2009 Yolande wrote Hi bigk I'm not quite sure if this is what you are looking for, but you may still find these articles of interest with regards to change. Burke-Litwin Change Model – Unraveling the Dynamics of Organizational Change http://mindtools.com/community/pages/ar ... PPM_90.php Kotter's 8-Step Change Model – Implementing change powerfully and successfully http://mindtools.com/community/pages/ar ... PPM_82.php Kind regards Yolandé August 2, 2009 bigk wrote Hi I found this tool seemed to suggest that the danger zone (negative curve) suggested a time of information flow and relationship building being critical. In all stages of this curve when applied to change, it seems there may be risk or exposure in the area of negativity, but the actions suggest giving support and it seems that awareness would be the most important although having understanding or building on existing or new relationships with the team going through the change it could be used as a stage to better these relationships and give more support to develop success. Using empathy or similar awareness of team member issues would surely be a good ficus to lessen the impact of the negative curve. However I see that the curve here although suggesting an exposed time of weakness might be used to build a stronger team relationship and strengthen the team. This could help provide more information or take account of other issues that the people might be faced with also handling while a change is in progress.

If allowing for any negative effect but helping to lessen the curve impact is important then so to is developing a better understanding of the team and it's working relationships as the change progresses. Giving time for the change to be adapted or implemented and giving reassurance that the change can deliver benefits to the team would help at this stage. Are there any particular issue to explore from the project management tools about this or are these more people skills and team workings? I have explored some of the project management tools already and team tools or skills. Where could I get details about change in this context that is about team support or personal support and define a method or set of tools to administer team relationships and performance? Thanks Bigk August 2, 2009

Return to top of the page

Benefits Management Getting the Greatest Possible Benefit From a Project Projects are the engines of change within most organizations. When you decide that you need something new, or you need something old done in a new way, a project is born. From then on, efforts focus on planning, preparing, executing, monitoring, and managing this project.

Getting the very most from your projects. © iStockphoto

But have you ever had a project that ultimately didn't deliver the benefits you needed? A great deal of time can elapse between the time that a project is created, and its completion. Things can change along the way as you overcome obstacles. And even very small shifts in project design and execution can affect whether the benefits you wanted when you created the project are still addressed in the final outcome. When there's a weak connection between the project's deliverables and the organization's needs, then there's a risk that the benefits of a project may be lost along the way. (This is particularly the case when the project team is separate from the project's client.) This is where it makes sense to establish a clear case for the project – so that you can make sure that the deliverables meet expectations, and give the organization the benefits it expects.

Starting With the End "Benefits Management" is the process by which you ensure that your projects deliver what you want. Done effectively, it helps ensure that your project's deliverables give value to the business, and the appropriate return on investment. In the benefits management process, you answer questions like these: • Why are we doing this? • What business objective will this project help to meet? • Have we defined all of the benefits we're expecting? • Have we justified the time and expense of the project? • How will we measure the benefits? • Is the project still valid? • Are the benefits still relevant? Investing your time in benefits management helps you reduce the overall risk of the project. It forces you to look at organizational issues

that might hurt a project's success, and then deal with those issues in the project plan. After all you begin by knowing what you want the end result to look like, you'll likely improve your ability to predict and avoid many potential obstacles.

The Benefits Management Process A benefit is the desired result of a project that was created to meet a particular operational need. For example, a project designed to reduce the time it takes to process an order has benefits such as improved customer service, increased sales, and reduced frustration for sales staff who have to deal with customer complaints. The whole point of benefits management is to make sure that your project provides clear benefits – as opposed to simply making sure the project is completed within specific time and resource limitations. So, while the success of project management is to deliver on time and on budget, the success of benefits management takes it one step further – to ensure that the initiative delivers the expected results. Here are the main phases of benefits management:

Phase One: Define and develop the benefits During project initiation: • Talk to all stakeholders to figure out which benefits and outcomes each expects – and why. • Create a benefits statement. • List the final benefits that you want, and make sure you've distinguished between "must haves" and unaffordable "nice-to-haves". • Identify how the benefits are aligned with the company's strategy, and the needs of the business. • Decide what must happen in connection with the project to maximize benefits. • Identify the changes, or other projects, needed to support and achieve the outcome of the main project, and make sure that these are in the plan. For example, do workers need extra training? Do you need a new advertising campaign to tell the market about your new feature? Or do you need to hire additional people, or buy new equipment to take full advantage of the change? • Extend the cost-benefit analysis you've identified.

to include the benefits

• Remember to look for tangible and intangible benefits. For a list of the types of benefits which stakeholders may be seeking, see Miadanu's helpful post on the subject in the Club forum.

Phase Two: Develop the benefits plan Again, during project initiation:

• Look at the overall project plan, and make sure that the appropriate supporting activities are included, so that you can ensure that benefits are achieved on time. Use traditional project management tools, like Gantt charts and PERT charts, to complete and track your benefits schedule. • Watch out for gaps in benefits, as well as additional benefits. • Identify who is accountable for delivering these supporting activities. • Establish metrics for each benefit, and determine when and how you'll determine that the benefit has been delivered. • Determine how the benefits will be reported. You can use milestone reports as well as a benefits dashboard as reporting tools. • Include a benefits management summary in the business case for the project.

Phase Three: Monitor the benefits during project implementation As the project moves forward: • Regularly monitor your progress towards delivering the expected benefits. • Modify the benefits plan as needed when the overall project plan changes. • Establish a communication system between yourself and the project manager (if this is a different person). This helps ensure that you routinely discuss and consider the benefits. • Provide support to the project team, and use the benefits statement to encourage their work. • Watch for "benefits creep" – make sure that people's expectations don't grow too much during the project. When you start to expect too many benefits, this can weaken the project's overall impact, and lead to disappointment when imagined benefits are not delivered. If your benefits-required list keeps growing, it's often better to create separate projects for each specific intention and focus. See more tips on scope control .

Phase Four: Complete the project, and review your benefits Towards the end of the project: • Identify the benefits that were achieved, and look for gaps and missed opportunities. • Monitor your workers' ongoing needs to ensure that they continue to enjoy the benefits. Consider setting up a system to communicate future needs. This is a way to collect ideas for future projects. • Record what went well and what needed improvement. This supports continuous learning within your organization.

Key Points Benefits are the reason any project is created and implemented. Benefits management is all about ensuring that the hard work and investment that's gone into the project gives the greatest possible business return. Projects tend to change over their lifecycles, and even small shifts can produce different results. That's why it's important to focus on the project's benefits, and not just its timely completion. Benefits management forces you to stay focused on why you started the project in the first place. And it doesn't stop after the project ends, like traditional project management – it continues until all benefits are clearly achieved. You can use the same project planning framework as the rest of the project to do this, but you'll need to build in benefit-specific milestones, as well as establishing accountabilities clearly, and setting up appropriate communications systems. Done this way, benefits management can be a smart addition to a comprehensive project management plan.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote

Hi mravaisqureshi, Welcome to the forums and thanks for the question. If you are wondering about it then guaranteed other people are as well. The reason why "Identify the changes, or other projects, needed to support and achieve the outcome of the main project" is important is that you want to look at this project in the context of the whole organization. Projects often don't happen in isolation what you are doing in one project will impact other parts of the organization. Likewise, other things going on outside the project can impact its success. So what this step is asking you to do is take a look at exterior variables that need to change or other projects that need to happen before your project can achieve success. A very simple example might be you are working on a project to design a new and improved website for the business. You and your team plan all the design changes and are excited about launching the new site but at the same time the technical staff might have to be working on a project to upgrade the technology that supports the website. This new design might also mean a change in some administrative processes. Does that clarify what is meant? With "Supporting activities" this refers to all the planning and administrative details involved in bringing a project together. Again with the website design example, supporting activities might include your project schedule, hiring of contract workers to help with the project, and setting up a liaison with the tech team to make sure everyone stays informed. These are again activities that will help keep the big picture insight and ensure your project is successful and creates benefit for the organization. Let me know if this helps. I'm happy to provide different examples or clarify more. And if anyone else has information to add please do so. Project management is complex area so there are bound to be areas of confusion. Dianna April 7, 2011 mravaisqureshi wrote Hi there, I'm not sure on what is meant by "Identify the changes, or other projects, needed to support and achieve the outcome of the main project." I'm equally not sure what is meant by 'supporting activities'. Could someone please clarify?

Thank you in advance April 7, 2011 bigk wrote Hi If the project deliverable and benefits can be aligned to longer term objectives this would help deliver more benefits but to the team and the anticipated outcomes. If the demands and the results can be varied in the schedule, the results got can also be used for other projects. Follow up can be used throughout the project(s). At the project start if the impacts and benefits can be reused in other projects it would help define the expected demands from current and future expectations. The project and it's benefits could be condensed to a few items and the items assessed as the project progresses with the deliverable item assessed on result needed, the result expected, the after project or result expected for use in future projects or development of team results. Bigk September 19, 2009 Yolande wrote A number of years ago I was involved in a huge project in Lesotho (not too far from where I live - about 1½ hrs by car) and we drove there every day for six months, then twice a week for almost a year. Seeing that I didn't have much experience with regards to project management at the time, I made many mistakes and wasted a lot of (my own) time.... Articles such as these and all the tips given by Miadanu (in her posting referred to in the article) would have helped me a lot. In the end it was a successful project and I wouldn't want to exchange the experience gained for anything. The monitoring phase was the part that I found the most difficult because of the physical distance; lack of technology in Lesotho made it difficult to utilise Internet & e-mail as we do in South Africa and much of the monitoring had to be done physically. The following was a very real challenge we had to deal with and it caused numerous challenges which we had to handle (and I quote from the article): Watch for "benefits creep" – make sure that people's expectations don't grow too much during the project. When you start to expect too many benefits, this can weaken the project's overall impact, and lead to disappointment when imagined benefits are not

delivered. Fortunately I had a mentor who helped me a lot and today I am really comfortable with quite large projects. Kind regards Yolandé September 24, 2008

Return to top of the page

Bridges' Transition Model Guiding People Through Change People are often quite uncomfortable with change, for all sorts of understandable reasons. This can lead them to resist it and oppose it. This is why it's important to understand how people are feeling as change proceeds, so that you can guide them through it and so that – in the end – they can accept it and support it.

Help people make a smooth transition during change. © iStockphoto/maigi

Bridges' Transition Model helps you do this. We'll explore the model in this article.

About the Model The Transition Model was created by change consultant, William Bridges, and was published in his 1991 book "Managing Transitions." The main strength of the model is that it focuses on transition, not change. The difference between these is subtle but important. Change is something that happens to people, even if they don't agree with it. Transition, on the other hand, is internal: it's what happens in people's minds as they go through change. Change can happen very quickly, while transition usually occurs more slowly. The model highlights three stages of transition that people go through when they experience change. These are: 1. Ending, Losing, and Letting Go. 2. The Neutral Zone. 3. The New Beginning. Bridges says that people will go through each stage at their own pace. For example, those who are comfortable with the change will likely move ahead to stage three quickly, while others will linger at stages one or two. Let's examine each stage in greater detail.

Stage 1: Ending, Losing, and Letting Go People enter this initial stage of transition when you first present them with change. This stage is often marked with resistance and emotional upheaval, because people are being forced to let go of something that they are comfortable with.

At this stage, people may experience these emotions: • Fear. • Denial. • Anger. • Sadness. • Disorientation. • Frustration. • Uncertainty. • A sense of loss. People have to accept that something is ending before they can begin to accept the new idea. If you don't acknowledge the emotions that people are going through, you'll likely encounter resistance throughout the entire change process.

Guiding People Through Stage One It's important to accept people's resistance, and understand their emotions. Allow them time to accept the change and let go, and try to get everyone to talk about what they're feeling. In these conversations, make sure that you listen empathically and communicate openly about what's going to happen. Emphasize how people will be able to apply their skills, experience, and knowledge once you've implemented the change. Explain how you'll give them what they need (for instance, training and resources) to work effectively in the new environment. People often fear what they don't understand, so the more you can educate them about a positive future, and communicate how their knowledge and skills are an essential part of getting there, the likelier they are to move on to the next stage.

Stage 2: The Neutral Zone In this stage, people affected by the change are often confused, uncertain, and impatient. Depending on how well you're managing the change, they may also experience a higher workload as they get used to new systems and new ways of working. Think of this phase as the bridge between the old and the new; in some ways, people will still be attached to the old, while they are also trying to adapt to the new. Here, people might experience: • Resentment towards the change initiative. • Low morale and low productivity. • Anxiety about their role, status or identity. • Skepticism about the change initiative. Despite these, this stage can also be one of great creativity, innovation, and renewal. This is a great time to encourage people to try new ways of thinking or working.

Guiding People Through Stage Two Your guidance is incredibly important as people go through this neutral period. This can be an uncomfortable time, because it can seem unproductive, and it can seem that little progress is being made. Because people might feel a bit lost, provide them with a solid sense of direction. Remind them of team goals, and encourage them to talk about what they're feeling. Meet with your people frequently to give feedback on how they're performing, especially with regard to change. It's also important to set short-term goals during this stage, so that people can experience some quick wins ; this will help to improve motivation as well as giving everyone a positive perception of the change effort. Also, do what you can to boost morale and continue to remind people of how they can contribute to the success of the change. If required, you may also want to help people manage their workloads, either by deprioritizing some types of work, or by bringing in extra resources.

Stage 3: The New Beginning The last transition stage is a time of acceptance and energy. People have begun to embrace the change initiative. They're building the skills they need to work successfully in the new way, and they're starting to see early wins from their efforts. At this stage, people are likely to experience: • High energy. • Openness to learning. • Renewed commitment to the group or their role.

Guiding People Through Stage Three As people begin to adopt the change, it's essential that you help them sustain it. Use techniques like Management by Objectives to link people's personal goals to the long-term objectives of the organization, and regularly highlight stories of success brought about by the change. Take time to celebrate the change you've all gone through, and reward your team for all their hard work. However, don't become too complacent – remember that not everyone will reach this stage at the same time, and also remember that people can slip back to previous stages if they think that the change isn't working. Tip 1:

Don't get impatient or try to push people through to stage three; instead, do what you can to guide them positively and sensitively through the change process.

Tip 2:

Bridges' Transition Model is similar to the Change Curve in that it highlights the feelings that people go through during change. Both models are useful in helping you guide people through change, and they fit together well. Tip 3:

While the model can help you guide people through change more effectively, it's not a substitute for change management tools such as Kotter's 8-Step Model and Lewin's Change Management Model . Use Bridges' model alongside these tools.

Key Points Change consultant William Bridges developed and published the Transition Model in his 1991 book "Managing Transitions." The model highlights the difference between change and transition. Change happens to people. Transition, on the other hand, is internal: it's what happens inside people's minds when they're presented with change. You can use the model to understand how people feel as you guide them through change. It has three distinct stages: 1. Ending, Losing, and Letting Go. 2. The Neutral Zone. 3. The New Beginning. While the model is useful for implementing change, it's not a substitute for other change management approaches. Use it alongside these in your change projects.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly version

Ask questions, or share your experience Return to top of the page

Business Requirements Analysis Clearly Agreeing What You're Going to Deliver Every new activity, every new product, every new project in the workplace is created in response to a business need. Yet we often find ourselves in situations where, despite spending tremendous time and resources, there's a mismatch between what has been designed and what is actually needed.

Scrutinizing needs in sufficient detail.

© iStockphoto Has a client ever complained that what you delivered isn't what she ordered? Has someone changed his mind altogether about the deliverable, when you were halfway through a project? Have you had conflicting requirements from multiple clients? And have you ever received new requirements just after you thought you'd finished creating a product?

A focused and detailed business requirements analysis can help you avoid problems like these. This is the process of discovering, analyzing, defining, and documenting the requirements that are related to a specific business objective. And it's the process by which you clearly and precisely define the scope of the project, so that you can assess the timescales and resources needed to complete it. Remember: to get what you want, you need to accurately define it – and a good business requirements analysis helps you achieve this objective. It leads you to better understand the business needs, and helps you break them down into detailed, specific requirements that everyone agrees on. What's more, it's usually much quicker and cheaper to fix a problem or misunderstanding at the analysis stage than it is when the "finished product" is delivered. Tip:

Many organizations already have established procedures and methodologies for conducting business requirements analyses, which may have been optimized specifically for that organization or industry. If these exist, use them! However, do make sure you also consider the points below.

How to Use the Tool Below is a five-step guide to conducting your own business requirements analysis.

Step 1: Identify Key Stakeholders Identify the key people who will be affected by the project. Start by clarifying exactly who the project's sponsor is. This may be an internal or external client. Either way, it is essential that you know who has the final say on what will be included in the project's scope, and what won't. Then, identify who will use the solution, product, or service. These are your end-users. Your project is intended to meet their needs, so you must consider their inputs. Tip:

Make sure that your list is complete: remember, end-users for a product or service might all be in one division or department, or they might be spread across various departments or levels of your organization. Our article on Stakeholder Analysis will help you identify stakeholders.

Step 2: Capture Stakeholder Requirements Ask each of these key stakeholders, or groups of stakeholders, for their requirements from the new product or service. What do they want and expect from this project? Tip 1:

Remember, each person considers the project from his or her individual perspective. You must understand these different perspectives and gather the different requirements to build a complete picture of what the project should achieve. Tip 2:

When interviewing stakeholders, be clear about what the basic scope of the project is, and keep your discussions within this. Otherwise, end-users may be tempted to describe all sorts of functionality that your project was never designed to provide. If users have articulated these desires in detail, they may be disappointed when they are not included in the final specification. You can use several methods to understand and capture these requirements. Here, we give you four techniques: • Technique 1: Using stakeholder interviews Talk with each stakeholder or end-user individually. This allows you to understand each person's specific views and needs. • Technique 2: Using joint interviews or focus groups Conduct group workshops. This helps you understand how information flows between different divisions or departments, and ensure that hand-overs will be managed smoothly.

Tip:

When using these two methods, it's a good idea to keep asking "Why?" for each requirement. This may help you eliminate unwanted or unnecessary requirements, so you can develop a list of the most critical issues. • Technique 3: Using "use cases" This scenario-based technique lets you walk through the whole system or process, step by step, as a user. It helps you understand how the system or service would work. This is a very good technique for gathering functional requirements, but you may need multiple "use cases" to understand the functionality of the whole system. Tip:

You might want to find existing use cases for similar types of systems or services. You can use these as a starting point for developing your own use case. • Technique 4: Building Prototypes Build a mock-up or model of the system or product to give users an idea of what the final product will look like. Using this, users can address feasibility issues, and they can help identify any inconsistencies and problems. You can use one or more of the above techniques to gather all of the requirements. For example, when you have a complete list of requirements after your interviews, you can then build a prototype of the system or product.

Step 3: Categorize Requirements To make analysis easier, consider grouping the requirements into these four categories: • Functional Requirements – These define how a product/ service/solution should function from the end-user's perspective. They describe the features and functions with which the end-user will interact directly. • Operational Requirements – These define operations that must be carried out in the background to keep the product or process functioning over a period of time. • Technical Requirements – These define the technical issues that must be considered to successfully implement the process or create the product. • Transitional Requirements – These are the steps needed to implement the new product or process smoothly.

Step 4: Interpret and Record Requirements Once you have gathered and categorized all of the requirements, determine which requirements are achievable, and how the system or product can deliver them. To interpret the requirements, do the following: • Define requirements precisely – Ensure that the requirements are: • Not ambiguous or vague. • Clearly worded. • Sufficiently detailed so that everything is known. (Project over-runs and problems usually come from unknowns that were not identified, or sufficiently well-analyzed.) • Related to the business needs. • Listed in sufficient detail to create a working system or product design. • Prioritize requirements – Although many requirements are important, some are more important than others, and budgets are usually limited. Therefore, identify which requirements are the most critical, and which are "nice-to-haves". • Analyze the impact of change – carry out an Impact Analysis to make sure that you understand fully the consequences your project will have for existing processes, products and people. • Resolve conflicting issues – Sit down with the key stakeholders and resolve any conflicting requirements issues. You may find Scenario Analysis helpful in doing this, as it will allow all those involved to explore how the proposed project would work in different possible "futures". • Analyze feasibility – Determine how reliable and easy-to-use the new product or system will be. A detailed analysis can help identify any major problems. Once everything is analyzed, present your key results and a detailed report of the business needs. This should be a written document. Circulate this document among the key stakeholders, end-users, and development teams, with a realistic deadline for feedback. This can help resolve any remaining stakeholder conflicts, and can form part of a "contract" or agreement between you and the stakeholders.

Step 5: Sign Off Finally, make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder groups, saying that the requirements as presented precisely reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer from scope creep later one.

Key Points The key to a successful business requirements analysis is identifying what the new system or product will do for all appropriate end-users/stakeholders – and to understand what they WANT the new system or product to do. You can use various techniques to gather requirements, but make sure those requirements are clear, concise, and related to the business. This process also helps you identify and resolve any conflicting requirements issues early on. Once you complete your analysis, record it in a written document. This becomes the "contract" for creating the product or system that addresses all the needs of your business or your client.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... paul_murray wrote Hi Dianna, I feel much more on board with getting in front of end users and stakeholders now. Even though I have gathered feedback indirectly through various other non-related meetings, I think, taking the time to focus on discussing requirements specifically

for this project, could very well unlock some great ideas. Thanks for your insights, going to have a coffee now and have a read of your article. Paul September 26, 2012 Dianna wrote Hi Paul, I think situations like this come down to a cost vs. benefit analysis. What benefits will you reap by conducting the survey? As Midgie says, will the additional feedback help you structure your project and ensure stakeholder buy in? On the surface of it I think you will probably derive a lot of benefit from talking with the stakeholders. Any type of change initiative will meet with some degree of resistance - it's human nature. When you involve people in the change from the very early stages you are able to breakdown many of these resistances before they even rear their ugly heads. And you never know where the next great idea might come from. It's possible that one of the people you survey has an innovative idea, or something you can build on, that you wouldn't have thought of on your own. And remember too that there are many ways to get feedback from people. You can develop a simple online survey or conduct small group sessions. decide which method is the most efficient and which will make sure you are on the benefit side of the cost/ benefit equation. One of my favorite articles on change is the one one why change can fail. It comes at the issue from the back end and has lots of great tips. Here is the link if you are interested in reading it: http://www.mindtools.com/community/pages/article/ newPPM_81.php Dianna September 26, 2012 Midgie wrote Hi Paul, What a great question to ask ... should any of us still spend time doing the research / interviews to come up with the answers that we already know? My personal view is definitely yes! By doing the interviews and finding out what the stakeholders want and need, and what they identify as missing, you will then have the 'evidence' to back up what you are doing. Otherwise, you might proceed only to find out later that big

chunks were missing. The benefit of doing the interviews is that you might reveal aspects that you didn't expect. These could ultimately add more benefit to the overall project. Let's see what others' views are. Hope that helps. Midgie September 25, 2012 paul_murray wrote Hi All, The article on business requirements analysis is great. I do have a question, and maybe it is not meant for this discussion thread, so correct me if I am wrong (I just joined). I am currently initiating a project to improve and re-design our company Intranet. At the moment, there is a lot of functionality missing, so I know what a lot of the work is and what needs to be done, however, should I spend the time to still survey/interview my stakeholders, even if I feel confident the answers I get back will fit with what I know? Kind regards, Paul September 25, 2012 Midgie wrote Hi Ben and Lunitaire, I agree that a template would add value to this article. I've passed the request to our editorial team to look at and hopefully they will be able to do something soon. Midgie June 21, 2012 lunitarie wrote I completely agree with Ben- this is a very well written and informative topic. A template would definately add value to an already great article! June 20, 2012 ChaiLatte wrote Can you create a PDF file for this Business Requirements Analysis topic? I find this write-up extremely useful and it should compliment the What is Project Management workbook, as an

appendix. Thanks. Ben June 20, 2012 Dianna wrote Hi genji, I don't know of a specific format for this type of document. Maybe someone else can provide a template of sorts. I do think that if you take each of the "steps" in the article and use them as headings you will come out with a comprehensive contract to guide your project. Dianna May 30, 2012 genji wrote Good link with useful information. However, I'm wondering if there's a standard format that we can use in creating a Business Requirements Document? I vaguely remember a specific format used in school, but nothing in the article here seems to outline all the necessary sections needed in a strong BRD Document. May 29, 2012

Return to top of the page

Business Testing in Projects Involving Real Users as an Important Testing Step Have you ever been involved with a project that didn't deliver what was expected? The project may have failed to meet expectations because the new process or system didn't work properly. Perhaps users didn't follow the new procedures and caused problems for others.

Real users will give you invaluable feedback.

Or maybe they couldn't understand the training or documentation they'd received.

© iStockphoto/track5

Do you recall hearing people say things like "It was better the way we did it before"? So, how can you avoid this problem? Effective "Business Testing" can help. Testing has a fundamental role in making sure that your projects' end-products are delivered successfully. Business testing (also known as User Acceptance Testing, or UAT) is usually carried out by the people who will be using the product in practice. It ensures that proposed changes actually work – BEFORE they're put into use. In this article, we'll show you how to set up a successful business test. This will help you involve business users and other stakeholders to check that your project delivers the desired results. It also helps you ensure that the systems and procedures you implement work efficiently, effectively and accurately.

How to Use the Tool Consider using business testing in any project where you want to ensure that deliverables are robust and usable before they're implemented. Here are some steps to help you think through your business testing requirements.

Step 1: Learn from other projects Make sure you understand the testing challenges and problems faced on previous projects. Ask your colleagues, or check previous Post-

Implementation Reviews , if they're available. This will give you insight into what tends to work, and what tends not to work in your organization. Remember, history often repeats itself: for example, if other projects have had difficulties getting resources for testing, it's likely that yours will too.

Step 2: Decide what to test Figure out what needs to be tested by considering the following: • Handover points – Consider all handovers between different systems and different groups of people. You'll often find issues in these areas. • Key project risks – Determine your key project risks by using our risk analysis and risk management tool . This analysis will help you identify areas where you need to focus. • End-to-end processes – If possible, test process and system changes from start to finish, including tests for each variation of the process. • Impact assessment – Consider the potential impact of launching your project outputs without testing them. Would errors cost you more money, lose customers, or cause delays? Would these errors be acceptable to the business? Prioritize testing in high risk areas. • Other options – What other options do you have? For example, if you're revising an internal classroom-based training program, you may want to consult key staff in its development. By running a pilot with the first training group, and then making revisions for subsequent groups, you may be able to manage risk sufficiently well to avoid carrying out business tests.

Step 3: Consider what support is needed for your testing process Think about the following elements of testing: • Budget – You may need to include all sorts of cost in your budget. Here are some examples: • Room rental. • Computer equipment. • Printing costs for training material. • Expenses for participants. • Additional staffing or contractors' fees. • The right people – Involve people who perform, or will perform, the tasks being tested. Also, consider the extent to which you want to include the following people: • Key influencers – This is useful where you want to build support for your project with major stakeholders. • Advocates of the new process/system – Advocates will often work hard to make sure that the deliverables meet the requirements. • Resisters to the project (handle with care!) – They're likely to show you how new processes can be

broken, and they'll give you ideas for points to include in any training or support documentation for users. You may even change resisters into advocates as they learn about the benefits of the new system or process! As well as having the right people to perform the tests, think about how you'll manage testing. Your testers will need to know what tests to conduct, and your project team will need to know what changes to make as a result of the tests. • Testing location – Consider how much space you'll need and where it must be located. For example, if a process involves working remotely, you may want to simulate this in the way you set your testing up. • Tester training – Determine what training your testers need. Tip:

Use your end-user training documentation during business testing. When you do, you'll be able to test the training material and the new process or system at the same time! If this isn't possible, use feedback from testing when you develop or finalize your training material. • Documentation – Consider what documentation your testers need. For example, when testing systems, testers often use a series of "test scripts." These take them through individual roles and activities within an end-to-end process. You can then group test scripts to test your whole process. Note:

If you've mapped your new or amended processes using Swim Lane Diagrams , it's usually easy to see how many test scripts you'll need for each end-to-end process.

Step 4: Determine how much testing time is needed You may be able to conduct the testing phase quickly with a small group of people, or you may need more extensive and comprehensive planning. To figure out what's right for your project, consider what you need to test and how you should organize testing. You may have other goals too. For example, it's often appropriate to consider testing as a way to gain support for your project from key stakeholders. Allow time to prepare and train your testers. Without this, they may focus on how the new system or process works and not on finding its problems! Also, include sufficient time and resource to conduct the tests, make any changes needed, retest any revisions, and provide for a contingency. Note that testing usually takes place toward the end of the project. So, if the project has had delays, there may be pressure to shorten the testing time. Be clear about the essential components in your testing approach (there's more information about planning approaches in our article on Critical Path Analysis and PERT

Charts ). Remember, if the deliverables don't work once they're implemented, no one will thank you for skimping on testing! Check when the testing phase is due to take place. It's often difficult to get people released from their regular duties during holiday times or when the business is particularly busy. And make sure that you schedule time after testing to update any training material, supporting documentation, and procedures for users. This will ensure that this information is accurate once testing is complete.

Step 5: Determine what reporting is needed. Consider whether to collect statistics during your testing phase (for example, the number of problems found, the number of problems fixed, and so on), and discuss the overall reporting requirements with your sponsors and other stakeholders. Tip:

Making revisions based on business testing results is often stressful! Project managers want to ensure that their project is delivered on time, within budget, and to the required quality standard; and compromises are sometimes needed to balance these different goals. You can minimize this conflict by putting a scope management process in place, ensuring that roles and responsibilities for managing changes are clear, and including time in the plan for implementing and retesting revisions. You may also need to be assertive to manage unrealistic delivery expectations!

Key Points Business testing is a useful tool for making sure that a new process or system works properly before you implement it. By using this tool, you'll ensure that your testing phase is set up effectively, and that you can influence any decisions that must be made to get the right balance between delivering a project on time, on budget, and to quality standards – even if compromises are needed.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... bigk wrote Hi This could be difficult to solve if the process or system requires implementation immediately on completion of project but feedback and interaction in the testing would be the most effective way to eliminate any issues. The guidance in the resource gives useful indication on how to achieve this Add time and effective testing in the planned feedback assessment, allowing for change at this stage in the project would help keep the results deliverable. The issue is more on what amount of planned or tested issues are included and what issues might be missed, even after all issues are documented or included for the testing needed. Trying to get all the issues known or included is where the focus could be. The next issue might be that too many demands make the project difficult to react quickly at this time. Specialist help could be used in the project, even out with the team if required, as a source of knowledge and guidance. Using effective feedback with user testing is valuable in remembering the projects unique elements or demands and could lead to success. Bigk September 23, 2009

Return to top of the page

Change Management Making Organization Change Happen Effectively Change management is a term that is bandied about freely. Sometimes it's a scapegoat for less than stellar results: "That initiative failed because we didn't focus enough on change management." And it's often used as a catch-all for project activities that might otherwise get overlooked: "When we implement that new process, let's not forget about the change management." It's It's It's It's

© iStockphoto/jpsdk

a noun: "Change management is key to the project." a verb: "We really need to change manage that process." an adjective: "My change management skills are improving." an expletive: "Change management!"

But what exactly is it? Change management is a structured approach for ensuring that changes are thoroughly and smoothly implemented, and that the lasting benefits of change are achieved. The focus is on the wider impacts of change, particularly on people and how they, as individuals and teams, move from the current situation to the new one. The change in question could range from a simple process change, to major changes in policy or strategy needed if the organization is to achieve its potential.

Understanding Change Management Theories about how organizations change draw on many disciplines, from psychology and behavioral science, through to engineering and systems thinking. The underlying principle is that change does not happen in isolation – it impacts the whole organization (system) around it, and all the people touched by it. In order to manage change successfully, it is therefore necessary to attend to the wider impacts of the changes. As well as considering the tangible impacts of change, it's important to consider the personal impact on those affected, and their journey towards working and behaving in new ways to support the change. The Change Curve is a useful model that describes the personal and organizational process of change in more detail. Change management is, therefore, a very broad field, and change management approaches vary widely, from organization to organization and from project to project. Many organizations and consultants subscribe to formal change management methodologies.

These provide toolkits, checklists and outline plans of what needs to be done to manage changes successfully. When you are tasked with "managing change" (irrespective of whether or not you subscribe to a particular change management approach), the first question to consider is what change management actually means in your situation. Change management focuses on people, and is about ensuring change is thoroughly, smoothly and lastingly implemented. And to know what that means exactly in your situation, you must dig down further to define your specific change management objectives. Typically, these will cover: 1. Sponsorship: Ensuring there is active sponsorship for the change at a senior executive level within the organization, and engaging this sponsorship to achieve the desired results. 2. Buy-in: Gaining buy-in for the changes from those involved and affected, directly or indirectly. 3. Involvement: Involving the right people in the design and implementation of changes, to make sure the right changes are made. 4. Impact: Assessing and addressing how the changes will affect people. 5. Communication: Telling everyone who's affected about the changes. 6. Readiness: Getting people ready to adapt to the changes, by ensuring they have the right information, training and help. Who's Responsible?

When you are defining your change management objectives and activities, it's very important to coordinate closely with others: project managers, managers in the business, and the HR department. Ask "who's responsible?" For example, who's responsible for identifying change agents? Defining the re-training plan? Changing job descriptions and employment contracts? And so on. As every change is different, responsibilities will vary depending on how the change activities and project are organized. Only when you know who's responsible and how things are organized in your situation will you know what's within your change management scope, and how you'll be working with other people to bring about the change.

Change Management Activities Once you have considered the change management objectives and scope, you'll also need to consider the specific tasks. Again, the range of possible change management activities is broad. It's a question of working out what will best help you meet the change management challenge in hand, as you have defined it in your objectives and scope, and how to work along side other people's and projects' activities and responsibilities.

The essence of this is to identify the tasks that are necessary if you're going to give change the greatest chance of success. Coming from this, the activities involved in managing change can include: • Ensuring there is clear expression of the reasons for change, and helping the sponsor communicate this. • Identifying "change agents" and other people who need to be involved in specific change activities, such as design, testing, and problem solving, and who can then act as ambassadors for change. • Assessing all the stakeholders and defining the nature of sponsorship, involvement and communication that will be required. • Planning the involvement and project activities of the change sponsor(s). • Planning how and when the changes will be communicated, and organizing and/or delivering the communications messages. • Assessing the impact of the changes on people and the organization's structure. • Planning activities needed to address the impacts of the change. • Ensuring that people involved and affected by the change understand the process change. • Making sure those involved or affected have help and support during times of uncertainty and upheaval. • Assessing training needs driven by the change, and planning when and how this will be implemented. • Identifying and agreeing the success indicators for change, and ensure they are regularly measured and reported on. Remember, these are just some typical change management activities. Others may be required in your specific situation. Equally, some of the above may not be within your remit, so plan carefully, and coordinate with other people involved.

Your Change Management Tool-Kit So where do you start? Here are some tools and techniques from Mind Tools that can help:

Understanding Change The Change Curve – This powerful model describes the stages of personal transition involved in most organizational change. It will help you understand how people will react to the changes, and so you can better plan how to support them through the process. Lewin's Change Management Model – This describes how you generally have to "break up" the current state of things in order to make improvements, using the concept of "unfreeze – change – refreeze". Our article shows the different things you need to do at each stage to support those impacted.

Beckhard and Harris's Change Model – Giving another perspective on change, this describes how change initiatives require the pre-requisites of real dissatisfaction with the current state, a vision of why the new state will be better, and clear first steps towards getting there, to be successful.

Planning Change Impact Analysis – This is a useful technique for uncovering the "unexpected" consequences of change. Burke-Litwin Change Model – This complex model helps you to work through the effects of change between 12 elements of organizational design. McKinsey 7S Framework – Somewhat similar to the Burke-Litwin Model, this well-known tool helps you to understand the relationship between seven "hard" and "soft" aspects of organizations. Leavitt's Diamond – In the same vein as the McKinsey 7S and Burke-Litwin models, this tool allows you to work through the impacts of a proposed change oni the interrelated elements of tasks, people, structure and technology in any organization. Organization Design – Although every organization is unique, there are a several common structures. This article describes these, and discusses the things you need to consider when choosing the best design for your situation. SIPOC Diagrams – A comprehensive tool for checking the impact of a proposed change on your suppliers, inputs, processes, outputs and customers,

Implementing Change Kotter's 8-Step Change Model – The core set of change management activities that need to be done to effect change, and make it stick in the long term. Training Needs Assessment – Change projects almost always need people to learn new skills. A training needs assessment is a structured way of ensuring that the right people are given the right training at the right time. Why Change Can Fail – Change is complex, and knowing what NOT to do is just as important as knowing what TO do!

Communicating Change Stakeholder Analysis – A formal method for identifying, prioritizing and understanding your project's stakeholders. Stakeholder Management – A process for planning your stakeholder communications to ensure that you give the right people the right message at the right time to get the support you need for your project. Mission Statements and Visions Statements – Mission and vision statements are a well-structured way of helping you to communicate what the change is intended to achieve, and to

motivate your stakeholders with an inspiring, shared vision of the future. And to explore various aspects of change management in more depth, take our Bite-Sized Training lesson on Managing Change

.

Key Points Change management is a broad discipline that involves ensuring change is implemented smoothly and with lasting benefits, by considering its wider impact on the organization and people within it. Each change initiative you manage or encounter will have its own unique set of objectives and activities, all of which must be coordinated. As a change manager, your role is to ease the journey towards new ways of working, and you'll need a set of tools to help you along the way: There's a wide range of change management tools here at Mind Tools – this a great place to start!

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... Yolande wrote Hi Philippa Welcome to the forums - it's great to 'hear' your voice. The link for the topic of the crabs is: viewtopic.php?f=2&t=6369 If you'd like to share some more of your ideas and / or challenges, please feel free to do so on one of the forums such as Career Cafe Central - that is where we all help and learn from one another. Everybody brings some knowledge or experience to the 'party' and the collective becomes a huge pool of shared knowledge/ experience. Philippa, please let me know if you need any help around here - I'd only be too glad to help. And I'd love to hear your thoughts on the crabs. Kind regards Yolandé February 5, 2013 philskill wrote Hi Yolande Could you please post the reference for the article you mention "lessons from the wild" as I can't find it, and it sounds like a great resource. Many thanks, Philippa February 5, 2013 Yolande wrote Hi sammymatchett Welcome to the forums...great to 'hear' your voice and I hope we will see you on the forums often from now on. I've used the following exercise with great success. It's simple and doesn't require lots of complicated and expensive props & stuff. (PLEASE NOTE: Before you start the exercise, make it very clear to your delegates that they don't have to share anything they are not comfortable with.) First divide your delegates into pairs or groups of three. Ask each of them to think of three major changes they've had to handle in the workplace and write them down. The others in the pair/group then question the first person on these major changes. They can for example ask them how they handled the chang; how the change made them feel; what they found difficult about the change; did others

react in a way that affected them; how did they help others cope with the change etc. Once each person had a chance to be questioned you can lead a group discussion. Ask the group about their coping mechanisms and strategies. Also ask them what they learnt from their conversation partners about coping with change. What ideas can they put together as a 'gameplan' for coping with change? Add questions of your own to tailor-make the session to the needs of your staff. Also have a look at this "Lesson from the Wild" I wrote earlier this year about the Giant Japanese Spider Crab. The central idea of the moulting crabs provides a nice theme to build around; there are also cool video clips on youtube showing the moulting process. (Search for 'moulting crabs' and you should find them.) viewtopic.php?f=2&t=6369 Let me know what you think. Kind regards Yolandé May 29, 2012 sammymatchett wrote Has anyone an exercise/activity that could be run with a group of managers to make them think about change management in a beneficial way? Thanks May 28, 2012 Helena wrote Hi All I've chosen this article to be our Featured Favorite this week because in the current turbulent times, it's never been more important to to understand what change involves and how to implement it - fast. http://www.mindtools.com/community/page ... PPM_87.php What has your epxerience of going through change at work been like? Share your "how to"s AND your "how not to"s by replying ot this post! Best wishes Helena August 4, 2009 Fidget wrote

You know, when you read this article, it stops sounding like a holy grail that only very expensive "change management consultants" can do, and something we can all work at getting to grips with... especially for the small impovements and changes that we try to implement week in week out to make things better. Fiona May 21, 2007

Return to top of the page

Changing People's Habits Encouraging and Sustaining New Behaviors You've just come back from a course about managing meetings, full of enthusiasm for changing the way that you work. You're going to turn up to meetings on time, every time. And when you're in the chair, you'll start promptly, even if everyone else isn't there yet. However, after a couple of weeks, it's clear that this isn't really working.

How can you get a leopard to change its spots? © iStockphoto/WinterWitch

Other meetings overrun, and whilst you endeavor to get to yours on time, your colleagues don't seem to be making any effort. With key people missing, you can't make any progress, and you find yourself wasting time just hanging around. Frustrated, you gradually return to your old way of doing things. This is a very common story. Even when you're enthusiastic about changing your own habits and behaviors, it is not always easy to do so. And encouraging others to change their habits can be even harder! How people behave at work is not just down to their personality and particular skills. There are numerous contributory factors, including organizational structure and processes, and the overall business culture.

Creating sustainable behavior change In many cases, if you want to create sustainable behavior change, it's not enough just to run a series of training workshops. Chances are that you'll need to change the way your business operates, as well. If you work through the two stages below, your program will be much more likely to succeed.

Stage 1: Ensure that the case for change is compelling You're unlikely to succeed in the tricky business of changing people's habits if the people you're asking to change don't think it is worthwhile. As such, the first thing you need to do is make sure that your arguments for change are compelling. Above all, you need to have a robust business case . This should go beyond simply detailing how the expected benefits will exceed the time and money that it will take. It must also show that there's enough spare "organizational focus" available right now to make it work. There's a limit to the number of "new" things that any organization can concentrate on at one time, and taking too much on

will inevitably have a negative impact on the delivery of some of your company's initiatives. You must think through the impact that the desired new behavior will have on: • Costs. • Revenue. • The quality of the product, service, or customer experience. • The productivity of staff, machines, or other assets. • The time taken to complete processes. • The amount or extent of reworking or restructuring required. • Customer satisfaction levels. • The speed, effectiveness and quality of decision-making. Being able to demonstrate likely benefits in these areas will help you to overcome resistance to your plans from those who need to change. Now, build all of this information into a stakeholder communication plan . Tip:

Even if you don't have a compelling case for change, it may still be worth trying. Look for ways that you can tackle the issue that don't demand a dedicated project, with all of the cost, visibility and drama associated with this. For example, you may want to adopt a new behavior with your team. By showcasing it, others may then adopt it too.

Stage 2: Create the environment for behavior change Next, you must develop an understanding of what will drive and reinforce the behavior you want to encourage. The questions given below will help you to start thinking about this, but there may be other areas specific to your organization that you should investigate as well. Record your answers on a fishbone diagram

.

Personnel

• How will the organizational structure support or encourage your new behaviors? • What support will people require to develop the skills, understanding and knowledge needed to behave in the "new way"? • What will be the most effective way for this support to be delivered? For example, should you deliver this through training courses, workshops, or peer/boss mentoring?

Key senior people

• How do the values of senior managers get reflected in the way that the organization works? Will this reinforce or work against the new behaviors you want? • How do these people reward positive behaviors and discourage unwanted ones in their teams? • Are there any existing people who are positive role models, that you could get other people to follow? • Could these senior people support you and become effective advocates, agents or sponsors of change? (See our article on change management for an understanding of these essential implementation roles.) History

• How has the business evolved? Have some behaviors originated from a previous strategy or from a priority of the organization that may now have been abandoned? If so, how can you demonstrate to people that things have moved on? Processes and systems

• How will existing processes and systems support the new behavior? Location

• What impact does remote working, office layout and location have? Are there any challenges that arise from the organization's locational structure which need to be taken into account in designing your implementation approach? Technology

• Which technologies do people have access to in the organization? What technological barriers and opportunities are there? Measures and controls

• What types of measures are important within the organization, and what kind of controls are in place? How will these support or hinder the way that you want people to behave? Customers, suppliers and other external stakeholders

• Do the needs of stakeholders outside your organization have a significant influence on behaviors? Reward

• How are individuals and teams recognized and rewarded? To what extent does this vary across the business? And what impact will this have on your change? • How important is behavior in considering an individual's overall performance? • In what circumstances is poor behavior overlooked? • To what extent could existing HR tools within the organization support or hinder the implementation of the new behavior?

(These could include performance management processes, competency frameworks, and job sizing or grading systems.) Organizational culture

• What is important to the organization as a whole? • What "cultural paradigm" does the organization operate within? (See our article on Johnson and Scholes' Cultural Web .) When you're thinking about changing people's behaviors, think about as many of these questions as possible. Tip:

Many existing habits and behaviors are subconscious. People have got so used to doing something in a particular way, that they do it without thinking. Even if you're aware of these things, you might well have no idea how they became habits in the first place. New staff may remark on them, but, before long, chances are they'll be behaving in just the same way! To change these die-hard habits, you need to make your staff aware of them. Show people why they're no longer appropriate. Then reinforce the new behaviors you want within the organization, until they themselves become habits.

Ensuring success When it comes to improving the chances of successfully changing people's behaviors, there are a number of things that are well worth doing: • Limit the number of areas that your program needs to address. Your fishbone diagram may indicate a complex set of things that need to happen in order to achieve the desired new behavior. If this is the case, look again at your initial plan, and include only the actions that are really critical to making a difference. You'll have a much better chance of succeeding if you can focus on a few key things that need to change. • Recreate your fishbone diagram in a workshop with key change advocates and change agents. This will not only make your preparation more robust, but it will also engage these people early in the program, and strengthen their sense of ownership of the plan. • Consider what consequences individuals will experience if their behavior doesn't change. If the new behavior is not reinforced through systems or processes, or if it's not integrated into how performance is measured, it's going to be more difficult to implement successfully. If appropriate, consider monitoring people's progress within your performance management system. • Ensure that individuals see the change as compelling. It's not enough for you to see that something needs to be done – others must too. Remember, existing behaviors and habits are likely to be deeply rooted, and are often taken for granted. • Respected role models are critical for success. When you introduce a new IT-based system, for example, it‘ll be obvious

whether it's working well for your business or not, however changing behavior is less clear cut. People need to see what good behaviors look like in practice. Tip:

For more general guidance on how to implement change successfully, and in particular for large-scale or complex change processes, read our articles on Implementing Change and Kotter's Change Model . And for structured approaches for thinking about the impacts these may have, see our articles on the McKinsey 7 Ss and the Burke-Litwin Change Model .

Key Points Peoples' habits and behaviors are influenced by a complicated set of factors. Some are driven by the individual's capabilities and experience, and others by elements within the organization where they work. By using the approach in this article, you'll be able to determine the key issues that you need to take into account when implementing a behavioral change program within your organization.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... bigk wrote Hi I see change as a requirement. I see change as a tool or method. These are both used to improve. Communicating change needs to take note of existing practices and new practices and combine them unless it is a complete change in system or process. The correct change? Maybe there is no correct change. It might depend on the variables in the change and the variables for how the change is to progress. Providing flexibility in change and any new method allows people to take hold of the change and use it so they can contribute, but this often is at implementation of change and monitoring it's progress. I see no reason why change can not be changed if it is not working. Identifying an item or action for change needs a broader view so the change also assesses the impact it has before and after a required change. I don't have any other immediate suggestions to offer. The article items lists many variables, I understand the items listed as items to assess in the change. Bigk October 21, 2009 yann wrote While I agree on the need to articulate the case for change and create some sense of urgency around it, I also remind myself systematically that people do what they do because they perceive a benefit in doing it. The case for change focuses on correcting what does not work, but if we do not explicitly address what I call the conservation of benefits (ie what works) we inadvertently create barriers to change. In the Theory of Scientific Revolutions, TS Kuhn demonstrates how Einstein's theory not only resolves the anomalies that Newton's mechanics met at its limits, but also confirms the results of Newton's mechanics in the domain where it is fit for purpose. The article highlights that habits are often unconscious, and certainly the perceived benefits often are. After the case for change has been communicated, a useful tool is to get people to

work on what are the benefit that we need to find a way - possibly a new way - to keep. In the subsequent discussion, people start to make the distinction between the habit (that may indeed have to change) and its benefit (that may be kept in a different manner). In some case, they even realise that the benefit was only a perception. This process helps a lot removing the unconscious barriers to change. Yann October 21, 2009

Return to top of the page

Conducting a Project Healthcheck Finding Out How a Project is Progressing Projects don't always go as planned. Perhaps one is struggling to deliver the benefits specified, or a deadline has been missed for a key project phase, or costs are escalating and threatening the project's business case. Sometimes you can address these challenges as part of everyday activity within the project – but sometimes you can't.

Understand how your project is progressing. © iStockphoto/alexsl

For example, imagine that you're managing a project to introduce a new IT system. You've completed the design phase, and had your design approved. However, during the development and testing phase, you realize that key people think you're supposed to be doing something different. You've discussed this with some important business stakeholders, and the situation is complicated. How do you resolve it? Conducting a project healthcheck gives you a complete picture of the project's progress, and helps you confirm how different stakeholders view its success. You can then agree how to proceed.

When You Need a Project Healthcheck Healthchecks take time and cost money, so be sure they're needed. In general, they're worth running when you want to do the following: • Develop action plans to resolve significant and complex concerns that can't be managed as part of the everyday project activity. • Renew the organization's enthusiasm and commitment to a highprofile project. • Get stakeholders to recommit to their obligations and responsibilities, and re-energize the team. • Educate a new project manager, and identify any changes that the project manager must make. (This is particularly helpful in a medium- or large-scale project.) • Get a project back under control. • Make sure that the team is using the appropriate project management processes and systems.

How to Conduct a Project Healthcheck In the steps below, we look at how you can scope, plan, and conduct a project healthcheck.

Step 1: Determine the healthcheck's objectives The reason for conducting your healthcheck gives you the starting point for thinking about objectives. You can then refine this by asking further questions: • What project phases and processes • Should the governance • Do your stakeholders ones?

must be covered?

process be included in the scope? need to be involved? If yes, which

• Do you simply want to assess project status, or do you also want to include recommendations for improvement? • How will you deliver your healthcheck? As a report? As a presentation to the steering group? Or in some other way? • Who will make decisions on your recommendations? And what is the deadline for presenting them? You may be able to write your objectives by yourself, or you may need to have discussions with stakeholders and team members. It's important to get this right, as your objectives affect the way in which you'll conduct the rest of the healthcheck process. As well as getting agreement from the project sponsor on the healthcheck objectives and output, you may also need to agree a budget for using internal team members' time, or for appointing an external group to conduct the healthcheck.

Step 2: Decide who will do the healthcheck Healthchecks can be led by the project manager, by another project manager within the organization, by an external or internal consultant, or by an internal auditor. Choosing the right person depends on two things: • Why is the healthcheck needed? • What is the healthcheck's focus? You must determine who has the appropriate understanding of the project, authority, experience, and mindset to conduct the review properly. Let's look at each of these individually: • Authority – An internal auditor is often selected when the healthcheck is part of a routine project audit. This person checks that all of the correct processes and procedures are being followed. • Experience – If there are concerns about the expertise of the project manager, then the project manager shouldn't conduct the review. Using someone else with more project management expertise might lead to greater insight into how the project could be improved. An external consultant is sometimes used under these circumstances. • Project understanding – If the healthcheck is needed to resolve complex project issues, but the project manager's

capability is not being questioned, then it's often best to have the project manager conduct the review. • Mindset – The healthcheck usually results in changes to the way the project is being delivered. The person conducting the review must, therefore, have an open mind, and be able to make recommendations without being locked into the way that the project has run to date. Whether the healthcheck is conducted by an individual or by a team depends on what needs to done, and on the time frame. However, remember that within a team, people can offer one another ideas, and use a greater range of skills than a single individual. This is particularly helpful when issues are complex.

Step 3: Identify how you will proceed Once you've decided who will complete the healthcheck, the next stage is to think about how you'll get the information you need. The following approaches may be useful: • Project deliverable reviews – By reviewing the project's deliverables to date, you'll pick up crucial background information that will help you understand the context of the project. Healthchecks may review, for example, strategy documents, business requirements documents, the project team charter, business case documents and project control documents. And, by studying the project end-products completed so far, you'll be able to assess the quality of work being done by the project team. • Interviews – Team member and stakeholder interviews are very common within project healthchecks. The challenge is to decide whom to include in (and exclude from) your interview list. Interviews are particularly helpful for gaining further insight into project deliverables. For example, a project plan can be complex, so having someone explain its elements may help you find omissions or issues. Interviews are also useful if you want further information on things for which certain individuals are responsible, or if you want specific individuals' perspectives on the project. • Questionnaires – In a medium-sized or large project, you may want project team members and stakeholders to fill in a questionnaire. This is usually considered only when you want information from a large number of people. If using a questionnaire, you may want to follow it up with interviews with a sample of the respondents to gain further qualitative information, and to discuss any ideas that you've developed. • Workshops – Workshops are useful when you want a general overview of a situation. Participants have the opportunity to give each other ideas, and find solutions together.

Step 4: Form your plan Once you've thought about how you'll go ahead, you can create your schedule of activities. This should be relatively simple once you've determined what you need to accomplish.

Healthchecks are best done quickly, lasting from a few days up to a couple of weeks (for larger projects). By keeping them short, you minimize the disruption for the project team and ensure that any recommendations are implemented quickly.

Step 5: Conduct your healthcheck During the healthcheck, your objectives and plan will drive your activity. Mind Tools has many resources available to help you. In particular, look at the tools within the problem solving , creativity , and project management sections of the site.

Step 6: Present your findings and agree on next steps Once you've conducted your healthcheck, put your views and recommendations into the format that you've agreed on with your project sponsor. This might be a written report or a presentation. Even if you've agreed to a simple discussion rather than a formal presentation, make sure you write down all of the key points. As you prepare your findings, you may find it helpful to look at the Healthcheck Deliverable Checklist to make sure you've covered everything. You'll probably then need to discuss your findings and recommendations with your project sponsor (and any other governance groups) before those recommendations can be approved and implemented.

Key Points Project healthchecks give you a summarized overview of a project and its progress to date, and help you make recommendations on how to take it forward. This can give fresh life to a stalling project, renew the enthusiasm of stakeholders, increase confidence that the project will succeed, and, perhaps, help negotiate a more realistic delivery date or budget. However, doing a healthcheck takes time and money, and it can distract the project team from delivering the day-to-day activities. That's why it's important to ensure that the potential benefits outweigh the costs.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Hi wendy_marn, That's definitely a tall order to fill. Complex projects do require leadership. If there truly is no one willing to take on the official role I'm wondering if using the RACI Matrix might help keep things organized and on track. Here is the link: http://www.mindtools.com/community/page ... PPM_97.php Essentially it's a tool where the team gets together and decides who is Responsible, Accountable, Consulted, and Informed. Using a tool like this will help you get things underway and you might even be able to share the typical leadership responsibilities this way. I do think it's important that a project leader is recruited and developed though. Does anyone have an inclination or interest in it? If not, then at the next recruitment opportunity that might be one of the competencies you put high on the list. Hope this helps a bit. Any other suggestions from experienced project managers? Dianna April 27, 2010 wendy_marn wrote We may need to update this article to address what to do when there is no program manager... there are times when an organization fails at a project or is significantly derailed because of people resouces. There may be a champion or sponsor business unit that doesn't have the resources or the experience to drive a complex project forward. So how do you identify and onboard a group or stakeholder to sign up to become the project manager of

a medium to large scale project? They may have never done project management themselves or may not be inclined to take on additional roles. What resources are available to a group that is hesistant to manage the project themselves and on top of it, can't afford to hire a consultant.? April 27, 2010 JosieB wrote I like this tool but think it is very much a "cost benefit" situation. Maybe paring it down might be a good way to stay in check and not expend too much energy "checking" as opposed to "doing". I think too if you are doing casual audits on a regular basis then you might be able to avoid a full-blown health check. Having said that we all know that stuff happens to derail even the best planned project so it's good to have a framework to use when you need to get back on track. Thanks for sharing it with us! April 15, 2010

Return to top of the page

Critical Path Analysis and PERT Charts Planning and Scheduling More Complex Projects Related variants: AOA or Activity-on-Arc Diagrams Critical Path Analysis and PERT are powerful tools that help you to schedule and manage complex projects. They were developed in the 1950s to control large defense projects, and have been used routinely since then. As with Gantt Charts , Critical Path Analysis (CPA) or Multiple activities often feed into other activities. the Critical Path Method (CPM) © iStockphoto/Cybernesco helps you to plan all tasks that must be completed as part of a project. They act as the basis both for preparation of a schedule, and of resource planning. During management of a project, they allow you to monitor achievement of project goals. They help you to see where remedial action needs to be taken to get a project back on course. Within a project it is likely that you will display your final project plan as a Gantt Chart (using Microsoft Project or other software for projects of medium complexity or an excel spreadsheet for projects of low complexity).The benefit of using CPA within the planning process is to help you develop and test your plan to ensure that it is robust. Critical Path Analysis formally identifies tasks which must be completed on time for the whole project to be completed on time. It also identifies which tasks can be delayed if resource needs to be reallocated to catch up on missed or overrunning tasks. The disadvantage of CPA, if you use it as the technique by which your project plans are communicated and managed against, is that the relation of tasks to time is not as immediately obvious as with Gantt Charts. This can make them more difficult to understand. A further benefit of Critical Path Analysis is that it helps you to identify the minimum length of time needed to complete a project. Where you need to run an accelerated project, it helps you to identify which project steps you should accelerate to complete the project within the available time.

How to Use the Tool As with Gantt Charts, the essential concept behind Critical Path Analysis is that you cannot start some activities until others are finished. These activities need to be completed in a sequence, with each stage being more-or-less completed before the next stage can begin. These are 'sequential' activities.

Other activities are not dependent on completion of any other tasks. You can do these at any time before or after a particular stage is reached. These are non-dependent or 'parallel' tasks.

Drawing a Critical Path Analysis Chart Use the following steps to draw a CPA Chart:

Step 1. List all activities in the plan For each activity, show the earliest start date, estimated length of time it will take, and whether it is parallel or sequential. If tasks are sequential, show which stage they depend on. For the project example used here, you will end up with the same task list as explained in the article on Gantt Charts (we will use the same example as with Gantt Charts to compare the two techniques). The chart is repeated in Figure 1 below: Figure 1. Task List: Planning a custom-written computer project

Task

Earliest start

Length

Type

Dependent on...

A. High level analysis

Week 0

1 week

Sequential

B. Selection of hardware platform

Week 1

1 day

Sequential

A

C. Installation and commissioning of hardware

Week 1.2

2 weeks

Parallel

B

D. Detailed analysis of core modules

Week 1

2 weeks

Sequential

A

E. Detailed analysis of supporting modules

Week 3

2 weeks

Sequential

D

F. Programming of core modules

Week 3

2 weeks

Sequential

D

G. Programming

Week 5

3 weeks

Sequential

E

Task

Earliest start

Length

Type

Dependent on...

H. Quality assurance of core modules

Week 5

1 week

Sequential

F

I. Quality assurance of supporting modules

Week 8

1 week

Sequential

G

J.Core module training

Week 6

1 day

Parallel

C,H

K. Development and QA of accounting reporting

Week 5

1 week

Parallel

E

L. Development and QA of management reporting

Week 5

1 week

Parallel

E

M. Development of Management Information System

Week 6

1 week

Sequential

L

N. Detailed training

Week 9

1 week

Sequential

I, J, K, M

of supporting modules

Step 2. Plot the activities as a circle and arrow diagram Critical Path Analyses are presented using circle and arrow diagrams. In these, circles show events within the project, such as the start and finish of tasks. The number shown in the left hand half of the circle allows you to identify each one easily. Circles are sometimes known as nodes. An arrow running between two event circles shows the activity needed to complete that task. A description of the task is written underneath the arrow. The length of the task is shown above it. By

convention, all arrows run left to right. Arrows are also sometimes called arcs. An example of a very simple diagram is shown below:

This shows the start event (circle 1), and the completion of the 'High Level Analysis' task (circle 2). The arrow between them shows the activity of carrying out the High Level Analysis. This activity should take 1 week. Where one activity cannot start until another has been completed, we start the arrow for the dependent activity at the completion event circle of the previous activity. An example of this is shown below:

Here the activities of 'Select Hardware' and 'Core Module Analysis' cannot be started until 'High Level Analysis' has been completed. This diagram also brings out a number of other important points: • Within Critical Path Analysis, we refer to activities by the numbers in the circles at each end. For example, the task 'Core Module Analysis' would be called activity 2 to 3. 'Select Hardware' would be activity 2 to 9. • Activities are not drawn to scale. In the diagram above, activities are 1 week long, 2 weeks long, and 1 day long. Arrows in this case are all the same length. • In the example above, you can see a second number in the top, right hand quadrant of each circle. This shows the earliest start time for the following activity. It is conventional to start at 0. Here units are whole weeks. A different case is shown below:

Here activity 6 to 7 cannot start until the other four activities (11 to 6, 5 to 6, 4 to 6, and 8 to 6) have been completed. Click the link below for the full circle and arrow diagram for the computer project we are using as an example. Figure 5: Full Critical Path Diagram This shows all the activities that will take place as part of the project. Notice that each event circle also has a figure in the bottom, right hand quadrant. This shows the latest finish time that's permissible for the preceeding activity if the project is to be completed in the minimum time possible. You can calculate this by starting at the last event and working backwards.The latest finish time of the preceeding event and the earliest start time of the following even will be the same for ciircles on the critical path. You can see that event M can start any time between weeks 6 and 8. The timing of this event is not critical. Events 1 to 2, 2 to 3, 3 to 4, 4 to 5, 5 to 6 and 6 to 7 must be started and completed on time if the project is to be completed in 10 weeks. This is the 'critical path' – these activities must be very closely managed to ensure that activities are completed on time. If jobs on the critical path slip, immediate action should be taken to get the project back on schedule. Otherwise completion of the whole project will slip.

'Crash Action' You may find that you need to complete a project earlier than your Critical Path Analysis says is possible. In this case you need to re-plan your project. You have a number of options and would need to assess the impact of each on the project’s cost, quality and time required to complete it. For example, you could increase resource available for each project activity to bring down time spent on each but the impact of some of

this would be insignificant and a more efficient way of doing this would be to look only at activities on the critical path. As an example, it may be necessary to complete the computer project in Figure 5 in 8 weeks rather than 10 weeks. In this case you could look at using two analysts in activities 2 to 3 and 3 to 4. This would shorten the project by two weeks, but may raise the project cost – doubling resources at any stage may only improve productivity by, say, 50% as additional time may need to be spent getting the team members up to speed on what is required, coordinating tasks split between them, integrating their contributions etc. In some situations, shortening the original critical path of a project can lead to a different series of activities becoming the critical path. For example, if activity 4 to 5 were reduced to 1 week, activities 4 to 8 and 8 to 6 would come onto the critical path. As with Gantt Charts, in practice project managers use software tools like Microsoft Project to create CPA Charts. Not only do these ease make them easier to draw, they also make modification of plans easier and provide facilities for monitoring progress against plans.

PERT (Program Evaluation and Review Technique) PERT is a variation on Critical Path Analysis that takes a slightly more skeptical view of time estimates made for each project stage. To use it, estimate the shortest possible time each activity will take, the most likely length of time, and the longest time that might be taken if the activity takes longer than expected. Use the formula below to calculate the time to use for each project stage: shortest time + 4 x likely time + longest time ---------------------------------------------------------6 This helps to bias time estimates away from the unrealistically short time-scales normally assumed.

Key Points Critical Path Analysis is an effective and powerful method of assessing: • What tasks must be carried out. • Where parallel activity can be performed. • The shortest time in which you can complete a project. • Resources needed to execute a project. • The sequence of activities, scheduling and timings involved. • Task priorities. • The most efficient way of shortening time on urgent projects.

An effective Critical Path Analysis can make the difference between success and failure on complex projects. It can be very useful for assessing the importance of problems faced during the implementation of the plan. PERT is a variant of Critical Path Analysis that takes a more skeptical view of the time needed to complete each project stage.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... bigk wrote Another potential option that could be considered with the analysis about increased competitors or price issues is looking at the blue ocean strategy. There are many parts of blue ocean strategy useful to consider when using "what if" analysis combined with sensitivity analysis or risk assessment and overall analysis that "what if" requires. As Yolande mentioned it is important to get understanding about what and how to decide from the options or analysis you get. Perhaps recheck the decision after deciding if you feel the decision was made too early rather than taking extra time assessing all the options. However the balance it requires is what

is important about this. Using a mentor or another view (opinion) is a good option and could give very useful information if there are limited options when checking the strength or effectiveness of the decisions required. The decision needs the information prioritized and assessed for impact to the overall objective. Bigk October 16, 2010 Yolande wrote I love the 'what if' approach and I think it is essential to do in order to raise awareness of possible risks before making decisions. However, the secret is to know when and where to stop so that all the 'what if's' don't paralyse you into never making a decision. Sometimes I take 'what if' a step further by going to a mentor or someone with more experience than I have in a specific field, asking them "WHAT would you have done IF xyz happened to your business?" The idea is not necessarily to follow their ideas to the letter, but rather to gain sound, good quality information before making a decision. Kind regards Yolandé October 14, 2010

Return to top of the page

Estimating Time Accurately Calculating Realistic Project Timelines Have you ever been on a project where the deadline was way too tight? Chances are that tempers were frayed, sponsors were unhappy, and team members were working ridiculous hours. Chances are, too, that this happened because someone underestimated the amount of work needed to complete the project.

Be realistic. © iStockphoto/MorePixels

People often underestimate the amount of time needed to implement projects, particularly when they're not familiar with the work that needs to be done. For instance, they may not take into account unexpected events or urgent high priority work; and they may fail to allow for the full complexity of the job. Clearly, this is likely to have serious negative consequences further down the line. This is why it's important to estimate time accurately, if your project is to be successful. In this article, we look at a process for making good time estimates, and we explore some of the estimating methods that you can use.

Why Estimate Time Accurately? Accurate time estimation is a crucial skill in project management. Without it, you won't know how long your project will take, and you won't be able to get commitment from the people who need to sign it off. Even more importantly for your career, sponsors often judge whether a project has succeeded or failed depending on whether it has been delivered on time and on budget. To have a chance of being successful as a project manager, you need to be able to negotiate sensible budgets and achievable deadlines.

How to Estimate Time Accurately Use these steps to make accurate time estimates:

Step 1: Understand What's Required Start by identifying all of the work that needs to be done within the project. Use tools such as Business Requirements Analysis , Work Breakdown Structures , Gap Analysis and Drill-Down to help you do this in sufficient detail.

As part of this, make sure that you allow time for meetings, reporting, communications, testing and other activities that are critical to the project's success. (You can find out more on these activities in our article on Project Management Phases and Processes .)

Step 2: Order These Activities Now, list all of the activities you identified in the order in which they need to happen. At this stage, you don't need to add in how long you think activities are going to take. However, you might want to note any important deadlines. For example, you might need to get work by the finance department finished before it starts work on "Year End."

Step 3: Decide Who You Need to Involve You can do the estimates yourself, brainstorm ask others to contribute.

them as a group, or

Where you can, get the help of the people who will actually do the work, as they are likely to have prior experience to draw upon. By involving them, they'll also take on greater ownership of the time estimates they come up with, and they'll work harder to meet them. Tip:

If you involve others, this is a good time to confirm your assumptions with them.

Step 4: Make Your Estimates You're now ready to make your estimates. We've outlined a variety of methods below to help you do this. Whichever methods you choose, bear these basic rules in mind: • To begin with, estimate the time needed for each task rather than for the project as a whole. • The level of detail you need to go into depends on the circumstances. For example, you may only need a rough outline of time estimates for future project phases, but you'll probably need detailed estimates for the phase ahead. • List all of the assumptions, exclusions and constraints that are relevant; and note any data sources that you rely on. This will help you when your estimates are questioned, and will also help you identify any risk areas if circumstances change. • Assume that your resources will only be productive for 80 percent of the time. Build in time for unexpected events such as sickness, supply problems, equipment failure, accidents and emergencies, problem solving, and meetings. • If some people are only working "part-time" on your project, bear in mind that they may lose time as they switch between their various roles.

• Remember that people are often overly optimistic, and may significantly underestimate the amount of time that it will take for them to complete tasks. Tip:

The most reliable estimates are those that you have arranged to be challenged. This helps you identify any assumptions and biases that aren't valid. You can ask team members, other managers, or co-workers to challenge your time estimates.

Methods for Estimating Time We'll now look at different approaches that you can use to estimate time. You'll probably find it most useful to use a mixture of these techniques. • Bottom-Up Estimating Bottom-up estimating allows you to create an estimate for the project as a whole. To analyze from the "bottom up," break larger tasks down into detailed tasks, and then estimate the time needed to complete each one. Because you're considering each task incrementally, your estimate of the time required for each task is likely to be more accurate. You can then add up the total amount of time needed to complete the plan. Tip 1:

How much detail you go into depends on the situation. However, the more detail you go into, the more accurate you'll be. If you don't know how far to go, consider breaking work down into chunks that one person can complete in half a day, for example. Sure, this is a bit circular, but it gives you an idea of the level of detail you should aim for. Tip 2:

Yes, this does take a lot of work, however, this work will pay off later in the project. Just make sure that you leave plenty of time for it in the project's Design Phase. • Top-Down Estimating In top-down analysis, you develop an overview of the expected timeline first, using past projects or previous experience as a guide. It's often helpful to compare top-down estimates against your bottom-up estimates, to ensure accuracy.

Note:

Don't assume that the bottom-up estimates are wrong if they differ widely from the top-down ones. In fact, it's more likely that the reverse is true. Instead, use the top-down estimates to challenge the validity of the bottom-up estimates, and to refine them as appropriate. • Comparative Estimating With comparative estimating, you look at the time it took to do similar tasks, on other projects. • Parametric Estimating With this method, you estimate the time required for one deliverable; and then multiply it by the number of deliverables required. For example, if you need to create pages for a website, you'd estimate how much time it would take to do one page, and you'd then multiply this time by the total number of pages to be produced. • Three-Point Estimating To build in a cushion for uncertainty, you can do three estimates – one for the best case, another for the worst case, and a final one for the most likely case. Although this approach requires additional effort to create three separate estimates, it allows you to set more reasonable expectations, based on a more realistic estimate of outcomes. Tip:

In the early stages of project planning, you often won't know who will do each task – this can influence how long the task will take. For example, an experienced programmer should be able to develop a software module much more quickly than someone less experienced. You can build this into your estimates by giving best, worst, and most likely estimates, stating the basis for each view.

Preparing Your Schedule Once you've estimated the time needed for each task, you can prepare your project schedule . Add your estimates to the draft activity list that you produced in the second step, above. You can then create a Gantt Chart to schedule activities and assign resources to your project; and to finalize milestones and deadlines.

Tip:

If your project is complex, you might find that identifying the critical path on your plan is helpful. This will help you highlight the tasks that cannot be delayed if you're going to hit your deadline.

Key Points You need to estimate time accurately if you're going to deliver your project on time and on budget. Without this skill, you won't know how long your project will take, and you won't be able to get commitment from the people required to help you achieve your objective. More than this, you risk agreeing to impossibly short deadlines, with all of the stress, pain, and loss of credibility associated with this. To estimate time effectively, follow this four-step process: 1. Understand what's required. 2. Prioritize activities and tasks. 3. Decide who you need to involve. 4. Do your estimates. Use a variety of estimating methods to get the most accurate time estimates.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote Hi Jack, Thanks for the reminder about doubling the estimate of time to complete certain tasks. I'm currently feeling quite heavy with all the things to do and I often underestimate the time allowed! I know, I know ... I should know better as the end result is that I start feeling overwhelmed by the sheer number of tasks that I want done by the end of the day or week. Yet, if I simply decided to allocate sufficient time, doubling the estimate of how long it may take, then I may be able to breath a sigh of relief. Some tasks can indeed wait!! Does anyone else experience this sense of 'overwhelm' of all the things on their list of things to do and how do you manage it? Midgie November 28, 2013 Dianna wrote I tend to agree Jack!! Particularly when my husband says he'll take on a little project around the house... it'll only take 1/2 an hour he says... in that case I double it and add 10! Best! Dianna November 28, 2013 jack hobbs wrote Hi, I find that the rule of two sometimes works, depending on the project: whatever time you think it's going to take- double it! Jack November 27, 2013 James wrote Hi Everyone We’ve given this popular article a review, and the updated version is now at: http://www.mindtools.com/community/pages/article/ newPPM_01.php

Discuss the article by replying to this post! Thanks James December 2, 2011 Yolande wrote A number of years I worked on a big project in a neighbouring country and one of the things that we said to ourselves over and over again was much like this sentence in the article: Finally, allow time for all the expected and unexpected disruptions and delays to work that will inevitably happen. Allow generously, for those unexpected interruptions, especially if you find yourself in unfamiliar territory where many things have a different time frame than what you're used to. For instance, we were used to ordering office equipment and receiving it within a day or two; in the neighbouring country such things took up to two weeks!! You can imagine how that threw our project 'off balance' ... Kind regards Yolandé May 18, 2010

Return to top of the page

Gantt Charts Planning and Scheduling Team Projects The following are trademarks: Gantto (see gantto.com), MatchWare (see www.matchware.com/en), Microsoft Excel, and Microsoft Project (see www.microsoft.com). We have no association or connection with these organizations. Think about how challenging it would be to juggle a dozen balls at once. You'd have to keep your eye on all of them, and know when to catch each one. If you missed just one, this could spoil your whole performance.

Flash

Learn how to use Gantt Charts effectively, with Project management is James Manktelow & Amy Carlson. similar to this. To complete a project successfully, you must control a large number of activities, and ensure that they're completed on schedule.

If you miss a deadline or finish a task out of sequence, there could be knock-on effects on the rest of the project. It could deliver late as a result, and cost a lot more. That's why it's helpful to be able to see everything that needs to be done, and know, at a glance, when each activity needs to be completed. Gantt charts convey this information visually. They outline all of the tasks involved in a project, and their order, shown against a timescale. This gives you an instant overview of a project, its associated tasks, and when these need to be finished. In this article, we'll look at why Gantt charts are so useful, and we'll see how you can use them to organize projects and keep your team informed of progress.

Origins of the Tool In the late 1800s, Polish engineer Karol Adamiecki developed a visual work flow chart that he called a "harmonogram." In around 1910, Henry Gantt, a management consultant and engineer, took Adamiecki's concept to the next stage. His chart was designed to help manufacturing supervisors see whether their work was on, ahead of, or behind schedule, and it formed the foundation of the tool we use today.

Why Use Gantt Charts? When you set up a Gantt chart, you need to think through all of the tasks involved in your project. As part of this process, you'll work out who will be responsible for each task, how long each task will take, and what problems your team may encounter. This detailed thinking helps you ensure that the schedule is workable, that the right people are assigned to each task, and that you have workarounds for potential problems before you start. Gantt charts also help you work out practical aspects of a project, such as the minimum time it will take to deliver, and which tasks need to be completed before others can start. Plus, you can use them to identify the critical path – the sequence of tasks that must individually be completed on time if the whole project is to deliver on time. Finally, you can use Gantt charts to keep your team and your sponsors informed of progress. Simply update the chart to show schedule changes and their implications, or use it to communicate that key tasks have been completed.

Creating a Gantt Chart You can see an example Gantt chart in figure 1, below: Figure 1 – A Gantt chart

(Click here to expand this diagram.) To create one for your project, follow these steps, using our example as a guide.

Step 1: Identify Essential Tasks Gantt charts don't give useful information unless they include all of the activities needed for a project or project phase to be completed. So, to start, list all of these activities. Use a work breakdown structure if you need to establish what the tasks are. Then, for each task, note its earliest start date and its estimated duration

.

Example

Your organization has won a tender to create a new "Software as a Service" product, and you're in charge of the project. You decide to use a Gantt chart to organize all of the necessary tasks, and to calculate the likely overall timescale for delivery. You start by listing all of the activities that have to take place, and you estimate how long each task should take to complete. Your list looks as follows: Task

Length

A. High level analysis

1 week

B. Selection of server hosting

1 day

C. Configuration of server

2 weeks

D. Detailed analysis of core modules

2 weeks

E. Detailed analysis of supporting modules

2 weeks

F. Development of core modules

3 weeks

G. Development of supporting modules

3 weeks

H. Quality assurance of core modules

1 week

I. Quality assurance of supporting modules

1 week

J. Initial client internal training

1 day

K. Development and QA of accounting reporting

1 week

L. Development and QA of management reporting

1 week

M. Development of management information system

1 week

N. Client internal user training

1 week

Step 2: Identify Task Relationships Gantt charts show the relationship between the tasks in a project. Some tasks will need to be completed before you can start the next one, and others can't end until preceding ones have ended. For example, if you're creating a brochure, you need to finish the design before you can send it to print. These dependent activities are called "sequential" or "linear" tasks. Other tasks will be "parallel" – i.e. they can be done at the same time as other tasks. You don't have to do these in sequence, but you may sometimes need other tasks to be finished first. So, for example, the design of your brochure could begin before the text has been edited (although you won't be able to finalize the design until the text is perfect.) Identify which of your project's tasks are parallel, and which are sequential. Where tasks are dependent on others, note down the relationship between them. This will give you a deeper understanding of how to organize your project, and it will help when you start scheduling activities on the Gantt chart. Note:

In Gantt charts, there are three main relationships between sequential tasks: • Finish to Start (FS) – FS tasks can't start before a previous (and related) task is finished. However, they can start later. • Start to Start (SS) – SS tasks can't start until a preceding task starts. However, they can start later. • Finish to Finish (FF) – FF tasks can't end before a preceding task ends. However, they can end later. A fourth type, Start to Finish (SF), is very rare.

Tip 1:

Tasks can be sequential and parallel at the same time – for example, two tasks (B and D) may be dependent on another one (A), and may be completed at the same time. Task B is sequential in that it follows on from A, and it is parallel, with respect to D. Tip 2:

To minimize delivery times, you'll need to do as much work in parallel as you sensibly can. You also need to keep the scope the project as small as possible.

of

Example

Task

Length

Type*

Dependent on...

A. High level analysis

1 week

S

B. Selection of server hosting

1 day

S

A

C. Configuration of server

2 weeks

S

B

D. Detailed analysis of core modules

2 weeks

S, P to B, C

A

E. Detailed analysis of supporting modules

2 weeks

S, P to F

D

F. Development of core modules

3 weeks

S, P to E

D

G. Development of supporting modules

3 weeks

S, P to H, J

E

H. Quality assurance of core modules

1 week

S, P to G

F

I. Quality assurance of supporting modules

1 week

S

G

J. Initial client internal training

1 day

S, P to G

C,H

K. Development and QA of accounting reporting

1 week

S

E

L. Development and QA of management reporting

1 week

S

E

M. Development of Management Information System

1 week

S

L

N. Client internal user training

1 week

S

I, J, K, M

* P: Parallel, S: Sequential

Step 3: Input Activities Into Software or a Template You can draw Gantt charts by hand or use specialist software, such as Gantto, Matchware, or Microsoft Project. Some of these tools are cloud-based, meaning that you and your team can access the document simultaneously, from any location. (This helps a lot when you're discussing, optimizing, and reporting on a project.) Several Gantt chart templates have been created for Microsoft Excel, and you can also find free Gantt chart templates with a quick search online. Figure 2 – Example Gantt chart

(Click here to expand this diagram.)

Step 4: Chart Progress As your project moves along, it will evolve. For example, in our scenario, if quality assurance of core modules revealed a problem, then you may need to delay training, and halt development of the management information system until the issue is resolved. Update the Gantt chart to reflect changes as soon as they occur. This will help you to keep your plans, your team, and your sponsors up to date.

Key Points Gantt charts are useful for planning and scheduling projects. They help you assess how long a project should take, determine the resources needed, and plan the order in which you'll complete tasks. They're also helpful for managing the dependencies between tasks.

Gantt charts are also useful for monitoring a project's progress once it's underway. You can immediately see what should have been achieved by a certain date and, if the project is behind schedule, you can take action to bring it back on course.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... James wrote Hi Everyone We’ve given this popular article a review, and the updated version is now at http://www.mindtools.com/community/pages/article/ newPPM_03.php Discuss the article by replying to this post! Thanks James June 7, 2013

dp7622 wrote Hi pazza, Excel doesn't have any built-in Gantt chart templates that I know of however people do use bar charts to create them. [img:1tdmyykv]http://officeimg.vo.msecnd.net/en-us/files/670/ 681/ZA001035640.gif[/img:1tdmyykv] I googled 'Gantt Chart Excel' and found many examples for different versions of the software. See if you can find anything that helps and then get back to me. July 26, 2012 pazza98 wrote Do you have any good templates for doing this in Excel? July 22, 2012 Midgie wrote This is a great tool for anyone who is in charge of managing a project - both big and small! This tool outlines each step to developing your project plan. Simply by knowing what resources you will need and essentially ... what needs to be done, by whom and by when! Having a visual representation of your project and the task can help everyone know where they are with things. Midgie September 8, 2010

Return to top of the page

Gap Analysis Identifying What Needs to be Done in a Project Imagine that you've just been asked to improve call-handling in your organization's contact center. You already have some possible solutions in mind. However, before you choose a best solution, you need to identify what needs to be done to meet this project's objectives.

Filling the gap for project success. © iStockphoto/alexsl

This is where Gap Analysis is useful. This simple tool helps you identify the gap between your current situation and the future state that you want to reach, along with the tasks that you need to complete to close this gap. Gap Analysis is useful at the beginning of a project when developing a Business Case , and it's essential when you're identifying the tasks that you need to complete to deliver your project. Note:

Gap Analysis is not specifically mentioned as a technique in PMBOK or in PRINCE2 . However, it's a useful tool that you can apply when working with both of these project management methodologies.

Using Gap Analysis To conduct a Gap Analysis for your project, follow these three steps:

1. Identify Your Future State First, identify the objectives that you need to achieve. This gives you your future state – the "place" where you want to be once you've completed your project. Simple example: Future State

Answer 90 per cent of calls within 2 minutes.

Current Situation

Next Actions/ Proposals

2. Analyze Your Current Situation For each of your objectives, analyze your current situation. To do this, consider the following questions: • Who has the knowledge that you need? Who will you need to speak with to get a good picture of your current situation? • Is the information in people's heads, or is it documented somewhere? • What's the best way to get this information? By using brainstorming workshops? Through one-to-one interviews? By reviewing documents? By observing project activities such as design workshops? Or in some other way? Simple example: Future State

Current Situation

Answer 90 per cent of calls within 2 minutes.

Approximately 50 per cent of calls are answered within 2 minutes.

Next Actions/ Proposals

3. Identify How You'll Bridge the Gap Once you know your future state and your current situation, you can think about what you need to do to bridge the gap and reach your project's objectives. Simple example: Future State

Current Situation

Answer 90 per cent of calls within 2 minutes.

Approximately 50 per cent of calls are answered within 2 minutes.

Next Actions/ Proposals 1. Develop a call volume reporting/ queue modeling system to ensure that there are enough staff during busy periods. 2. Recruit any additional people needed.

Future State

Current Situation

Next Actions/ Proposals 3. Develop a system that allows callers to book a call back during busy periods.

Tips Pitch your Gap Analysis to provide an appropriate amount of detail. If you present too much detail, people will be overwhelmed, but if you don't give enough detail, you won't tell them what they need to know to sign the project off. When you analyze your future situation and current state, use metrics where information can be quantified (such as "Salary costs account for 50 percent of the cost of the product."), and general statements when metrics aren't available (such as "Creativity is valued within the organization.") Also remember that your assessment of the current situation and the desired future state can be both quantitative and qualitative. For instance: Assessment Type

Current Situation

Future State

Quantitative

Total costs are $100 per unit.

Total costs will be $80 per unit.

Qualitative

Team members work in isolation.

Team members will work collaboratively.

Note:

While this article illustrates a very simple use of Gap Analysis, this approach can be very extensive and complex, for example, when it is used to identify software modifications needed as part of IT projects. Don't underestimate how much work your Gap Analysis may involve!

Key Points Gap Analysis compares your current situation with the future state that you want to achieve once your project is complete. By conducting a Gap Analysis, you can identify what you need to do to "bridge the gap" and make your project a success. You can use Gap Analysis at any stage of a project to analyze your progress, but it's most useful at the beginning. To carry out a Gap Analysis, first identify your project's objectives – this is your "future state." Then analyze your current situation, making sure that you gather information from the right sources. Finally, identify how you'll bridge the gap between your current situation and the desired future state.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Sounds like a simple and powerful technique. Looking forward to the update!! Cheers! Dianna

June 21, 2012 manishsharma wrote After going thru the topic I learnt to use the technique in a proactive manner like identifying targets, compare with present performance and concluding GAPS. In my organisation, I have been very fortunate to work under Mr. Manish Sharma - Managing Director, JUSCO-A TATA Concern who has been a guide throughout and he has taught us a technique which might be useful to some of you. Its a simple excel sheet where one can capture KPI's, Action Plans, Actual status, GAPs, Proposed Action plan, Resource requirements in broadly 3 categories-Skill / Material / Equipment. In a hurry. Will update more. See you June 21, 2012 Dianna wrote Great tip about using a visual/diagram tool in conjunction with gap analysis. Certainly it will make things much easier to "see" and understand when presented visually. It's interesting that tools don't need to be complex to be effective - sometimes the simplest are the most powerful. And when a tool is simple it is more likely to be used! Dianna June 30, 2011 rtab wrote Hi, Good simple tool. I found it work in a group environment as well. Coupling it with a diagramming tool makes it even more effective. One of many toolkits for a BA. June 29, 2011 Yolande wrote I quite like analysing things and I've used gap analysis quite often. What I love about it, is the clarity it brings about where you are and where you want to be. Sometimes we have an idea of what it is we want to attain, but unless you put it down on paper as with a gap analysis, it can remain pretty vague. Reducing the 'gap' to

action steps will see the gap being closed. Just thinking about closing it will not get the job done. Any examples from other members on how, where and when you've used gap analysis? Regards Yolandé June 4, 2011 zuni wrote A gap analysis has many uses. I was first introduced to gap analysis when I was trained in change management. Of course, change management is an integral part of project management. I also use gap analysis as part of a needs assessment process. Gap analysis is helpful in identifying the actions a business unit or company needs to take to achieve business objectives and as part of assessing the develop needs for an individual, team or business unit. Michele June 4, 2011

Return to top of the page

How Good Are Your Change Management Skills? For most organizations, change is inevitable. Because of this, you'll most likely be involved in managing a change project at some point – be it a simple change to the way your team deals with customer complaints, or a major change in organizational policy or strategy. When you manage change Find out which change management skills you need to improve. effectively, you can move your © iStockphoto/alexsl organization into the new "business as usual" state swiftly, and you'll find that other people are quick to accept change. This means that your team and organization experiences minimum disruption, and projects succeed, rather than stall and fail. The quiz below helps you assess your change management skills. By using it, you can learn for yourself where your skills are strong, and where you need to develop new skills. We then guide you through the key areas of change management, and give links to resources that you can use to further develop your change management skills.

How Good Are Your Change Management Skills? Instructions:

For each statement, click the button in the column that best describes you. Please answer questions as you actually are (rather than how you think you should be), and don't worry if some questions seem to score in the 'wrong direction'. When you are finished, please click the 'Calculate My Total' button at the bottom of the test.

16 Statements to Answer 1 I usually receive good support

Not Some Rarely at All times

from senior executives for changes that I want to implement.

2 I create a plan for change for my department and team, and I let other departments deal with the impacts as they choose.

Often

Very Often

16 Statements to Answer

Not Some Rarely at All times

3 I communicate successes

throughout the organization, so that everyone understands the positive impact of a change project.

4 If the change makes financial and operational sense, then it will work.

5 If the team is dissatisfied with how something is working or operating right now, change is more likely to be successful.

6 I try to understand my

organization's culture and values as important elements of a change project.

7 When change is happening, I expect people to continue to perform at 100 percent.

8 Once I'm successful with a change project, I declare victory and move onto the next project.

9 I consider things like the impact

on people and organizational structure when planning a change project.

10 If I think something must be

changed, I start right away and make it happen.

11 To get backing and support from my team, I talk with team members about what is causing the need for change.

12 I let people get comfortable with changes before I decide if any training is necessary.

13 If key individuals are convinced

that change is needed, the rest of the stakeholders will usually come on board.

14 It’s harder to manage change

effectively when the organization has previously managed change projects badly.

Often

Very Often

16 Statements to Answer

Not Some Rarely at All times

Often

Very Often

15 When implementing a change

project, I set achievable, shortterm targets that, once accomplished, will motivate people to persist and keep trying.

16 Change is as good as a rest, so

even though it might not be necessary, it often helps to "mix things up a bit."

Total = 0

Score Interpretation Score

Comment

16-36

You tend to look at the end result and forget to focus on the immediate planning needs. To be successful with change, you must find a way to communicate and share the excitement of the end goal with your team, as a way of creating the necessary support. Take time to work through the sections below in detail to learn how to do this.

37-58

You understand many of the elements required for change, but putting them into practice doesn't always work well. Concentrate on developing a process that allows you to work on each of the elements of change one after the other. The ideas and resources below will help you do this.

59-80

You have a very good understanding of what makes change successful, and you have a good knowledge of managing, planning, and implementing change. Skim the sections below to see if there are any ideas that you can use to get even better.

The questions you just answered relate to four key areas of successful change management. They are: 1. Understanding change. 2. Planning change. 3. Managing resistance to change.

4. Implementing change. By addressing each area, you'll be better prepared to plan and implement successful change projects. We'll look at each area separately, and provide links to more in-depth resources that you can use in the change management process.

Understanding Change (Questions 1, 7, 10, 14) Before you manage a project that involves changing the way that people work, you must first understand how people react to change. Then you'll be in a better position to plan proactively for the stages of change, and for the effect that change has on your organization. The Change Curve theory describes people's reactions to each stage of change. These reactions can range from "shock and denial," when business as usual is first disrupted, to "acceptance" and "commitment," as the change is implemented. Many people need time to adjust and accept the change. So levels of performance may fall as they learn how to use new systems and processes. Lewin's Change Management Model of "UnfreezeChange-Refreeze" highlights why you need to build sufficient time into the process for people to adjust, and provide a lot of consultation with those affected by the change.

Planning Change (Questions 2, 4, 6, 9) The quote that "If you fail to plan, you're planning to fail" is as true with change management as it is with anything else. As ever, thorough preparation is the key to successful planning. As part of this, conducting an Impact Analysis will help you understand the possible positive and negative consequences of change, so that you can develop contingency plans to deal with any issues that may arise. The Burke-Litwin Change Model will help you identify every potential area of impact. It maps out the interrelated complexity of organizational structures, and helps you track how your proposed change project will affect other areas of your organization. Leavitt's Diamond is another tool that analyzes how change can impact your organization. It looks at the four major components of an organization – structure, technology, people, and tasks – and helps you think about how changes to these components can affect each other. You can also use McKinsey's 7S Framework to help you look at every affected area, and ensure that you keep issues aligned and congruent throughout the organization. Organizational design issues are particularly important, because you must ensure that your changes can be supported by your team and organization, using available resources.

Finally, the tools and techniques taught in our Project Management section will help you when it comes to planning how you'll implement change.

Managing Resistance to Change (Questions 5, 11, 13, 16) Many people are uncomfortable with change. So a large part of managing change is overcoming resistance, and promoting acceptance and belief in the change. You can overcome this resistance by communicating effectively. Talk about why change is necessary, and share your vision of change with everyone. This includes talking to all stakeholders and getting their support early in the process. These early discussions can help you assess the various barriers to change, and then plan how to manage stakeholders as you move the project forward. According to Beckhard and Harris's Change Equation , for people to be motivated to change, they must be dissatisfied with the current situation, and must think that the proposed solution is desirable and practical. Use this equation to assess readiness for change, so you can ensure that a change is actually needed, and that your planned changes will result in significant benefits. The RACI Matrix is another useful tool that can help you manage resistance to change. It shows you how to structure the various responsibilities between the change team and the rest of the stakeholders. You'll be able to deal with natural resistance, and manage issues that occur throughout the process, by keeping your communication open and well organized.

Implementing Change (Questions 3, 8, 12, 15) When you implement change, further communication is crucial – you'll almost certainly have problems at some point, and if you aren't regularly talking about the plan and communicating your successes, people may go back to old ways of doing things. Conduct Training Needs Assessments at various stages of the project to ensure that people have the skills they need to be successful as the change is implemented. People must be confident that they can do what they're being asked to do – so the time for training is before, during, and after the change. Kotter's 8-Step Change Model is a useful overall change management tool, and the last three steps of it are crucial for successful implementation. These three steps are: • Create short-term wins. • Build on the change. • Anchor the changes in corporate culture. So aim for a few early achievements to showcase the benefits of the change. This can help keep motivation and enthusiasm for the change high.

Then highlight building on the change you started, and work toward making it part of the organizational culture. This can separate "good" change management from "great" change management. Good change management is when you are satisfied when you meet your initial objective. Great change management is when you keep adjusting your target for continuous improvement – you aren't afraid to keep changing things, because you're confident in your ability to keep making progress. Tip:

For a unique perspective on effective change management, read our article on Why Change Can Fail . If you avoid the common mistakes outlined in this article, you’ll improve your chances of managing change successfully.

Key Points Managing change is a challenging and important task. If you apply a process and use a variety of tools, you can design a change plan that people will accept and work hard to implement, leading to less disruption to your team and organization. Because change doesn't happen in isolation, you must understand how change works, then broaden your thinking, brainstorm potential impacts, and maintain open communication with people. Change management doesn't end as soon as the change is implemented. Make sure that you continue to communicate achievements, and ensure that people have the skills needed to do what they are being asked to do. By taking an extensive and proactive approach to your change projects, you'll enjoy greater success, and you'll be able to build on that success for many other change projects in the future.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

More Self-tests

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote This is a really great tool with loads of links to additional resources that can help you as you manage and implement change in any size of organization. I believe many of us have experienced times when change was implemented poorly, and the negative effect it had on everyone. Yet, when change is implemented well, and everyone is on board with what is happening ... there is a very positive effect on the team where people become excited, re-invigorated and looking forward to the new challenges ahead! If you are involved with any change process, using the ideas from the tool will most certainly smooth the way for a successful implementation! Midgie June 15, 2010

Return to top of the page

How Good Are Your Project Management Skills? Whether or not you hold the official title of project manager, chances are you'll be called upon to lead some sort of project at some time. From initiating a procedural change in your department to opening a branch office in a different city, projects come in all shapes and sizes. Project managers need a broad range of skills.

As the complexity of your © iStockphoto/ez_thug projects increases, the number of details you have to monitor also increases.

However, the fundamentals of managing a project from start to finish are usually very similar. This short quiz helps you determine how well you perform in the eight key areas that are important to a successful project. The quiz is aimed at people who manage projects of a significant size, but who are not full-time project managers. However, everyone can use their answers to make sure they're applying best practices.

How Good Are Your Project Management Skills? Instructions:

For each statement, click the button in the column that best describes you. Please answer questions as you actually are (rather than how you think you should be), and don't worry if some questions seem to score in the 'wrong direction'. When you are finished, please click the 'Calculate My Total' button at the bottom of the test.

20 Statements to Answer 1 I communicate what needs to be

done by what deadline, and expect the people to whom I assign the work to be responsible for breaking down the work packages into smaller and more manageable pieces.

2 When I choose suppliers, I base my decision on their ability to

Not Some Rarely at All times

Often

Very Often

20 Statements to Answer

Not Some Rarely at All times

deliver on time as well as on price.

3 I prepare a specific timeline and

sequence of activities, and I use this schedule to manage the overall project to ensure its timely completion.

4 When a project begins, I work with its sponsor to negotiate and agree specific deliverables.

5 Project teams are only temporary, so I don’t worry too much about personalities. I select team members based on the technical skills I need.

6 At the start of a project, I formally outline what, why, who, how, and when with a Project Initiation Document – so everyone can understand how the elements of the project fit together.

7 I consider a variety of cost

alternatives when developing my original project budget plan.

8 I outline clear expectations for the project team, and I manage their individual and collective performance as part of the overall project evaluation process.

9 When a project gets behind

schedule, I work with my team to find a solution rather than assign blame.

10 I identify as many potential

project risks as I can, and I develop a plan to manage or minimize each one of them, large or small.

11 Because projects involve so many

variables that change so often, I let the plan develop on its own, as time passes, for maximum flexibility.

Often

Very Often

20 Statements to Answer

Not Some Rarely at All times

Often

Very Often

12 I use customer/stakeholder

requirements as the main measure of quality for the projects I manage.

13 I routinely monitor and reevaluate significant risks as the project continues.

14 I give people a deadline to

complete their project work, and then I expect them to coordinate with others if and when they need to.

15 I keep all project stakeholders

informed and up-to-date with regular meetings and distribution of all performance reports, status changes, and other project documents.

16 I define specifically what the

stakeholders need and expect from the project, and I use these expectations to define and manage the project's scope.

17 Forecasting costs is more art than

science, so I include extra funds in the budget and hope that I’m under cost at the end.

18 I present project status

information in an easy-to-use and easy-to-access format to meet stakeholders' information needs.

19 Delivering on time and on budget are the most important things for me.

20 When I contract for goods or

services, I often choose suppliers based on familiarity and the past relationship with my organization.

Total = 0

Score Interpretation Score

Comment

20-46

Oh dear. Right now, you may be focusing mostly on day-to-day activities rather than the bigger picture. If you spend more time on planning and preparation, you'll see a big improvement in your project outcomes. And you'll have more time to spend on productive work rather than dealing with last-minute surprises. As part of planning more for your projects, take time to create a development plan for the specific skills on which you scored lowest. (Read below to start.)

47-74

Your project management skills are OK, and when projects are relatively simple, your outcomes are often good. However, the more complex the projects you manage, the less control you will have and the more likely you are to deliver below expectations. Take time to improve your planning skills and prepare for the unexpected. The more time you spend on your up-front planning, the better your project outcomes will be. (Read below to start.)

75-100

You are an accomplished project manager. Few things that happen will upset you, or hurt your confidence in your ability to lead the project to a successful end. Use your mastery to help others on your team develop their project management skills. Lead by example, and provide opportunities for other team members to manage parts of the project. Also, be aware of your own strengths and weaknesses. Just as you review a project at its completion, make sure that you review your own performance, and identify what you can do better next time. (Read below to start.)

Project Integration (Statements 6, 11) At the beginning of a project, it's important to develop a solid understanding of the project's goals, and how the various elements will fit together for a successful outcome. Start by producing a Business Requirements Analysis , and then develop a comprehensive Project Initiation Document , which covers the basic project needs and outcomes, so that everyone can understand the project's goals. To prepare this critical, high-level document, you need to understand the phases and processes of project management . This overview will help you become better prepared for what's ahead. Understanding the planning cycle is also important, because it

helps you appreciate how important your project plan is to a successful outcome.

Scope Management (Statements 4, 16) Projects have a nasty habit of expanding as they go along, making it impossible to hit deadlines. To control this “scope creep,” it's essential to define the scope at the very start of your project based on the Business Requirements Analysis, and then manage it closely against this signed-off definition. For more on how to do this, see our article on scope control .

Schedule Management (Statements 1, 3, 9, 14) A project's scope can easily grow, and so can the time needed to complete it. For a project to be completed successfully, despite all of the unknowns, it's important to clearly define the sequence of activities, estimate the time needed for each one, and build in sufficient contingency time to allow for the unexpected. It's also important to monitor full completion of each activity – it's shocking how long it sometimes takes for an activity to move from “80 percent complete” to 100 percent complete! With this information, you can develop a Project Schedule and then begin breaking it down into very specific pieces of work using a Work Breakdown Structure . A schedule often isn't enough, particularly when different people do different things and their work output becomes the input for another piece of work. To keep track of the various activities, Gantt Charts and Critical Path Analysis are often helpful. These tools allow you to prepare and manage your schedule for maximum efficiency.

Cost Management (Statements 7, 17) To determine what a project will cost, you must be systematic with your estimating, budgeting, and controlling. Also, be aware that many project decisions will have an impact on cost. Therefore, it's important to understand what's driving your costs and to develop a system for monitoring the project's financial performance. Managing project finances requires many tools and strategies, and it's very important to set up a reliable control system to keep track of the costs and required changes.

Quality Management (Statements 4, 12, 19) Projects must be delivered not only on time and on budget, but also to specification (this is what “quality” means in project management). As part of this, ensure that you actively manage project benefits . By continuously referring to the benefits that the project will provide,

you keep client quality at the forefront – and you won't waste precious time and resources trying to achieve an inappropriate level of quality. An effective project manager knows the importance of checking that project outcomes are consistent with needs. The Deming Cycle (Plan-Do-Check-Act) and Business Testing are important tools for this, as they both force you to consider the needs of the end users.

People Management (Statements 5, 8) The people on your project team can make or break the final outcome. Here, getting the right mix of interpersonal and political skills is just as important as the right technical skills. To help your new team start working together effectively as soon as possible, develop a Team Charter and outline performance expectations . Use well-informed task allocation and appropriate team management skills to keep the project team on track and working productively. And be prepared to help people through the Forming, Storming, Norming and Performing stages that so many teams go through.

Communication (Statements 15, 18) As with most situations, effective project communication means communicating with the right people at the right time and in the right way. To do this, Stakeholder Management is essential. When you analyze your stakeholders , you identify who must be kept informed in full, and who needs less intensive communication. This can save you a lot of time, and helps you maintain good relationships with people involved in the project. Project Dashboards are great for presenting project updates in a way that people can quickly understand. For longer projects that require periodic status reports, Milestone Reporting is effective for capturing the essentials of a project's status.

Risk Management (Statements 10, 13) Project managers must understand which of the risks to their plans are significant. An Impact/Probability Chart will help with this. From there, develop a plan for monitoring and controlling the major risks involved in your project. Using your Risk Analysis , develop options to reduce risks, prepare Contingency Plans , and decide who is responsible for which parts of risk response.

Project Procurement (Statements 2, 20) Unless your project is in-house, external suppliers will generally have a large impact on your costs. Suppliers will also affect whether the project delivers on time and to specification.

Take the time to define your needs in a Request for Proposal document, and then use an appropriate Procurement Management approach to select the best supplier. Tip:

For more on these project management skills take a look at the Project Management Body of Knowledge (PMBOK).

General Project Management Skills (Statements 4, 9) This quiz also highlights some general skills that you should be aware of while developing your project management skills. Negotiation – specifically, Integrative Negotiation – is very important for dealing with suppliers and getting the in-house resources you need, when you need them. Conflict resolution is another important general skill. From resolving conflict within your project team to managing conflict that arises during negotiation, this is a fundamental skill for project managers. And, ultimately, your problem-solving skills are essential. They will not only improve negotiation and conflict resolution skills, but also help with risk management, time management, and quality management.

Key Points Project management is a complex process that requires a wide range of skills. Whether you manage projects on a regular basis or only once or twice a year, the skills learned in project management are applicable to many managerial and leadership positions. Understanding client needs and meeting their expectations in a timely manner are universal requirements. Use the information you gain here to improve specific project management skills – as well as your general workplace skills.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

More Self-tests

View print friendly versio

Ask questions, or share your experience

What members say... AnneE wrote Hi Rigo The comment that you make is a very valid one, and would prove a helpful additional angle to explore in this quiz. Just because of their nature, the quizzes are not as easy to update as our articles, as each one needs to work as a complete set of questions - but this is something that I would like to consider including when it is updated. Anne February 14, 2014 Midgie wrote Hi Rogo, Thanks for the feedback, and the comments about inexperienced project managers giving equal weighting to things, which may or may not be valid and may have an impact on the critical path. I've brought this to the attention of our editorial team to take a look at and potentially amend the article to reflect that very important point. Hope to see you around with more comments and questions of your own. Midgie February 4, 2014 Rogo wrote

G'day MT Team This is a good, helpful tool. Some questions are open to interpretation, but that's understandable in this context I would recommend this as a starting guide for anyone facing a Project Management task for the 1st time & also as a refresher for anyone who doesn't manage projects as their everyday work. In my experience & research, I reckon that Project Management is one of the most poorly executed disciplines in almost every walk of life, so a good brief like this is welcome! I think you are to to be congratulated for covering the major elements very well, though I would like to make a comment re 1 specific that could be included... One of the biggest pitfalls in any PM scope, is the tendency for an inexperienced Manager to give all tasks/sequences a somewhat equal weighting. This is a major major bungle because there will be a 'Critical Path' that will determine the outcome as successful or not! Do you think that a question to highlight this fact would be worthwhile to include at this stage or is it too advanced?? Regards Rogo February 3, 2014 Rachel wrote Hi All Many of us lead projects as part of our roles, and there many skills that we need to learn to do this successfully. Find out which skills will be of most benefit to you, in this week's Featured Favorite self-test. Best wishes Rachel May 14, 2013 Dianna wrote Thanks mikky! That's great feedback. If we can help you address the points you want to improve let us know. Using the forums in conjunction with the tools provides an effective way to get the information and support you need to reach your goals. Keep us posted! Dianna October 16, 2012 mikky wrote I presently work as a professional project manager in an

establishment and I must say that this quiz is quite on point! My score is a true reflection of my present state in the project management field. I have taken the feedback and I hope to work hard on improving on the 'weak' areas identified. Thanks October 16, 2012 Dianna wrote Hi Paul, Glad you enjoyed the quiz Paul! Keep us posted on your progress and let us know how we can support you. Dianna September 25, 2012 Midgie wrote Hi Paul, Welcome to the Club. Glad to hear that the quiz has given you some good food for thought and a structure to move forward. Let us know how we can help you as you do move forward. If you want to bounce around any thoughts or questions, why not come over to the Cafe area. Hope to see you around. Please let me know if there is anything I can help you with. Midgie September 24, 2012 paul_murray wrote This is a great starting point for me to get a grip over my weaknesses and start moving forward in a structured manner. Great stuff! Paul September 24, 2012

Return to top of the page

How to Write a Business Case Getting Approval and Funding for Your Project You've got some great ideas for improving the way your department delivers what's required of it. But how do you get approval for your projects to go ahead? And how do you ensure that you receive the resources you need to complete them successfully?

Detail the benefits, cost, approaches and timescale of your proposed project.

The answer is this: by creating © iStockphoto/DNY59 a proper business case document. In formal projects, a business case is the main deliverable from the Strategy and Business Case Project Phase . It's one of the key documents that senior managers review when deciding whether to give a project the funding it needs to go ahead. In the business case, you detail the benefits that the project will deliver, how they'll be achieved, what it will cost, and how long it will take. There are a number of other benefits that come from writing a business case: • You have to be specific about what your project will achieve, all in a single document, so this encourages you to think the project through and record your key assumptions. • It provides a project baseline, against which you can track scope, cost, time lines, and the delivery of benefits. • It gives you with an opportunity, right at the start of the project, to ensure that all of your stakeholders understand what you're delivering (and not delivering) and recognize any responsibilities and obligations they have in supporting the project. To get the biggest advantage from this, think about how you can get your most important stakeholders involved. For example, you could consult with them before you put the business case together – or, alternatively, you could get their input when writing your business case, and get their feedback on early drafts. Several of the articles within the Building Support for Your Projects section of our Project Management area will help you here. In particular, look at our articles on Working with Project Sponsors , Stakeholder Analysis , Stakeholder Management , the RACI Matrix and Influence Maps .

How to Use the Tool Each business case should include several core components. The level of detail needed within your document will depend on the stage that the project is at, and on the level of complexity and investment

required in the project. For example, in a complex project, you may need to submit an initial business case to seek approval of the project in principle. This would then lead to the release of preliminary funding, so that the project manager can produce a full business case, with a detailed analysis of scope, costs, and benefits. Approval of this detailed business case would then release funding for the project to be implemented in full. On the other hand, a project to change an existing standalone IT system to deliver a legal requirement may be quick to implement, because it's self-contained, and has minimal impact. In this case, the business case may be only a few pages long. Tip:

Most organizations have a rigorous, careful process for allocating funds to projects. They may also have a set of priorities or considerations against which projects are assessed. Investigate the templates and guidelines available within your organization before you start writing your business case. In particular, explore whether there's a template that you must use (and which parts of this are mandatory or optional). Identify who approves business cases for the level of investment that your project requires, and determine the assessment criteria for project approval. The core business case components are as follows: • Management summary – Here, summarize the key points within each business case section, ideally on one page. You'll write this summary after you've clearly thought through the project proposal in detail, and written the rest of the business case document. • Project background – Identify the issue, opportunity, and business strategy requirements that the proposed project will address. Discuss any other options that you have considered and rejected as potential solutions. Identify any implications of not approving the project. Give information on the key stakeholders who have been involved in developing the project proposition, and explain the work that's already taken place in earlier project phases or in dependent projects. • Objectives – State what the project will deliver using SMART objectives . • Scope – Define what the project will deliver. Be clear about what is in the scope, and what's out of scope. You may find it helpful to list processes or process areas, geographical areas, departments/ functions, equipment, systems (remember to state which system interfaces are in scope - this is often forgotten!), or stakeholder groups as a way of being clear about what is in scope. It's often also useful to state where the project responsibilities will end. For example, the project may be responsible for setting up the initial training of the internal support team. However, the internal support team may then be responsible for training end users as part of their existing "business as usual" responsibilities.

• Dependencies – Identify any project dependencies. For example, state clearly if your team is in any way dependent on work from another team to complete the project. Also, be sure to state whether another project relies on something that you're delivering. • Risks – Identify the critical risks within the project. State how you plan to eliminate, reduce or manage these risks , and determine the implications of not doing so. You might also find it helpful to estimate the probability of each risk occurring, or give more detail about the conditions under which you could not effectively reduce the risk. • Costs and resources – Clearly lay out your project budget. In addition, highlight resources that you're depending on, but that don't need cash expenditure. These resources may include things like IT hardware, people, equipment, and rooms that are already available. In these cases, state the amount of these resources that you'll need, and highlight where you expect these resources to come from. Clearly state any assumptions that support the cost estimates in the business case, as well as any numbers that you've left out. For example, if you've assumed that there's sufficient data storage capacity already available, state this. Areas that are often forgotten in budgets include expenses for staff who must attend project events (such as workshops or business testing exercises) and extra systems hardware capacity. For example, if an additional server is needed to support testing, but it won't be needed once the project "goes live," it's easy to forget to budget for this. Managers often have problems getting hold of the resources they need for their projects. This is why it's really important to have key stakeholders give up-front approval, and understand the resources that the project will need. • Benefits – State the benefits that the project will deliver. These should include both qualitative and quantitative benefits. • Milestones – State your project time line. If the project has to be delivered by a certain date to achieve legal or internal deadlines, state this. Also, be clear about the implications of the project starting, or not starting, by a certain date. • Project Evaluation – How projects are evaluated will depend on the organization and its mission. However many organizations will base go/no-go decisions on the project's Internal Rate of Return or Net Present Value, both of which are measures of the return that the project will deliver to the organization once costs have been considered. Tip:

Just as your organization is likely to have specialized templates for business cases, it's likely to have specialized rules detailing how projects should be evaluated. If appropriate, get help from your finance department to make sure that this part of your business case is correctly structured.

Key Points The business case is a key document in the initial stages of a project. It details how the project will proceed, and it's the key document that decision-makers need to decide whether to approve and fund your project. As well as this, it sets the baseline for the project's scope, costs, and time lines, which means that it's a key document for determining whether the project is judged as a success or a failure. As such, take care with this document – after all, anything that's wrong, left out or misunderstood could is likely to cause problems later. As with many of the key project management documents, the business case provides you with an opportunity to engage with your key stakeholders and build support for your project. Make sure that you take best advantage of this opportunity!

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote It's great to hear you enjoyed the article - welcome to the forums. As you can see this is a great place to come for information and ideas about current workplace issues you are dealing with. The contributions from members is invaluable and really enriches the whole learning process. I hope you will visit us often and join in

the conversations as well as start your own topics. If you ever have any questions please let me know - I'm here to help you get the most from your membership. Cheers! Dianna December 21, 2010 gusfekei wrote Thanks for the article. I am a Project Management student and I found this article every interested. December 20, 2010 tonysen10 wrote thanks Helena and Yolande for your response and info - Very glad to see the LFA is a part of the training - I find it to be one of the best project planning tools March 2, 2010 Yolande wrote Hi tonysen10 Welcome to the Club and to the forums - it's great to see you round! Thanks for referring to LOGFRAME - we actually have a wonderful article on that called "Logrames and the logical framework approach" . I include the link for those who might want to have a quick look before they reply to your question. http://mindtools.com/community/pages/ar ... PPM_86.php Please let me know if you need any help around the club and we hope to see you on the forums often! Kind regards Yolandé March 2, 2010 tonysen10 wrote Much of this topic is framed in the excellent NGO tool called a LOGFRAME or a Logical framework Would like to know if anybody has used it March 2, 2010 rashidm wrote

This topic has come at the right time. I am just in process of writing a business case. The information will defiantly help me in my cause. I will welcome any information/tips etc other members may have been involved in writing their business case. What were the learning experience? i.i.e. what went well, and what didn't go well? etc. Many thanks. I look forward hearing from more experience members. Kind regards Rashid February 19, 2010

Return to top of the page

Influence Maps Uncovering Where the Power Lies in Your Projects Many people can have influence over your projects. Some influencers are obvious and easy to spot. Others are less obvious, but are no less significant. If you fail to recognize and "manage" these influencers, you'll most-likely experience unexpected resistance to your projects, and sometimes bewildering failure.

Who influences whom? © iStockphoto/iqoncept

This is increasingly the case as you run large projects, and as the number of people affected by your projects increases. People within your organization, at least, are supposed to work together openly and willingly. However, even here, your boss, your teammates, your customers, your boss's boss – even the CEO's nephew in the mailroom – can all impact you, given certain sets of circumstances. However people outside your organization have all sorts of interests and motivations that you can't control. Here, knowing who influences who can be critical if you want to get anything done at all.

Influence Mapping So do you understand who has influence over your projects? Do you know the nature, direction, and strength of these influences? After all, using the normal "chain of command" may not always be the best way to advance your objectives: Knowing who the real influencers are can help you determine where you should put your effort if you really want to succeed. This is what influence mapping is all about – discovering your project's true stakeholders (not just the obvious ones) and the influence relationships between them. This helps you target the key influencers so that you can win the resources and support you need to reach your goal. Influence maps are a natural extension of Stakeholder Analysis . Your project's success can depend on identifying its key stakeholders and then managing the various relationships between them. Stakeholders have the power to help or hurt your initiatives, so stakeholder management is an important aspect of project

management. For more on this, see our Winning Support for Your Project Bite-Sized Training.

The Elements of an Influence Map An influence map is a visual model showing the people who influence and make decisions about your project. The map helps you understand how stakeholders relate to one-another, so that you can quickly see the way in which influence flows. Remember that even the most powerful people rarely act alone. Top executives and other people in authority rely on advisers. Find out who the advisers are, and understand how they operate. This can be vital to your project's success. There are three main considerations when you construct an influence map: 1. The importance or weight of a stakeholder's overall influence (represented by the size of the circle representing that stakeholder). 2. The relationships between stakeholders (represented by the presence of lines or arrows between them). 3. The amount of influence stakeholders have over others (represented by the heaviness of the lines drawn between them). Your completed influence map shows the stakeholders with the most influence as individuals with the largest circles. Lines (arrows) drawn to other stakeholders indicate the presence and strength of influence.

Example We'll use an example to illustrate. You've proposed a new organizational structure that will encourage people to work in business units with cross-functional teams. You know this is a huge change, and you want to make sure it's well supported within the company before you try to implement it. The most obvious stakeholders are: CEO

Elizabeth Brown

CFO

Dennis Gordon

Director of Marketing

Pamela Enns

Director of Product Development

Jon Evans

Director of Human Resources

Wallace Houston

But are there other stakeholders as well? And who holds influence over whom?

Upon further investigation, here's what you discover: • The entire HR team will be important to the reorganization – but not just the director of HR. Francis Beaton, the newly hired change agent, will be especially important. • Elizabeth Brown has worked with Jon Evans for over 15 years, and she values Jon's input on strategic initiatives. • The board of directors is chaired by a longtime associate of Jon Evans. Like Elizabeth Brown, the board chair values Jon's opinions and has never objected to any initiative Jon has ever backed. • Wallace Houston and Dennis Gordon have a history of conflict. This is because Dennis was very late to realize HR's strategic value. Dennis still has difficulty spending money on HR projects, which he considers to be "soft" expenses. Getting Dennis's buy-in is critical if you want the financial resources needed for the change. So when you look more closely, you can identify additional people who will have an impact on your reorganization plan. And not everyone has the same influence. The resulting influence map looks something like this:

This influence map clearly shows how important Jon Evans is to the success of your restructuring plan. It also indicates that you should spend energy on gaining support from Wallace Houston and Dennis Gordon before moving on to other executives. Before you thought about stakeholder influences, you might have assumed that the CEO and CFO had the most influence on organization-wide change. But the influence map shows you that this is probably not for the case in this situation.

Influence is not static. It changes over time, just like the circumstances surrounding each project or decision. If you create influence maps at regular intervals, you'll chart these differences and gain a much greater appreciation for the way decisions are made. This will help you to smooth the decision making process and be more effective.

Creating an Influence Map Follow these steps to construct an influence map. Step One: Prepare a stakeholder analysis . This helps you identify, prioritize, and understand your key stakeholders. Step Two: For each stakeholder, find out the following: • Whom does he or she influence, and who influences him or her? • How strong is that influence? • What is the history of each relationship? How does this impact overall influence? • What role does hierarchy play in the amount of influence? Step Three: Map the importance of influence using the size and position of the circles. The largest circles belong to stakeholders with the most influence. Where possible, place the most influential stakeholders at the top of the page, and put less influential people lower down. Step Four: Map the direction of influence by drawing arrows to link the stakeholders. (These may be one-way or two-way, depending on whether influence flows to the same extent in both directions). Step Five: Map the strength of influence by using thicker lines to indicate stronger influence. In some situations, the person who signs off projects or purchases may not actually be the most influential person in the network. For example, a Head of Purchasing might always accept the recommendations of the IT Department. In this case, it's worth marking who has sign-off authority on your map, however, it's worth checking quite carefully that they really are as influenced by others as the others claim! Step Six: Study the map, and identify stakeholders with the most overall influence. Form a stakeholder management plan that will allow you to communicate with, and hopefully influence, these important influencers. Step Seven: Map these influence relationships on a regular basis. This way, you'll better understand the dynamics of decision making relating to your project.

Key Points Influence maps are important visual models of the key people and relationships that impact a project or decision. (Don't make the mistake of thinking that hierarchy or traditional lines of authority are always the routes by which decisions are made.) Take the time to uncover the underlying relationships and influence that key stakeholders have. With this insight, you can tap into the real sources of power and persuasion. While this is something that people do intuitively in small projects, it's something that you'll need to do actively for larger projects. This is particularly the case in projects that involve people outside your organization.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

Next Handling "Politics" Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... Rachel wrote Hi All Who has the power to help, or even hinder, your project's success? Find out with this week's Featured Favorite on Influence Maps. Click below to learn more! http://www.mindtools.com/community/pages/article/ newPPM_83.php Best wishes Rachel November 15, 2011

Return to top of the page

Kotter's 8-Step Change Model Implementing Change Powerfully and Successfully Change is the only constant. – Heraclitus, Greek philosopher What was true more than 2,000 years ago is just as true today. We live in a world where "business as usual" is change. New initiatives, project-based working, technology improvements, staying ahead Learn how to implement change successfully. of the competition – these © iStockphoto things come together to drive ongoing changes to the way we work. Whether you're considering a small change to one or two processes, or a system wide change to an organization, it's common to feel uneasy and intimidated by the scale of the challenge. You know that the change needs to happen, but you don't really know how to go about delivering it. Where do you start? Whom do you involve? How do you see it through to the end? There are many theories about how to "do" change. Many originate with leadership and change management guru, John Kotter. A professor at Harvard Business School and world-renowned change expert, Kotter introduced his eight-step change process in his 1995 book, "Leading Change." We look at his eight steps for leading change below.

Step 1: Create Urgency For change to happen, it helps if the whole company really wants it. Develop a sense of urgency around the need for change. This may help you spark the initial motivation to get things moving. This isn't simply a matter of showing people poor sales statistics or talking about increased competition. Open an honest and convincing dialogue about what's happening in the marketplace and with your competition. If many people start talking about the change you propose, the urgency can build and feed on itself. What you can do: • Identify potential threats , and develop scenarios what could happen in the future. • Examine opportunities

showing

that should be, or could be, exploited.

• Start honest discussions, and give dynamic and convincing reasons to get people talking and thinking. • Request support from customers, outside stakeholders and industry people to strengthen your argument.

Note:

Kotter suggests that for change to be successful, 75 percent of a company's management needs to "buy into" the change. In other words, you have to work really hard on Step 1, and spend significant time and energy building urgency, before moving onto the next steps. Don't panic and jump in too fast because you don't want to risk further short-term losses – if you act without proper preparation, you could be in for a very bumpy ride.

Step 2: Form a Powerful Coalition Convince people that change is necessary. This often takes strong leadership and visible support from key people within your organization. Managing change isn't enough – you have to lead it. You can find effective change leaders throughout your organization – they don't necessarily follow the traditional company hierarchy. To lead change, you need to bring together a coalition, or team, of influential people whose power comes from a variety of sources, including job title, status, expertise, and political importance. Once formed, your "change coalition" needs to work as a team, continuing to build urgency and momentum around the need for change. What you can do: • Identify the true leaders in your organization, as well as your key stakeholders . • Ask for an emotional commitment from these key people. • Work on team building within your change coalition. • Check your team for weak areas, and ensure that you have a good mix of people from different departments and different levels within your company.

Step 3: Create a Vision for Change When you first start thinking about change, there will probably be many great ideas and solutions floating around. Link these concepts to an overall vision that people can grasp easily and remember. A clear vision can help everyone understand why you're asking them to do something. When people see for themselves what you're trying to achieve, then the directives they're given tend to make more sense. What you can do: • Determine the values

that are central to the change.

• Develop a short summary (one or two sentences) that captures what you "see" as the future of your organization. • Create a strategy

to execute that vision.

• Ensure that your change coalition can describe the vision in five minutes or less.

• Practice your "vision speech" often. Tip:

For more on creating visions, see our article on Mission Statements and Vision Statements .

Step 4: Communicate the Vision What you do with your vision after you create it will determine your success. Your message will probably have strong competition from other day-to-day communications within the company, so you need to communicate it frequently and powerfully, and embed it within everything that you do. Don't just call special meetings to communicate your vision. Instead, talk about it every chance you get. Use the vision daily to make decisions and solve problems. When you keep it fresh on everyone's minds, they'll remember it and respond to it. It's also important to "walk the talk." What you do is far more important – and believable – than what you say. Demonstrate the kind of behavior that you want from others. What you can do: • Talk often about your change vision. • Address peoples' concerns and anxieties, openly and honestly. • Apply your vision to all aspects of operations – from training to performance reviews. Tie everything back to the vision. • Lead by example

.

Step 5: Remove Obstacles If you follow these steps and reach this point in the change process, you've been talking about your vision and building buy-in from all levels of the organization. Hopefully, your staff wants to get busy and achieve the benefits that you've been promoting. But is anyone resisting the change? And are there processes or structures that are getting in its way? Put in place the structure for change, and continually check for barriers to it. Removing obstacles can empower the people you need to execute your vision, and it can help the change move forward. What you can do: • Identify, or hire, change leaders whose main roles are to deliver the change. • Look at your organizational structure, job descriptions, and performance and compensation systems to ensure they're in line with your vision. • Recognize and reward people for making change happen. • Identify people who are resisting the change, and help them see what's needed.

• Take action to quickly remove barriers (human or otherwise).

Step 6: Create Short-Term Wins Nothing motivates more than success. Give your company a taste of victory early in the change process. Within a short time frame (this could be a month or a year, depending on the type of change), you'll want to have some "quick wins " that your staff can see. Without this, critics and negative thinkers might hurt your progress. Create short-term targets – not just one long-term goal. You want each smaller target to be achievable, with little room for failure. Your change team may have to work very hard to come up with these targets, but each "win" that you produce can further motivate the entire staff. What you can do: • Look for sure-fire projects that you can implement without help from any strong critics of the change. • Don't choose early targets that are expensive. You want to be able to justify the investment in each project. • Thoroughly analyze the potential pros and cons of your targets. If you don't succeed with an early goal, it can hurt your entire change initiative. • Reward

the people who help you meet the targets.

Step 7: Build on the Change Kotter argues that many change projects fail because victory is declared too early. Real change runs deep. Quick wins are only the beginning of what needs to be done to achieve long-term change. Launching one new product using a new system is great. But if you can launch 10 products, that means the new system is working. To reach that 10th success, you need to keep looking for improvements. Each success provides an opportunity to build on what went right and identify what you can improve. What you can do: • After every win, analyze what went right, and what needs improving. • Set goals achieved.

to continue building on the momentum you've

• Learn about kaizen

, the idea of continuous improvement.

• Keep ideas fresh by bringing in new change agents and leaders for your change coalition.

Step 8: Anchor the Changes in Corporate Culture Finally, to make any change stick, it should become part of the core of your organization. Your corporate culture often determines what gets done, so the values behind your vision must show in day-to-day work.

Make continuous efforts to ensure that the change is seen in every aspect of your organization. This will help give that change a solid place in your organization's culture. It's also important that your company's leaders continue to support the change. This includes existing staff and new leaders who are brought in. If you lose the support of these people, you might end up back where you started. What you can do: • Talk about progress every chance you get. Tell success stories about the change process, and repeat other stories that you hear. • Include the change ideals and values when hiring and training new staff. • Publicly recognize key members of your original change coalition, and make sure the rest of the staff – new and old – remembers their contributions. • Create plans to replace key leaders of change as they move on. This will help ensure that their legacy is not lost or forgotten. Tip:

This is just one of the articles on change management on Mind Tools. Also see our articles on Change Management , Lewin's Change Model , using the Change Curve , the Burke-Litwin Change Model and Overcoming Cultural Barriers to Change .

Key Points You have to work hard to change an organization successfully. When you plan carefully and build the proper foundation, implementing change can be much easier, and you'll improve the chances of success. If you're too impatient, and if you expect too many results too soon, your plans for change are more likely to fail. Create a sense of urgency, recruit powerful change leaders, build a vision and effectively communicate it, remove obstacles, create quick wins, and build on your momentum. If you do these things, you can help make the change part of your organizational culture. That's when you can declare a true victory. then sit back and enjoy the change that you envisioned so long ago.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... Rachel wrote Hi all, It's a cliche, but change really is constant in today's business environment. Therefore, you need to be able to implement change effectively. Find out how to do this, with Kotter's 8-Step Change Model. Best wishes Rachel November 12, 2013 Dianna wrote Thanks for those great recommendations miadanu. "Our Iceberg Is Melting" received very mixed reviews so it's good to hear you enjoyed the way it was presented. November 25, 2007 miadanu wrote Nice overview of the model - hopefully it will motivate people to find out more.

I can highly recommend that everyone involved in driving / implementing change also read 'The Heart of Change' by Kotter and Cohen. It really solidified the principles for me with the case studies and the switch from thinking logically about a change to connecting with the feelings involved in it. For those who prefer fables to theory and case studies, take a look at 'Our Iceberg is Melting' by Kotter and Rathgeber. It's a short story, beautifully illustrated, showing the plight of penguins who have various reactions to the idea that their iceberg may be melting. Personally I prefer it to 'Who moved by cheese?'. November 25, 2007

Return to top of the page

Leavitt's Diamond An Integrated Approach to Change Also known as Leavitt's System Model It seems as if there's an epidemic of change out there! Re-engineering, restructuring, revamping – workplaces today seem to be launching one change initiative after another. But the hard truth is that many change initiatives fail. Why? The answer may lie in the way we view change. Do you see it Organizational strands are usually knotted together. as an isolated process? And do © iStockphoto/filonmar you focus only on one part of your organization in isolation? This can be a fatal error. Everything in an organization is connected, and changing one piece can impact another. This is why change is only likely to be successful if it considers all of those interconnected pieces. This is where Leavitt's Diamond is useful. Designed by Harold J. Leavitt in 1965, the model is a framework for understanding the connection between the key factors in an organization, and for building an integrated change strategy.

Understanding the Tool Leavitt's Diamond is based on the principle that an organization has four major components that are all interdependent: 1. Tasks 2. People 3. Structure 4. Technology Any type of change or redesign in one component will affect the other three.

According to this approach, before you bring about change in any one of the four components, you should evaluate the impact on the other three components. To implement change successfully, you need to find the right balance between all of them. A classic example is introducing new technology. A change in technology means that people need to change too – they'll need training to use the new technology. This may affect the organizational structure, because people might demand higher pay and better positions. The new technology may also change old tasks. For instance, if the change automates old processes, the work that people do will be different.

How to Use the Tool Leavitt's model can be a good starting point for any change analysis process. Whether you plan a simple process redesign or a complete organizational restructure, Leavitt's Diamond helps you assess the impact of the proposed change – so you can plan and provide for those impacts in advance. To use Leavitt's Diamond, follow this two-step process.

Step One: Define Each Component • Tasks Identify your work unit's main tasks, including both routine and key tasks. For example, if your work unit is a restaurant, the key tasks could be taking orders, preparing meals, and serving meals. The routine tasks could be cleaning, setting tables, and so on. To help define your tasks, consider these questions: • What is the staff expected to do? • How do staff get work done? • Why does the work unit exist?

• People Define the "people" within your work unit. People are often the key consideration in any change initiative, because skill sets and staff attitudes greatly affect the success of change in any organization. To help define your "people" component, consider the following: • What are their beliefs, attitudes, and behaviors? • What is their response to the proposed change? • What are their skill levels? • What are they trained to do? • What are the rewards that motivate them? • What is their work culture? • Structure Determine how people are grouped within the work unit. In other words, what is your organizational structure? If we go back to our restaurant example, the structure could be defined in terms of waiters, chefs, managers, cleaners, and so on. Ask yourself these questions: • What is the hierarchy in your work unit? • Is the unit centralized or decentralized? • Where is the control at each level? • How are the work units divided? • What is the geographical breakdown (if everything isn't at one location)? • How are duties divided? • What is the work flow? • What is the communication flow? • Technology Identify the technology that your work unit uses by making these two lists: 1. Key equipment and processes that enable and support your business functions, including computer systems, essential software, devices – anything that enables communication and work flow. 2. Tools you can use to implement the proposed change, including things such as seminars and training materials.

Step Two: Analyze the Impact of the Proposed Change Determine how the primary change will impact each of the four components. The "how-to" of the analysis is best explained through an example. ABC Company has decided to introduce a new skill-based assessment procedure for its field engineers. Under this system, the engineers will be evaluated primarily on their skills. They'll be expected to keep up with the latest developments in their field and use them effectively. Furthermore, instead of the boss, peers will be asked to rate other engineers.

What will the impacts be? • Task – The primary change will occur in the task component of the diamond. The work unit will have to take on the new task of conducting skill-based assessments. So, what is impact of this primary change on the other three components of Leavitt's diamond? • People – Engineers may be uneasy about the new system. They may think "Am I good enough?" "Won't it involve a lot of work?" "Will I have time to track new developments?" "How do I rate my peers?" These concerns will need to be addressed if the change is to be successful. • Structure – Old career advancement patterns might not align with the new assessment procedure. The new procedure might create a more skilled pool of people. These people, in turn, might demand higher pay and better positions. • Technology – This change may need changes to be made to computer systems: Once established, the new procedure may need a database to store and track the skill-based assessments on an ongoing basis. The organization might also need technology and training seminars to help with continuous learning for engineers. In summary, ABC Company's analysis revealed that its new assessment procedure is likely to meet a lot of resistance from the engineers. The procedure needs to be supported by an upgrade in technology. Also, the old structure and the new procedure aren't really aligned with each other. For a successful change, ABC Company has to design an integrated strategy that addresses all of these issues. Using this model, you can conduct a similar analysis for a different change proposal. The key findings of your analysis will become the foundations of your change strategy. Tip:

Leavitt's Diamond is only one such approach used to look at the impact that change can have on an organization. See also our articles on more recent models like the Congruence Model , the Burke-Litwin Model , and the McKinsey 7Ss . Also, see our article in Impact Analysis through the impact of change in detail.

, which helps you think

Key Points Change cannot be implemented in isolation, as it can have many knock-on impacts throughout an organization, both expected and unexpected. Organizations are inter-connected structures, where changing one part can impact many others. Therefore, to implement change successfully, you have to adopt an integrated change strategy. The idea of Leavitt's Diamond can help you build this integrated strategy.

It provides an easy framework for understanding the interdependency between four key variables: tasks, people, structure, and technology. Using this framework, you can analyze the impact of the proposed change and use the results within your implementation strategy.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Lewin's Change Management Model Understanding the Three Stages of Change Change is a common thread that runs through all businesses regardless of size, industry and age. Our world is changing fast and, as such, organizations must change quickly too. Organizations that handle change well thrive, whilst those that do not may struggle to survive.

Unfreeze-Change-Refreeze. © iStockphoto/doram

The concept of "change management" is a familiar one in most businesses today. But, how businesses manage change (and how successful they are at it) varies enormously depending on the nature of the business, the change and the people involved. And a key part of this depends on how far people within it understand the change process. One of the cornerstone models for understanding organizational change was developed by Kurt Lewin back in the 1950s, and still holds true today. His model is known as Unfreeze – Change – Refreeze, refers to the three-stage process of change he describes. Lewin, a physicist as well as social scientist, explained organizational change using the analogy of changing the shape of a block of ice.

Understanding Lewin's Model If you have a large cube of ice, but realize that what you want is a cone of ice, what do you do? First you must melt the ice to make it amenable to change (unfreeze). Then you must mold the iced water into the shape you want (change). Finally, you must solidify the new shape (refreeze).

By looking at change as process with distinct stages, you can prepare yourself for what is coming and make a plan to manage the transition – looking before you leap, so to speak. All too often, people go into change blindly, causing much unnecessary turmoil and chaos. To begin any successful change process, you must first start by understanding why the change must take place. As Lewin put it,

"Motivation for change must be generated before change can occur. One must be helped to re-examine many cherished assumptions about oneself and one's relations to others." This is the unfreezing stage from which change begins.

Unfreeze This first stage of change involves preparing the organization to accept that change is necessary, which involves break down the existing status quo before you can build up a new way of operating. Key to this is developing a compelling message showing why the existing way of doing things cannot continue. This is easiest to frame when you can point to declining sales figures, poor financial results, worrying customer satisfaction surveys, or suchlike: These show that things have to change in a way that everyone can understand. To prepare the organization successfully, you need to start at its core – you need to challenge the beliefs, values, attitudes, and behaviors that currently define it. Using the analogy of a building, you must examine and be prepared to change the existing foundations as they might not support add-on storeys; unless this is done, the whole building may risk collapse. This first part of the change process is usually the most difficult and stressful. When you start cutting down the "way things are done", you put everyone and everything off balance. You may evoke strong reactions in people, and that's exactly what needs to done. By forcing the organization to re-examine its core, you effectively create a (controlled) crisis, which in turn can build a strong motivation to seek out a new equilibrium. Without this motivation, you won't get the buy-in and participation necessary to effect any meaningful change.

Change After the uncertainty created in the unfreeze stage, the change stage is where people begin to resolve their uncertainty and look for new ways to do things. People start to believe and act in ways that support the new direction. The transition from unfreeze to change does not happen overnight: People take time to embrace the new direction and participate proactively in the change. A related change model, the Change Curve , focuses on the specific issue of personal transitions in a changing environment and is useful for understanding this specific aspect in more detail. In order to accept the change and contribute to making the change successful, people need to understand how the changes will benefit them. Not everyone will fall in line just because the change is necessary and will benefit the company. This is a common assumption and pitfall that should be avoided.

Tip:

Unfortunately, some people will genuinely be harmed by change, particularly those who benefit strongly from the status quo. Others may take a long time to recognize the benefits that change brings. You need to foresee and manage these situations. Time and communication are the two keys to success for the changes to occur. People need time to understand the changes and they also need to feel highly connected to the organization throughout the transition period. When you are managing change, this can require a great deal of time and effort and hands-on management is usually the best approach.

Refreeze When the changes are taking shape and people have embraced the new ways of working, the organization is ready to refreeze. The outward signs of the refreeze are a stable organization chart, consistent job descriptions, and so on. The refreeze stage also needs to help people and the organization internalize or institutionalize the changes. This means making sure that the changes are used all the time; and that they are incorporated into everyday business. With a new sense of stability, employees feel confident and comfortable with the new ways of working. The rationale for creating a new sense of stability in our every changing world is often questioned. Even though change is a constant in many organizations, this refreezing stage is still important. Without it, employees get caught in a transition trap where they aren't sure how things should be done, so nothing ever gets done to full capacity. In the absence of a new frozen state, it is very difficult to tackle the next change initiative effectively. How do you go about convincing people that something needs changing if you haven't allowed the most recent changes to sink in? Change will be perceived as change for change's sake, and the motivation required to implement new changes simply won't be there. As part of the Refreezing process, make sure that you celebrate the success of the change – this helps people to find closure, thanks them for enduring a painful time, and helps them believe that future change will be successful.

Practical Steps for Using the Framework: Unfreeze 1. Determine what needs to change. • Survey the organization to understand the current state. • Understand why change has to take place. 2. Ensure there is strong support from upper management.

• Use Stakeholder Analysis and Stakeholder Management to identify and win the support of key people within the organization. • Frame the issue as one of organization-wide importance. 3. Create the need for change. • Create a compelling message as to why change has to occur. • Use your vision and strategy as supporting evidence. • Communicate the vision in terms of the change required. • Emphasize the "why". 4. Manage and understand the doubts and concerns. • Remain open to employee concerns and address in terms of the need to change.

Change 1. Communicate often. • Do so throughout the planning and implementation of the changes. • Describe the benefits. • Explain exactly the how the changes will effect everyone. • Prepare everyone for what is coming. 2. Dispel rumors. • Answer questions openly and honestly. • Deal with problems immediately. • Relate the need for change back to operational necessities. 3. Empower action. • Provide lots of opportunity for employee involvement. • Have line managers provide day-to-day direction. 4. Involve people in the process. • Generate short-term wins to reinforce the change. • Negotiate with external stakeholders as necessary (such as employee organizations).

Refreeze 1. Anchor the changes into the culture. • Identity what supports the change. • Identify barriers to sustaining change. 2. Develop ways to sustain the change. • Ensure leadership support. • Create a reward system. • Establish feedback systems. • Adapt the organizational structure as necessary.

3. Provide support and training. • Keep everyone informed and supported. 4. Celebrate success!

Key Points Lewin's change model is a simple and easy-to-understand framework for managing change. By recognizing these three distinct stages of change, you can plan to implement the change required. You start by creating the motivation to change (unfreeze). You move through the change process by promoting effective communications and empowering people to embrace new ways of working (change). And the process ends when you return the organization to a sense of stability (refreeze), which is so necessary for creating the confidence from which to embark on the next, inevitable change.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Hi benlouie1, Another tool that I think you will appreciate is this one on coaching though change: http://www.mindtools.com/community/ pages/article/newTMM_19.php it provides a great outline for helping people work though their emotions nd overcome some of the natural resistance to change. As leaders it's important to be aware of how difficult it is to change so being aware and having tools to help people through the process is invaluable. Hope you enjoy it. Keep us posted on other tools you find particularly helpful. It helps us all learn. Best! Dianna April 18, 2013 ChaiLatte wrote Thank you for making the Lewin Change Management Model to be so easily understood. This knowledge is so useful for leaders to put theory into practice by implementing a logical and rational communication flow. "Change" is not operating in the dark anymore, it should be transparent and accessible to the information seekers. Best regards. April 16, 2013 Yolande wrote Hi garyb121 Welcome to the Club and welcome to the forums too. It's great to see you around and would love to hear some more of your thoughts, ideas and challenges. Career Cafe Central is the forum where we do most of our 'talking' and we look forward to 'seeing' you there. The other day I was doing research for a course on change management and happened upon a short video clip (2 minutes) on Youtube about the Lewin Change Management Model. It is a little simplistic, but nonetheless gives a good example of this model at work. The link is as follows (just add the www bit) youtube.com/watch?v=uHR8gw6derg . garyb121, please let me know if you need any help around here, I'll be only too glad to assist you.

Kind regards Yolandé May 2, 2012 garyb121 wrote Hi, Thanks for the topic. It is really helpful! Anyway, do you have any real example for Lewin Change Management Model? Thanks! May 2, 2012 bigk wrote Hi James This is a good resource to use as a source for development of change. I have not looked recently but did look not too long ago. This is a useful reminder to evaluate and reuse it to consider different ways to provide or help any adapting or utilising to create a flow of change or even a small change. It can help people use change to help get better options and outcomes. It can help people with confidence to adapt. It can help people achieve. Bigk February 4, 2010

Return to top of the page

Logframes and the Logical Framework Approach Planning Robust, Coherent, Successful Projects In practice, even the best project managers can find it difficult to plan major projects without missing important activities, and without failing to spot all significant risks and issues. What's more, once you're immersed in the detail of project planning, it's hard to keep site of the big picture: © iStockphoto What are you trying to achieve and why? What are the risks and assumptions? And how you can tell whether the project is a success once it's implemented? The Logical Framework Approach is a useful technique for helping you do these things, thereby making your projects more robust and coherent – and more successful. The Logical Framework Approach (LFA) was developed in the 1970s as a tool for strategic planning, using the ideas of Management by Objectives . It's a tool of choice used by development agencies and in the international donor community. Large aid organizations throughout the world use the LFA for planning, approving, evaluating and monitoring their projects. That said, this is a powerful and useful technique, and is one that richly deserves much wider application than in international development alone.

The Logical Framework Approach and the Logframe The Logical Framework Approach elegantly weaves together top-down and bottom-up approaches to project management. It brings together the classical, top-down, "waterfall approach" for identifying the activities in a project, with a rigorous bottom-up checking process to make sure that these activity lists are comprehensive. It then reinforces this with a rigorous risks and assumptions analysis, which is again thoroughly checked. And it concludes by identifying the controls needed to monitor and manage the project through to successful conclusion. It does this within the framework of the Logframe Matrix, shown in figure 1 below. This cross-references seven key areas of the project to ensure that the key questions are asked: • Goal – what results do we expect? • Purpose – why are we doing this?

• Outputs – what are the deliverables? • Activities – what will we do to deliver the outputs? • Indicators of Achievement – how will we know we've been successful? • Means of Verification – how will we check our reported results? • Risks and Assumptions – what assumptions underlie the structure of our project and what is the risk they will not prevail? The answers to these questions are put into a Logical Framework Matrix (Logframe) and become the output of the Logical Framework Analysis exercise. The Logframe is a four by four matrix, shown below: Figure 1: The Logframe Matrix

Logframe Matrix Project Summary

Indicators of Achievement

Means of Verification

Important Risks and Assumptions

Goal: Purpose: Outputs: Activities: The process has significant value for any size of project. It helps identify the big picture and allows you to see how other items cascade down from it. As well, it helps flesh out the core assumptions that are used in the project development process.

Using a Logframe Carry out the following steps in consultation with your stakeholders , after you've completed a thorough analysis of the situation. By involving stakeholders, you'll end up with a much more robust analysis of the project than you would on your own.

Step 1: Identifying Outputs and Activities (Project Summary, Column 1) The first step is to brainstorm the outputs and activities required by the project, starting with the project goal. Do this in the Project Summary column (column 1) of the Logframe. Start by defining the Goal and Purpose of the project and, from these, identify the outputs and the activities required: • Goal: What is the "to be" state of the project? What are you trying to achieve?

• Purpose: What good will you do by achieving the goal? Who are the beneficiaries? What is the underlying motivation for starting the project in the first place? • Outputs: What specific things will be delivered as a result of this project? In order for the project to be considered a success, what changes must be made, and what will the result be? • Activities: What will actually be done in order to deliver the intended outputs? The Logframe is not intended as an implementation guide, so this section is typically presented in bullet point form. Tip:

Don't underestimate the amount of time and work needed to complete this process properly! Manage people's expectations on this, and keep them focused on the task in hand. If people lose focus, you'll miss important activities, false assumptions, and risks.

Step 2: Verify the Vertical Logic Next, we take a bottom-up approach to checking that this list of activities will deliver the desired results – after all, it's possible that activities have been missed, or that the actual results of these activities may not be the ones wanted. This checking process is an important part of making sure that your project plan is robust. Column one shows a hierarchy of objectives, so it is important to check that actions identified deliver the results wanted. Check the logic in column one by using an if/then test as follows. Starting with your activities, ensure that: • IF you complete the activity, THEN the outputs will occur. You want to make sure your activities and outputs are directly linked. • IF your outputs are achieved, THEN the purpose of your project will be satisfied. Are the planned outputs closely tied to your purpose? Make sure the beneficiaries you identified in your purpose actually receive the beneficial outcome desired. • IF your purpose is satisfied, THEN the goal of the project is achieved. Examine your purpose and goal to make sure that the purpose fully incorporates the intent within the goal. If, in this step, you find that activities and outputs are missing or are wrong, add or adjust them appropriately. And bear in mind that if you identify issues with elements higher up in this hierarchy, you'll need to go back to Step 1 and identify appropriate outcomes and activities for those elements.

Step 3: Identify the Risks and Assumptions of your plan (Column 4) We now cross over to the other side of the Logframe to identify risks associated with the project, and possible false assumptions that may undermine it.

There are any number of external factors that can throw projects off course. In the planning and design phase, it is prudent to identify the major assumptions you've used and the degree or risk associated with them. For each of the points in the project's structure (Column 1), identify the assumptions you're making (which may or may not be correct), and look at the associated risks. To define your assumptions, ask "What actions or variables must exist for the project to start and proceed as planned?" Start at the bottom and work up. • Activity Assumptions: What do you need to happen for your activities to be completed successfully? And what conditions and resources are you assuming will be in place? • Output Assumptions: What factors outside of your control must be present to achieve the outputs you need? • Purpose Assumptions: To achieve the purpose, what external factors do you need to have in place? • Goal Assumptions: What are the necessary conditions for longterm viability of the project goal? Clarify these assumptions with stakeholders immediately, if you can. If you can't, make sure you have early activities in place within your project plan to confirm that your assumptions are correct. Next, repeat this process looking at risks (see our article on Risk Analysis .) Make sure you plan in all of the activities needed to manage or eliminate risk, and if risk can neither be managed or eliminated, make sure that it's clearly identified so that it can be evaluated in the next step.

Step 4: Verify the Logic of the Risks and Assumptions Once you have identified assumptions and risks, you need to check them to determine: • Whether your assumptions will link one level of the project to the next; and • Whether risks are too large. First of all, check that your assumptions are logical using an if/and/ then analysis. Start at the bottom and work up to ensure: • IF the activity is completed successfully, AND the assumptions underlying it are true, THEN the output will be delivered. • IF the output is delivered, AND the assumptions underlying it are true, THEN the purpose will be achieved. • IF the purpose is achieved, AND the assumptions underlying it are true, THEN the goal will be achieved. Then, check some additional points related to your risk and assumption analysis: • Make sure you have identified as many assumptions and risks as possible. Have you talked to everyone involved? Have you looked at the project from all angles?

• Make sure your assumptions are stated specifically and are not too vague. You can't assess risk accurately if you are working with generalities. • Do you have plans at each level to manage the risks you have identified? • If the risks you're not able to manage are too high, consider redesigning the project or, if you still can't reduce these to sensible levels, reconsider the project's viability. Again, where this process exposes issues with your Logframe, update it appropriately.

Step 5: Determine the Indicators of Achievement and Means of Verification When you are satisfied with the structure of the Logframe so far, and are comfortable that you can manage the risks related to your assumptions, you can move on to think about how you will monitor progress towards success. Performance indicators are the specific measures used to monitor this progress. Here are the criteria for a good indicator of achievement: • Valid – it must measure the intended result. • Reliable – the measure must be consistently attained over time. • Sensitive – the measure should respond to changes, and should sufficiently-quickly identify if things are going wrong. • Simple – the measure should be easy to collect or perform. • Useful – it must help with decision making or provide information for future learning. • Affordable – you need to be able to afford the financial and time costs involved in taking the measurement on a regular basis. Using these criteria, for each goal, purpose, output and activity, indicate what will be used to determine whether it was successfully achieved. Also note who will be responsible for setting these targets. Then indicate exactly how you will verify that achievement. What sources of data will you use? How will you collect the data? How often? Make sure that appropriate activities are in place within your plan to set up and manage these monitoring systems. Click here for an example Logframe.

Key Points The Logical Framework Approach is a great technique for making sure that your project plan is robust and coherent. By using it, you significantly increase the likelihood that your project will be successful. Firstly, it provides a useful framework for working through the design of your project with key stakeholders, making sure that you

can take full advantage of their knowledge, insights and experience. Secondly, it provides a useful process for testing and checking your project plan, making sure that it contains all the necessary activities, is based on sound assumptions, and fairly weighs and manages the risks inherent within the project. Thirdly, it helps you ensure that appropriate control measures are embedded within the project, meaning that you can quickly identify where things are going wrong, and take appropriate corrective action.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote Hi positivelykah and jkeyzer, Welcome to the Club and thanks for sharing your experiences with using logframes and the LFA. It has reminded me to take another look at it, as I am just reviewing my business plan and objectives for my business, and this will help me keep the work aligned with my overall objectives!!

Hope to see more of your insights and thoughts around the Cafe with other discussions. If there is anything I can help you with, just let me know. Midgie August 6, 2012 jkeyzer wrote Hello! Another context for the Logframes and Logical Framewok Approach is: Results Based Management. The canadian development agency CIDA is using this. Here you can find further info: www.acdi-cida.gc.ca/rbm I think the reason why LFA is mainly used in development is because it is a great tool for managing projects that aim at social change. There it is very difficult to determine causality: does a certain action or result lead to the desired change? In other words: the proverbial horse that you can lead to the well, but you can't make it drink. In IT the result is much more tangible and logical: if you programme an upload function, the result is that you can upload stuff, no surprises there. So than a work breakdown tool, dividing programmes into functionalites, etc. would be much more appropriate. Another reason for using LFA in development projects is for evaluation purposes. By building in indicators of the desired results at programme design stage, you can evaluate much easier at the end. In IT at the end you test, which tells you whether the functionality works. The tests normally lead to the results that the functional design prescribed, again no surprises there. August 4, 2012 positivelykah wrote One of the key elements of the LFA process is the facilitation of stakeholders to create the LogFrame. Having conducted over 40 LFAs for both profit and non-profit, the process must have integrity in facilitation in order to produce valid results that can then be pushed into a project framework. The logframe is a tool/document as an output to the LFA process of stakeholder facilitation. It is an excellent way to ensure that a project is working on solving a core problem, which in it's positive form is the purpose, rather than addressing symptoms - which are poorly aligned objectives. This is one of my favorite problem analysis and strategic tools that I use in my personal and professional life. August 3, 2012

cosborn wrote Thanks for the responce. I was mainly curious about level of detail and how some might represent multiple outputs. At some point a large prorgram would need to have work breakout structures in support of the outputs. So I am thinking through how much activity to represent. I am responsible for IT projects so I will work a couple through. For example: Enabling the workforce with Instant Messaging as a real time collaboration tool. or Defining what parts of unified communication we need to deploy in 2010 to increase employee productifity. So any examples of real world proejcts would be a good reference. October 15, 2009 bigk wrote Hi There are a few pdf samples but these are mostly descriptions of the technique. What kind of excel sample do you need..? or is it just the table headings and text for a table layout you want a sample of? If you took the headings created, the text could just be created as a table in excel or word and then auto format the text and the borders. The file created can be updated with each of the cells (fields) you want to include adjusted by using the text content as a guide. Or use the cells, adding a border around 5 rows (example only) (add whatever amount of cells), use the cells to add text content. Bigk October 15, 2009 cosborn wrote I have been reading through the LogFrame article and really like the concept. I have been searching the endless web for sample excel or word documents I could use as a template. Does anyone have other good research on the topic or templates? Thanks October 14, 2009

Adele wrote Must be something about those of us who work for development organisations (mine is in New Zealand) I too think logframes are a great tool for planning and evaluating projects - This article is one of the clearest explanations and instruction sets that I have come across for working with logical frameworks. Thanks Mind Tools for another great resource! (now I just need to complete the time management audit so I can find time to register for the mentor network..........) February 7, 2008 purpleNEW wrote Hi everyone I work for a development organization (specialising in Eastern Europe) and I was so pleased to see you covering logframes. I quite agree that they're a great tool and I don't see why no one outside my industry seems much interested in them. Some people don't like them, but I love them and including a logframe is mandatory for DfID submissions. Best Paul June 20, 2007

Return to top of the page

Managing Project Finances Understanding and Controlling Project Costs A well-managed project is completed on time, on spec, and on budget. It's generally the case that cost is one of the major factors in determining the success of a project – and no one wants to be responsible for a cost overrun. With that in mind, how do you make sure that you keep 'on budget' with your project?

Control your costs to stay within budget. © iStockphoto/peepo

The simple answer is 'control'. If you're going to have any chance of staying within budget then you need to manage the project costs proactively and systematically. Thankfully, there are many tools and ideas that can give you this control. Project cost management includes three basic processes: 1. Cost estimating – Making your best assessment of the costs of the resources needed to complete a project. 2. Cost budgeting – Assigning cost estimates to individual work items, and establishing a baseline for measuring performance. 3. Cost control – Controlling changes to the project budget. By managing these processes, and their inputs and outputs, you can develop an effective system to ensure that your resource costs remain within the approved budget. In short, project cost management is the process of doing the following: • Communicating budget limits to project designers, and to the people who are implementing the project. • Collecting actual cost data. • Comparing actual costs to the original budget. • Taking corrective action as needed. Let's look at the three project cost management processes in turn.

1. Cost Estimating Estimating is a critical part of managing project finances. Estimates are used for all sorts of activities, including budgeting, forecasting, resource planning, and staffing. It's important that you estimate the costs for all resources that will be charged to the project – including items such as labor, materials, and supplies – as well as any contingency costs. A cost estimate is an assessment of how much it will cost for all resources necessary to complete project activities. It's also a good

idea to identify and consider cost alternatives, and include these in the estimate. To determine which costs to estimate, you can use a variety of inputs, the most of common of which is the work breakdown structure (WBS). This is a detailed list of all the things that need to be delivered, and the activities that need to be carried out to complete the project. The project scope statement also has information related to resource requirements, restrictions, and assumptions – which can help you identify cost alternatives, if appropriate. To complete your estimates, there are a variety of tools and techniques you can use: • Analogous estimating – Use data from previous projects to build an estimate of costs for the current project. This can help if you have limited information or detail on your current costs. For example, look at similar, or analogous, items in the previous project, add 5% for inflation, and you may have a reasonable estimate. • Resource cost rates – Establish unit costs for hours and materials by using the various quotes and planning documents you've received. For example, if labor costs for a construction project are an average of $12 per hour, and you need 10 people to work 160 hours each, the labor cost estimate is $19,200. Add the costs of materials, and you have an estimate for the total construction. • Bottom-up estimating – Use the smallest work component in the work breakdown structure, and estimate the cost of each. Then combine these, as you move up the levels, to determine an overall cost estimate. For our construction example, you need to build walls, add plumbing and electrical, add doors and windows, finish floors, and paint. Estimate the cost of each of those items, and add them together. • Parametric estimating – Use the statistical relationship between cost and some other characteristic of the item being estimated. Square footage of a building or the number of words written per page – these are examples of elements used to create a cost estimate. If our construction project is 800 square feet, and it costs about $60 per square foot to build and finish office space, then the total estimate is $48,000. • Computer software – Many project management programs can calculate estimates for you using statistics or simulations. Once you've determined your cost estimate, make sure you record the information, and document your estimation process. When providing supporting detail, you may need to include the following: • A description of the activity. • Documentation of your methods and calculations. • A list of assumptions made, and restrictions applied. • A typical range for a reasonable margin of error in your estimate.

2. Cost Budgeting Once you have put together your activity cost estimates, you can now prepare a budget. This is the document that can help you get the

funds you need to complete the project. You'll probably have to stay within your original budget, so it's best to build in an adequate reserve – a little extra – for unexpected expenses. What you are looking to create through the budgeting process is a cost baseline. This represents the approved budget, and is used to compare and contrast with the actual project costs over time. The cost baseline serves as confirmation of what the project's cost structure looked like when the project was originally approved. Using the baseline, you can determine if cost performance to date is within acceptable parameters. As the project progresses, costs are monitored against the baseline, and any changes are expressed relative to the baseline. The baseline serves as a primary metric for evaluating performance, so it remains stable, and changes are reflected relative to it. It's important to keep a good balance here. If you budget too high, you may not succeed in securing funding for your project. If you budget too low, it may be impossible to stay within those costs, and you'll risk a poor outcome. The following tools will help you prepare a reasonable budget for your project: • Cost aggregation – Aggregate, or add up, the figures in your activity cost estimates to determine an overall budget amount. For example, to build a fully operational help desk, add the estimated costs of renting the space, hiring and training the support desk staff, and purchasing and installing the equipment. • Reserve analysis – Build in a contingency budget – some extra funds – in addition to the estimates for the actual activity costs. This reserve account will help you deal with unplanned changes and unexpected expenses that may be necessary at some point during the project. • Parametric estimating – Use predetermined parameters to add budget amounts for elements of the plan that aren't part of the activity estimates. For example, historical data may tell you that the average project in your organization runs 4% over budget. If you add an extra 4%, you'll probably improve the accuracy of your total budget. • Funding limit reconciliation – When preparing your budget, be aware of the expected cash flow. You probably won't be given all of the money up front, to be spent whenever and however you want. It's more likely that you'll be expected to spread your total budget over the duration of the project. This means that you need to consider cash flow, and possibly adjust the project schedule accordingly. A well-planned budget looks at how and when work is done, not just the total costs. Project managers use funding limit reconciliation to avoid large variations in the periodic expenditure of project funds. They do this by reconciling project expenditures with the funding limits set by the customer. Reconciliation may require the revision of project schedules to regulate expenditures; this in turn affects the allocation of resources. Bear in mind that the overall budget not only sets a cost baseline for the project, it also establishes a funding schedule. Remember to

include reserve amounts in each funding increment, because requests for changes – and unexpected expenses – will almost certainly arise.

3. Cost Control People may come to you and ask for changes to be made, or for extra features to be added to the project. If you agree to those changes because they're nice to have, rather than because they were overlooked in the original scoping of the project, then you will quickly go over budget. Change requests are one reason why cost control is so important, but there are many other activities that are part of controlling costs. These include monitoring actual expenditures, and analyzing the variances between budget and actual costs. It is therefore important to create and establish an effective control system, so you can respond to changes appropriately, and communicate cost changes in a timely manner. Key elements of cost control include the following: • Change control – This is a process that describes how changes to the baseline costs can be suggested and implemented. It outlines procedures that people have to use if they want to request changes. This includes what paperwork they need to complete, how changes requests are tracked, and what approval process they can expect. Without a clear change process, people often keep asking for more and more from the project. If you have no structured way of dealing with these requests, your costs will quickly go over budget. Do bear in mind that project cost management isn't just about numbers; it's also about managing project scope , and dealing with people. Learn to be firm, and recognize which changes are really necessary. • Performance measurement analysis – This activity is all about the numbers. You assess the significance of the variances from the budget baseline, as well as the cause, and the corrective action that is needed. The Project Management Institute recommends the earned value technique (EVT), which is described in the PMBOK (Project Management Body of Knowledge). There are a variety of calculations you can use: 1. Planned Value (PV) = Budgeted cost for the work scheduled for an activity or component of the Work Breakdown Structure. 2. Earned Value (EV) = Budgeted amount for the work actually completed on an activity or component of the Work Breakdown Structure. 3. Actual Cost (AC) = Total cost incurred to accomplish the work completed on an activity or component of the Work Breakdown Structure. 4. Cost Variance = EV - AC 5. Schedule Variance = EV - PV 6. Cost Performance Index (CPI) = EV / AC (a CPI less than 1 indicates a cost overrun).

7. Schedule Performance Index (SPI) = EV / PV (an SPI equal to or greater than 1 indicates the project is in a favorable condition. For example, the budgeted cost (planned value) for a project at the end of month 5 is $40,000. The budgeted amount for the work completed (earned value) is only $35,000. However, the actual costs incurred to date are $38,000. Consider the following calculations: 1. Cost variance = EV - AC = $35,000 - $38,000 = -$3,000 2. Schedule variance = EV - PV = $35,000 - $40,000 = $5,000 3. Cost performance index = EV / AC = $35,000 / $38,000 = 0.92 (there is a cost overrun). 4. Schedule performance index (SPI) = EV / PV = $35,000 / $40,000 = 0.875 (the project is behind schedule). • Forecasting – This involves predicting the project's future based on the performance to date. Completing forecasts periodically over the course of a project will help you to do this. Forecasts provide valuable information to help you deal proactively with variances. For example, a forecast can help you estimate that your project will be 10% over budget, so you can make plans accordingly. • Estimate to complete – You can estimated the cost to complete the project based on what has been completed so far, compared with your budget at completion. To calculate the estimate to complete (ETC), use either of these formulas (BAC means Budget At Completion and is equal to the Planned Value at completion):When current variances are seen as atypical and not expected to occur in the future use: ETC = BAC – EV When current variances are seen as typical of future variances use: ETC = (BAC – EV) / CPI In our example, if the total project budget is $60,000, and variances are seen as typical the calculation would be as follows: ETC = ($60,000 – $35,000) / 0.92 = $27,174 You need $27,174 to complete the work remaining. • Estimated actual cost – This is a forecast of the most likely total value of the completed project. The most basic formula, which assumes cost variances to date were atypical, for estimated actual cost (EAC) is: EAC = AC + BAC – EV In our example, this is calculated as follows: EAC = $38,000 + $60,000 – $35,000 = $63,000 If cost variances to date are typical, though, use: EAC = AC + ETC In our example, this is calculated as follows:

EAC = $38,000 + $27,174 = $65,174 • Project Performance Reviews – These compare cost performance over time, as well as against milestones. Some techniques are variance analysis, trend analysis, and earned value (described above). All of these analyses are typically included as regular updates in project reporting, as well as in project completion documents. Cost control is very useful for future project planning, so the more complete your analysis is before you start, the better your project planning can be in the future.

Key Points Project cost management helps you make sure that your project is completed within the approved budget. It includes the processes of cost estimation, cost budgeting, and cost control. Many of the project planning activities are used as key inputs to financial management. Managing a project's finances is an extremely important part of overall project management. Cost is a key measure of project success, so be aware of your actual costs compared with the budget. The quicker you recognize variances, the better you'll be able to make the necessary adjustments.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote That's a great system you outline Iman - simplicity and ease of use are definitely factors for success in many cases. And allowing team members to access the information is an especially important feature. Because project finances are so important to success it's well worth the time to create a system for tracking and managing that you can and WILL use as a team. Thanks for the great tips! Dianna April 5, 2010 iman wrote Hi there, Needless to say that projects are targeting to met expection on other hand they also need to maintain their cost in control, many financial institution and accountant try to use many dashboards to monitor actual with forecast, it could be difficult and time consuming many time is oversight because it really play a hidden factor in delivering the projects, as you see thing can be good for you, but , paretically saying all teams can develop their own KPI's to achieve their financial targets, that is simple, 1. know how much you should use for specific project. 2. How much you make out of this project, 3. Included in your table, linked with some is used to dispose the funds, petty cash, check book and so on. 4. see how frequent you need to see it, fix a date to review like a weekend, but make sure your report it at specific date too, like start of week day, this enable team member to be aware of what is going on with budget, advantag the improving will come along with data display to team, is usually revolve the more you use it more enhancement will be done on to it, the secret make as simple as possible and informative as possible be open to you team member never take it personally this you will get better. best of lack Iman April 4, 2010 Dianna wrote Hi Rachelle, Have you had any success with this? I'm thinking that this might be a great stepping-off point to bring the accounting and order

mgmt systems in-line with one another. I can foresee a lot of organizational benefits to this so maybe it's something worth investigating fully. These types of improvement suggestions also go a long way toward building your reputation within an organization and showing your commitment to quality and continuous improvement. Food for thought anyway... Dianna March 11, 2009 MissRocky wrote I want to know if anyone has a excel file in which they use to help track project finances from the field side? My project management team needs some serious help and our accounting and order management systems don't speak the same languages so its not as easy as could be. February 19, 2009 caz66 wrote I work in a programme office, and have responsibility for finance reports on all our projects, and this is a really good round up of the various issues. One big problem with MONITORING our finances is that we have a fairly complicated and bespoke system where all budgets must be entered - yet we also have a large number of project managers who are contractors and therefore not motivated to get to grips with the wretched system and enter their figures. I imagine this is fairly common in project-based organisations, but I bet whoever commissioned the system did think of that! Caro February 18, 2009

Return to top of the page

Managing Project Uncertainty Planning for the Unknown Most projects have an element of uncertainty to them. In many cases, you can use well-established risk management practices to deal with this. However, for cutting-edge projects, or for ones that must adapt to constantly changing conditions, you may not be able to foresee all risks when you start out.

Some projects are full of uncertainties. © iStockphoto/Sashkinw

In these situations, you can manage uncertainty instead of trying to manage risk. In this article, we'll outline four common types of uncertainty that you can face as a project manager, and we'll explore strategies that you can use to deal with them.

The Four Types of Uncertainty Professors Arnoud De Meyer, Christoph Loch, and Michael Pich analyzed projects across a wide range of industries, and, from their research, identified four major types of uncertainty. They set out their findings in the MIT Sloan Management Review in 2002. Their four types of uncertainty are: • Variation. • Foreseen uncertainty. • Unforeseen uncertainty. • Chaos.

Managing the Four Types of Uncertainty We look at each type of uncertainty in more detail below. We'll also suggest strategies that you can use to manage each one.

1. Variation Variation refers to a small degree of change in a project schedule. For example, you may need to manage short delays if team members are sick, or if you need to prepare additional documents for stakeholders. Individually, these issues have a minimal impact on the overall project. However, if there are many of them, they can lead to longer delays and added costs.

Managing Variation

You don't need to anticipate every kind of variation that might affect your project. Instead, plan for small amounts of it when you create project schedules. Divide your project into phases, and then build contingency buffers into each phase. Only use these buffers if you really need to, and don't bargain them away. Make sure that you've established procedures to monitor progress, and that your people know that they can discuss the impact of small changes with you. (If there are many changes, and these start to affect the project schedule, you'll need a formal scope control process to manage the impact on the project schedule.) Finally, determine the point at which you'll take corrective action. For example, are you comfortable if the project falls two days behind schedule? What about a week or a month behind schedule?

2. Foreseen Uncertainty Foreseen uncertainties are those that you can identify and prepare for. Unlike the small changes brought about by variation, foreseen uncertainties are larger events that may need risk management and contingency planning. Managing Foreseen Uncertainty

First, conduct a risk analysis to get an idea of the uncertainties that you could face. Next, prioritize these risks with a risk impact/ probability chart , and develop contingency plans to deal with them. Set aside time to monitor your foreseen uncertainties regularly, and to communicate how you'll handle them with your team and key stakeholders. Tip:

As with variation, if scope creep is a foreseen uncertainty in your project, practice careful scope control . This will help you keep your project's timeline and budget within the bounds that you agreed with your project sponsor.

3. Unforeseen Uncertainty Unforeseen uncertainties are events that you can't anticipate, or that you consider to be so unlikely that you don't need to create a contingency plan to address them. These kinds of uncertainties are common in technology projects, or in those that focus on uncertain markets. Unknown uncertainties – also called "unknown unknowns" – are also often caused by the knock-on effects of known risks. This "risklayered-upon-risk" can be very hard to predict.

Managing Unforeseen Uncertainty

Instead of trying to anticipate unknown uncertainties, view them as problems to solve as they arise. Open communication is essential in this situation. Meet with your team members regularly to discuss the changes, threats, or opportunities that they've noticed. Encourage everyone to be open about any problems they've spotted, and to come up with solutions. Stakeholder management is also important in these situations, because you will have to convince key stakeholders to accept unanticipated project changes. So, work on building trust with everyone involved in the project – this will make it easier for you to work together when unanticipated changes arise.

4. Chaos Sometimes, you can't clarify plans at the outset of a project, perhaps because the market is changing rapidly. In fact, you may find that the expectations you had at the start of the project change completely as work progresses. De Meyer, Loch, and Pich described this kind of situation as "chaos." This term has negative connotations, but, in this context, it simply means that you can't make reliable plans up-front. This shouldn't stop you going ahead, however – it just means that you should adjust your approach appropriately. Managing Chaos

The constant change of chaos-prone projects means that your team must stay flexible, as a fearful, over-rigid approach could stall the project. Make sure that your team understands this from the start. Agile project management is well suited to this kind of project. It allows team members to respond to market changes or evolving technological situations, and to factor them into ongoing development. Your team must be willing to try different approaches as your understanding develops. Encourage them to come up with new ideas , and build opportunities to discuss these into the schedule. Learn how to make confident go/no-go decisions at the end of each stage or sprint. If the project will no longer deliver appropriate benefits, you may need to discuss whether you should cancel it. Above all, focus on what you and your team can learn as the project develops: this will be a powerful motivator.

Key Points Every project comes with a certain amount of risk. However, it can be difficult – or even impossible – to anticipate and plan for all types of risk, especially when projects are fast-paced or complex. In these situations, it may be more practical to identify and plan for specific types of uncertainty.

Researchers Arnoud De Meyer, Christoph Loch, and Michael Pich identified four types of uncertainty. These are: • Variation. • Foreseen uncertainty. • Unforeseen uncertainty. • Chaos. You'll need to respond to each type of uncertainty differently depending on the costs involved, and the extent to which you can predict the event happening. Adopt an appropriate management approach, and encourage your people to be flexible, to share solutions to problems, and to see uncertainty as an opportunity for development.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote This is a great article because in today's world, there is indeed so much uncertainty that we have to deal with. This article outlines the four types of uncertainty and proposes tools to deal with it more effectively!

I'm curious, how do you tend to deal with uncertainty in your professional and personal life, and what sorts of strategies do you use to handle things when they do arise? Midgie September 5, 2013

Return to top of the page

Overcoming Cultural Barriers to Change Moving to a High Performance Culture How does your organization approach change? Do people respond with a sharp intake of breath when they first hear about a proposed new initiative, and then go on to try and find reasons why it won't work? Or do they react by saying things like "What a great idea, and we could also.." In other words, is your corporate culture against or for change?

How will you get round the barriers? © iStockphoto/Inok

Corporate culture is a powerful force that runs through every organization. It is defined as the attitudes, experiences, beliefs, and values that operate within an organization. And these undercurrents define people's behavior, and how a company gets things done, in either positive or negative ways. When successful change is the desired outcome, these cultural factors play a very important role. If an organization has had a negative experience of change in the past, then change will be that much more difficult the next time around. Likewise, if the prevailing attitude is represented by the saying, "If it ain't broke, don't fix it", then making any kind of change will be met with that much more resistance. Effecting change is difficult at the best of times. When you encounter resistance due to cultural elements, it can be even more frustrating. This is because the very elements of corporate culture are so difficult to see and pinpoint. It is worth remembering here that while culture issues can present barriers to change, they can also support change and goal achievement. To overcome cultural barriers the best way to start is to look at the characteristics of a high performance culture. Once you know what you "should" be doing or promoting, it is easier to make a plan to revamp your current situation. There is no such thing as a perfect culture. An organization's culture is unique and special and it evolves from all the experiences, growth, and development that have already occurred. So while there is no ideal to aspire to, what you do want to do is set in place characteristics that will help your organization adapt to whatever comes its way. There's a saying that "the only constant is

change" which has some truth to it, so every organization needs to encourage values, beliefs, and structures that support change.

The Characteristics of High-Performance Cultures By definition, one of the main differences between high-performance cultures and low-performance ones is their ability to adapt and change. In general terms, a low-performance organization is one in which there are many barriers to change. When organizations are able to embrace change and easily implement systems to support it, they tend to be more successful. The following chart lists cultural characteristics the support and obstruct change. Is your organization more on the left or right hand side of the chart? Cultural Barriers to Change

Cultural Supports for Change

Fear and distrust – thinking that everyone is out for themselves

Trust in the company and the people that work there

Concern with short-term profits and the bottom line

Long-term business focus

Hierarchical structure with topdown decision making

Employee empowerment to make decisions

Looking for blame and fault, people shirk responsibility

Personal accountability and responsibility

Poor communication – the "messenger is shot", information is hidden, employees are uninformed and skeptical

Open and honest communication – information is sought after

Preference for the status quo, believes what is currently being done is the right thing to do

Openness to new ideas and ways of doing things

Failure is covered up

Failure triggers investigation and analysis

Crushing of new ideas, with criticism given with intent to find fault

Promotion of innovation and creativity

Cultural Barriers to Change

Cultural Supports for Change

"Us versus Them" mentality, turf wars between departments or business units

Cross functional teams

Top management talks a big game but doesn't do much themselves

Top management that leads by example

Enforcement of very rigid policies and rules that don't allow for much judgment

Flexibility of rules, processes, and procedures that can be adapted to suit the situation

Negative attitude – start by looking at all the things that will go wrong

Positive attitude – start believing success will be achieved

If your organization is parked on the left side of the chart, there's no time like the present to address these cultural issues. Not only will these issues hamper your attempts to change, they may cause inefficiencies, discord and disconnection between employees, departments, managers and customers.

Overcoming Cultural Barriers The nature of the cultural barriers your organization faces will be unique to your organization. Nonetheless, there are some principles that you can apply right now that will help you as you move your culture from low-performance characteristics to high-performance ones.

What Gets Rewarded, Gets Done Reward and recognition programs are highly effective means to motivate and reinforce change. When culture has to change, you need to get creative and identify specific behaviors or outcomes that represent the cultural elements you want to promote. If you have a culture that prefers the status quo, then you might consider setting up an improvement program where people are rewarded for the improvements they suggest. At the same time, analyze your existing reward programs to ensure that you aren't inadvertently rewarding the behavior you want to eliminate. If you are currently recognizing people for adhering to policies and procedures, are you at the same time discouraging new ideas and turning out robots?

Tip:

Remember that rewards don't need to be financial. Most people respond well to recognition for good performance, whether that be an e-mail or letter from their boss or someone higher up, or a mention in a departmental meeting or newsletter.

Practice What You Preach When it comes to cultural change, the most important single element of success is leadership. As the head of an organization or a team, you cast a powerful shadow of influence over your peers and employees. This means you must model the behavior, attitudes, and values you want represented within the organization. When people see you making an effort that will make them want to follow suit.

Encourage Involvement and Ownership When people have changes thrust upon them, it is only human nature that they will display a certain amount of resistance. If people feel no involvement or ownership, "not-invented here" syndrome sets in, and it can be difficult to subsequently win people around. Through consultation and involvement, people will experience greater control over the changing environment they are working in, and so they will be able to contribute positively rather than resist the change.

Say It Over, and Over, and Over Again Changing an element of culture doesn't happen overnight. These patterns of doing things take a long time to develop. You need to communicate what you want done, and why, on a regular basis. Risk over-communicating if you need to because at some point, the message will resonate with each and every employee. If you let up, you risk allowing old patterns to re-emerge. Keep driving the message home until the new characteristic is firmly entrenched as a cultural characteristic.

Build a New Reputation The aspects of your culture that you want to change away from need to be highlighted and then decisively quashed. Be open and forthright about what wasn't working and then create a new image for team, department, or organization. You might create a slogan or mantra that depicts what you intend to represent. If your tag line is, "We own our decisions" then eventually you will be known as the department that takes responsibility and commits to making right the results of less than optimum decision making.

Be Passionate Finally, anything that requires changing requires enthusiasm. Show your passion and commitment to the cause every day. When you unequivocally believe that a certain aspect of your culture needs to be changed, you will display that belief in everything you do. As you

pass your passion on to others, you will create a chain reaction that culminates in a successful change initiative. This will also increase your "change agility" for next time.

Key Points An organization's culture is deeply embedded in its experiences, the way people work there, and their shared values and beliefs. It's not something that's quick or easy to change. However, if your organization's culture is creating barriers to the organization's progress, it's one of the key elements that you need to address when planning your strategic and change initiatives. By analyzing your organization's culture, and addressing any key barriers to change, you can help your make your change initiative more successful. With perseverance, communication, and passion, you can build a new story and encourage new ways of working. And so you will build a higher-performance culture which is fundamental to your organization's ability to adapt and change, and to its long-term success.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Manage Change Learning Stream extension resources

View print friendly versio

Ask questions, or share your experience Return to top of the page

Planning Large Projects and Programs Planning Large-Scale Projects The techniques explained so far in this section on Mind Tools support a pragmatic, commonsense approach to planning and managing small and medium-sized projects. However, this approach will only scale up to a certain extent – as projects get larger, they can reach a level of complexity where ad hoc approaches to project management become wasteful and inefficient.

Use a formal planning approach for complex projects. © iStockphoto/m-1975

For these projects, project management becomes a technical discipline in its own right. To run such projects efficiently, project managers use formal project management methodologies such as PMBOK or PRINCE2. PMBOK, which stands for the “Project Management Body Of Knowledge”, was first published in 1996 as a manual called A Guide to the Project Management Body of Knowledge. It is now in its fourth edition. It is a standard that represents generally-recognized good practice, and is published by the Project Management Institute. This is a not-for-profit membership association for the project management profession, which administers the associated Project Management Professional (PMP) qualifications. PMBOK is the dominant project management methodology used in North America. PRINCE2, which stands for "PRojects IN Controlled Environments", is widely used in the UK and in English-speaking countries outside North America, and was originally devised as a “best practice” standard to be used for managing UK government information systems projects. Since then, it has become increasingly widely used for projects of all kinds, in the private as well as the public sector, and although copyright in it is retained by the Crown and managed by the Office of Government Commerce (OGC), its methods are in the public domain and are free for organizations to use. Various accredited training organizations offer PRINCE2 qualifications at Foundation level, for those who need to be familiar with its terminology, and at Practitioner level, which is aimed at project and program manages. PRINCE2 is powerful in that it completely clarifies people's roles in projects, ensures that lines of communication are clear, makes sure that project risk is actively managed, sets up appropriate controls,

establishes baseline costs, schedule and scope, and so on. In this, it embodies and codifies much of project management best practice. For more information on training courses and PRINCE2 manuals and other publications go to www.prince2.org.uk, the website of the OGC’s official training and certification partner. PMBOK and PRINCE2 offer different but compatible approaches to project management. PRINCE2 is underpinned by a project phase framework, whilst PMBOK is arranged around knowledge area processes that run through most projects, such as cost management and communications management.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote If your work requires you to participate in planning large projects then understanding the principles in these project management structures is essential for your success. The amount of planning and organization that goes into a large scale project is overwhelming... unless you have a system and a framework to keep track of the big picture, stay on top of issues, and mind the day to day details. If you have experience with large projects we'd love to hear about the lessons you've learned and what has worked really well for

you. Dianna September 8, 2010

Return to top of the page

Post-Implementation Reviews Making Sure That What You Delivered Actually Works "Completing a project" is not the same thing as ending the project management process. Simply finishing doesn't ensure that the organization benefits from the project's outcome. For example, after completing a year long project to establish a new quality management process for your organization, "Lessons learned... and more." you want to make sure that © iStockphoto what you set out to do was actually achieved. Your objective wasn't to simply deliver a process – but rather, to deliver the process that addresses the specific business need you intended to meet. This is the real measure of success. To make the most of the benefits that the project can deliver, however, you also need to check to see if further improvements will deliver still greater benefit. You also need to ensure that the lessons learned during the project are not forgotten. You can more effectively design and execute future projects when you take advantage of lessons learned through experience of previous projects. So how can you properly measure a project's success, and work toward continuous improvement? This is where the process of PostImplementation Review (PIR) is helpful. It helps you answer the following key questions: • Did the project fully solve the problem that it was designed to address? • Can we take things further, and deliver even bigger benefits? • What lessons did we learn that we can apply to future projects?

The PIR Process The key to a successful PIR is recognizing that the time spent on the project is just a small part of an ongoing time-line. For people and organizations that will be working on similar projects in the future, it makes sense to learn as many lessons as possible, so that mistakes are not repeated in future projects. And for organizations benefiting from the project, it makes sense to ensure that all desired benefits have been realized, and to understand what additional benefits can be achieved.

When to Review A good time to start thinking about the Post Implementation Review is when members of the project team remember the most – shortly after the project has been delivered, and when most of the problems have been ironed-out. Start to list ideas and observations while they are still fresh in people's minds. However, to adequately assess the quality of the implementation and complete this process, you'll need to wait long enough for the changes caused by the project to truly take effect. There will probably be a period of adjustment before you can finally review the solution as it was intended to operate: you'll likely need to overcome some of the usual resistance to change, hold people's hands while they operate new systems, and eliminate technical problems that didn't emerge when deliverables were tested. You should therefore typically allow a few weeks, or even a few months, before doing the full PIR. Where possible, allow for at least one, full, successful cycle of business before reviewing lessons learned.

What to Review Here are some tips for conducting the PIR: • Ask for openness – Emphasize the importance of being open and honest in your assessment, and make sure that people aren't in any way punished for being open. • Be objective – Describe what has happened in objective terms, and then focus on improvements. • Document success – Document practices and procedures that led to project successes, and make recommendations for applying them to similar future projects. • Look with hindsight – Pay attention to the "unknowns" (now known!) that may have increased implementation risks. Develop a way of looking out for these in future projects. • Be future-focused – Remember, the purpose is to focus on the future, not to assign blame for what happened in the past. This is not the time to focus on any one person or team. • Look at both positives and negatives – Identify positive as well as negative lessons. When conducting the review, include the following activities: • Conduct a gap analysis. • Review the project charter to evaluate how closely the project results match the original objectives. • Review the expected deliverables (including documentation) and ensure either that these have been delivered to an acceptable level of quality, or that an acceptable substitute is in place. • If there are gaps, how will these be closed? • Determine whether the project goals were achieved. • Is the deliverable functioning as expected?

• Are error rates low enough, and is it fit for purpose? • Is it functioning well, and in a way that will adjust smoothly to future operating demands? • Are users adequately trained and supported? And are there sufficiently enough confident, skilled people in place? • Are the necessary controls and systems in place, and are they working properly? • What routine activities are needed to support the project's success? • If there are problems here, how will these be addressed? • How does the end result compare with the original project plan, in terms of quality, schedule and budget? • Determine the satisfaction of stakeholders. • Were the end users' needs met? • Is the project sponsor satisfied? • What are the effects on the client or end user? • If key individuals aren't satisfied, how should this be addressed? • Determine the project's costs and benefits. • What were the final costs? • What will it cost to operate the solution? • What will it cost to support the solution in the future? • How do the costs compare with the benefits achieved? • If the project hasn't delivered a sufficiently large return, how can this be improved? • Identify areas of further development. • Have all of the expected benefits been achieved? If not, what is needed to achieve them? • Are there opportunities for further training and coaching that will maximize results? • Could you make further changes, which would deliver even more value? • Are there any other additional benefits that can be achieved? • Identify lessons learned. • How well were the projects deliverables assessed, and how well were timescales and costs assessed? • What went wrong, why did these things go wrong, and how could these problems be avoided next time? • What went well, and needs to be learned from? Tip:

For a detailed list of questions you might want to ask, see this excellent posting on the Club forum.

• Report findings and recommendations. • What have you learned from this review? • Do you need corrective activity to get the benefits you want? • What lessons have you learned that need to be carried forward to future projects? • Does this project naturally lead on to future projects, which will build on the success and benefits already achieved?

How to Review As you perform the post-implementation review, certain methods and practices will help you obtain the best possible information: • Define the scope of the review beforehand -The last thing you want to do is to create a political problem. Given the number of people often involved in a project, it's easy to hurt someone's feelings when reviewing the project's success. Clarify your objectives for the review, and make your intentions clear – this will better ensure that people share their experiences openly and honestly. Then make absolutely sure that you stick to these intentions, and that people's egos aren't unnecessarily bruised by the process! • Review key documents – Gather together the key project documents. This will help you assess the project planning process, as well as the actual benefits achieved through the project. • Consider using independent reviewers – Where possible, use outside people in your review process to get an objective, unclouded view of the project. Some people recommend using only independent people in the review, however, you can learn a lot from the perspectives of those who were directly involved in the project – this is why the best strategy is probably to have a balance. • Use appropriate data collection – Collect information in the most appropriate way, for example, by using interviews and surveys. Also, test the deliverable yourself, to make sure you get firsthand information. • Deliver appropriate reports – Report your findings, and publicize the results. Remember that the PIR is designed to help project managers conduct more effective projects in the future, as well as to measure and optimize the benefits of the specific project being reviewed. • Present recommendations – Present the detailed recommendations to the organization and the project leaders, as well as to customers and other stakeholders. Include as many people as necessary so that you keep – and apply – the bestpractice information in the future. As you plan your PIR, be aware of the costs and benefits of the review process itself. Interviewing stakeholders and customers,

testing the solution, and documenting the results are timeconsuming activities. Make sure the time and resources dedicated to the review are consistent with the project scope and its output, and that the potential benefits of conducting the review are worth the effort put in.

Key Points A Post-Implementation Review (PIR) is conducted after completing a project. Its purpose is to evaluate whether project objectives were met, to determine how effectively the project was run, to learn lessons for the future, and to ensure that the organization gets the greatest possible benefit from the project. After a long project, the last thing many project teams want to do is relive the process and look for ways to improve. However, a forward-looking review can discover many tips and strategies for improvement. By conducting a thorough and timely PIR, you'll identify key lessons learned – and you can then apply those lessons to the planning and management of future projects.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Program Management Structuring Projects as Part of a Program Say you wanted to adopt a new technology and use it to change the way your organization works. To do this, you'd need to implement a number of different projects, focused on different areas of your organization. However, there are interdependencies between the projects, and they need to share some key resources.

Multiple projects are often run as part of a program. © iStockphoto/endopack

Also, your organization needs to manage the costs for each project within a single overall budget. Instead of running each project separately, it probably makes sense to manage these projects within a single program. But, what type of program structure should you use? And which activities do you need to manage at program level, rather than project level? In this article, we'll explore program management. We'll look at what a program actually is, and review different types of program structure.

Definition of a Program A program usually consists of a number of projects that contribute to the same strategic goal, and which have the same business sponsor. Some organizations also refer to large and complex projects as programs. The main benefits of managing projects in a program are: • You have a single delivery structure, and a single senior sponsor is responsible for achieving the goal. • It's easier to manage interdependencies, conflicts of interest, and competing requests for resources between projects. Managers, sponsors and steering groups can make decisions in the best interests of the program as a whole. • Managers can appoint program-level resources to work on behalf of all of the projects to improve effectiveness and efficiency. For example, you could set up a department to provide the IT support for all projects involved in the program. If you run your projects within a program, you must decide on the role and responsibilities of the program manager, the support that this person needs (which is usually called the program management

office, or program office), and the way that resources need to be distributed between the program and projects. There's no single solution to how to organize this, as it depends on the organization, and the goals of the program. However, we'll look at a typical program management structure that you can use as a starting point to assess what's required for your program. We'll then look at two examples of how this structure may work in practice.

A Typical Program Management Structure Figure 1 below shows a typical program management structure.

The two tables below show the phases and processes of program management, and the roles and responsibilities that program and project teams may have within this structure, depending on how you decide to organize things.

Table 1 – Phases Phase

Program strategy and business case.

Program Level Responsibilities

Project Level Responsibilities

Develop a strategy for the program as a whole. Develop an overall business case , with program-level costs and benefits.

Contribute to the program strategy and business case where required.

Phase

Program Level Responsibilities

Project Level Responsibilities

Develop project mandates for each project. Preparation.

Appoint project managers and perhaps other key project team members.Set up the governance group. Develop the program charter.

Appoint all other project team members.Establish any project-specific governance structure, if required. Develop the Project Charter or Project Initiation Document .

Design.

Establish principles and constraints within which the projects must operate. Agree on the approach to be used within each phase.

Deliver the project within the program framework.

Development and testing. Training and business readiness. Support and benefits realization.

Table 2 – Processes Process

Program Level Responsibilities

Project Level Responsibilities

Phase management

Determine project phases and phase start and end dates. Sign off on phase entry and exit criteria.

Manage the project within each phase.

Planning

Establish planning methodology and conventions. Agree on the overall program plan, including project plans at the milestone level and the program critical

Agree and deliver to the high-level program plan. Conduct detailed project planning. Monitor progress against this plan.

Process

Program Level Responsibilities

Project Level Responsibilities

path .Monitor progress against this high-level plan. Control

Agree and sign off on the high-level scope, business case , and benefits for the program as a whole. Support/manage escalated risks and issues from the projects. Manage the governance process . Allocate budgets to projects. Establish and manage program reporting, and internal program team working mechanisms.

Manage detailed scope, issues, and risks. Escalate areas of concern to the program level for support. Collate and manage costs and benefits information for the project, and report this to the program manager.

Team management

Manage shared resources within the program. Manage program-level team members, and project managers.

Manage project staff.

Communications and change management

Manage communications with program-level stakeholders . Develop the program communications strategy. Ensure an integrated change approach across the program.

Manage stakeholders local to the project. Conduct communications and other 'adoption' activities with wider stakeholder groups in line with program strategies.

Procurement

No typical setup. This depends on what makes the most sense for the program as a whole.

Integration

Manage integration points between the projects within the program.

Manage integration points between the project and 'business as usual' functions.

Process

Other

Program Level Responsibilities

Project Level Responsibilities

Establish the project management methodology to use for the program and associated projects. Conduct audits of associated projects, if required.

Examples of Program Structures The program structure above is a useful starting point, but it's not appropriate for all programs. These examples show how you can amend this structure to serve your own needs.

Example 1: A "Thin" Program Structure In this example, the sponsor has formed several projects to deliver a key strategic goal. There are only a few interdependencies between the projects, but these interdependencies are critical. They all must deliver change into the same parts of the organization. Therefore, the main benefit of establishing a program is to give increased visibility to these interdependencies, and to manage change in an integrated way. The program structure consists of a program sponsor, a program manager, and a support person. The program manager is accountable for the program as a whole, with an emphasis on leading and driving the overall change strategy. The project teams then do the detailed communications and change work. There is also a dedicated support person to collate reports, monitor costs and benefits, create communications and presentations, arrange program meetings, and prepare for program steering group meetings. This is an example of a "thin" program structure, in which the program manager's main role is to provide leadership and direction. Note:

Program managers will always benefit from having project management skills. But in a "thin" program structure as in Example 1, the most important skills are usually: • Managing relations with key stakeholders. • Controlling the program as a whole, rather than managing the details. • Providing leadership and direction.

So you don't always have to be an experienced project manager to be an effective program manager.

Example 2: A "Thick" Program Structure In this example, a company is rolling out a new system across several business units in different geographical areas. They've created a rollout program involving the initial system design and build, and pilot implementation. The program manager is "hands on," directly managing the initial design, build, and implementation. He or she manages the delivery of core components that are common to each implementation. He or she needs to know the details of the rollouts, the issues that the projects face, what's being done to manage issues that impact the critical path, and how staff are adopting the new system. The program office provides the support included in the typical program structure. In addition, the program office provides resources, experience, and advice so that each group of implementers doesn't have to learn everything on their own. The program office also includes additional strategy and control roles. These roles ensure that the original design is being appropriately implemented and adopted by everyone in the company. This is an example of a "thick" program structure, in which the program manager holds significant control and support.

Four Steps to Decide Your Program Structure Follow these simple steps to help you determine which structure is most appropriate for your program: 1. Identify which projects should be brought together into the program. 2. Identify what you must control at the program level to ensure that you meet your program and project goals. 3. Identify the services that the program should provide to increase project efficiency. 4. Identify the project cross-linkages that you need to manage, so that delivery is robust.

Further Program Management Tips • Don't simply set up a program with "standard" program roles – think about which roles are appropriate for your particular situation. This will help you avoid confusion and duplication of work between the program and project offices. By adopting this, you'll avoid unnecessary costs created by unnecessary roles. • If you assign an activity to the program office to improve efficiency, make sure that the activity serves the needs of the project as well as the program. If not, the activity may be

duplicated within the project, and you won't achieve the efficiency you intended. • When you design the roles required to ensure that changes are adopted, consider your stakeholders' perspectives. Then determine who should do what. Stakeholders may become overloaded and confused when they have to deal with too many different people within the program.

Key Points Our "typical" program structure gives you a useful starting point for determining your program structure, but it doesn't provide the full answer. You can base your structure on this, or use a variation of our "thin" or "thick" structure examples. When you develop your proposed structure, review it from several perspectives. Make sure it works for everyone involved – the project team members, project managers, program manager, program sponsor, governance group, and stakeholders.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... AnneE wrote Hi cmccawley,

Unfortunately I don't have any personal recommendations for you, but I've pasted a link below to a good review site. Hopefully you'll find something interesting on there. http://www.softwareadvice.com/construction/programmanagement-software-comparison/ Anne September 12, 2013 Dianna wrote Hi cmccawley, I've asked some people here who work in project management to suggest some software programs they use and like. Will keep you posted. Dianna September 10, 2013 cmccawley wrote Any sugesstions on a software to use that will manage and track the projects under the program? September 9, 2013 joe0823 wrote Your business could purchase A+ certifications, which are certifications in computer fundamentals, trouble shooting, and hardware. As well as microsofts MS-OS which teaches you how to use all the Microsoft office applications as well as the operating system. Getting the certifications in quantity will allow for lower purchase price, and if subScriber demand for certification aqisitions and reward after completion remain higher then the input costs there is potential for marginal gains or even better. February 13, 2012 darkchocolate wrote I am right in the middle of a programme assessment exercise so this article is very helpful. The skills assessment tools re communications, team effectiveness and project management are also very useful in context of an overall programme assessment. MT makes it easy for me to apply these information to the assessment exercise. Many thanks. November 24, 2011

Dianna wrote Hi Josephine, Thanks for your supportive comments about the article. I've been in touch with our planning team and the idea of certified courses is something that we are exploring albeit very slowly and cautiously. As you can imagine there are a number of issues to be addressed and finding an international body to provide certification might not be feasible. However I wanted to let you know that it is an avenue that we have on our radar. In the meantime, have you looked into PRINCE2 or PMBOK training and certification in your area? The Project Management Institute http://www.pmi.org/ ([color=brown:17lc57tz]moderator approved link) has links to PMBOK certification courses and they have chapters and communities of practice all over the world. PRINCE2 appears to have the same type of organized programs available globally so that is another option. Here is the link to that site: http://www.prince2.com/ ([color=brown:17lc57tz]moderator approved link) Hope this helps a bit. There are also lots of members with program management experience so you might want to pose any specific questions you have in the Career Cafe Central. It's a great way to learn from people who have direct experience with the issues you are facing. Dianna October 20, 2010 cutyjosie wrote REALLY INTERESTING Hi, it was relly helpful but i am hoping that this could be made into a form of certified course where people can be certified scholars? Just suggesting though because i have gained and learnt a lot. Thank you. Josephine October 12, 2010 bigk wrote Hi I found the article useful... It could have two issues... 1: the project manager might want access to the sponsor in the project or program although the program manager can meet this

need, there could be times when the project manager wants sponsor involvement. 2: Similarly the program manager might want contact with the project team or the sponsor... However it seems the program manager might spend more time between sponsor and project manager... Perhaps most projects could become a program, even only one project... often a project has many parts and these could be completed as a program. Any project whether a project or a program needs contact with the sponsor and the team, but mostly its customer. Communication and team working is the best way to approach this. Even large programs can use lean and agile methods, in the program office or project office and for scoping and result. But this is one option only, doing more evaluating. Read a few interesting articles recently about program and project, but this is only one of them. Bigk July 9, 2010 James wrote Hi Tarek I'm pleased that you found it useful! James July 9, 2010

Return to top of the page

Project and Program Governance Using Senior Management Support to Ensure Project Success Your business case is approved, your project team is in place, and you're ready to go. You have agreement on all the resources you need. You're confident that you're going to deliver on time, to quality, and within budget. The project's success seems to be guaranteed... But how often do things actually work out as smoothly as this?

Senior management support is essential. © iStockphoto/laflor

Then resources that you thought had been assigned to your project start to disappear… Experts that you need are allocated elsewhere. The data storage that you had stated as critical will no longer be provided, because another project has been delayed. Other stakeholders hear about your project, and it becomes obvious to you that the project's scope should be extended to include their needs, but you don't have the funding to do this. How could you have prevented this? The answer is to have strong project governance in place. This won't necessarily stop these issues from occurring, however, it will ensure that you have the right senior management support lined up and motivated to help you to resolve problems quickly and successfully. In this article, we'll explain what project governance is, we'll look at some useful governance mechanisms, and we'll give you a checklist that you can use to choose the approach that's right for your project.

What is Project Governance? Project governance is the set of processes used to ensure that the project is implemented successfully. This includes reviewing how the project is progressing through the project’s phases . Project managers are responsible for making sure that appropriate management processes are used routinely within the project. The Mind Tools project management menu takes you through many of these individual processes – for example, showing you how to initiate a new project, how to plan a large project, and how to control the scope of the project. But this isn't enough. A strong approach to project governance is also needed to engage with senior stakeholders. They can make decisions in the wider interest of the organization as a whole, and they can give you the support you need as a project manager, so that you can resolve critical issues.

You can get this engagement in a variety of ways, and not all are appropriate for all projects. In this article, we'll review three mechanisms that are commonly used as part of the project governance framework (steering groups, panels of experts, and oversight groups), and we'll look at the project sponsor role. You'll then be able to decide what will work best for your specific project. Project sponsorship is the most important part of project governance, so we'll start with the role of the project sponsor.

Project Sponsor Every project needs a sponsor to get started. Sponsors are often the executives who want the project's benefits, and they have the authority and commitment to provide the support that the project needs. As such, the sponsor has significant input into the project and is highly committed to the results. (See our article Working with Project Sponsors for more on this.) But simply having a project sponsor in place often isn't enough. Projects have a range of key stakeholders. (You can use the Stakeholder Analysis tool to understand who these are.) The web of relationships and interests that these stakeholders have can become difficult to manage. (Our article Stakeholder Management helps you think through the communications that each stakeholder needs.) Managing all of these separate relationships can take up a great deal of time. If you deal with them separately, you may lose out on ideas that would be generated if many of these people were in the same place, at the same time. Also, when dealing with issues or concerns one by one, you don't have the same opportunity for discussing the big picture, and support or advice given privately may not turn out to be that strong if other senior managers think of better ideas or solutions. One way of getting around this is to set up a series of forums that help you engage with stakeholders efficiently, helping you address the stakeholder engagement problems that many projects experience. These forums give you a way of formalizing this engagement, and put specific, regular events on stakeholders' calendars so that your project gets regular time and attention. There are three types of forum that can be useful: project steering groups, panels of experts, and oversight teams. We look at these below.

Project Steering Groups A project steering group is led by the project sponsor, and it includes senior people with a significant interest in the project and its success. This group is responsible for overall decision making with the project sponsor. Members oversee the direction of the project; set its priorities; approve its scope, costs, and resources; resolve major issues; ensure alignment with the business's strategic plan; and support the sponsor's communication within the business, and with customers and suppliers.

The project steering group usually includes the following people: • Senior managers from the areas of the business that the project impacts. • Representatives from key projects or programs with which this project interfaces. • Functional heads or experts from key risk areas – for example, IT, if there's a heavy reliance on information technology; HR, if there will be a significant impact on the roles that individuals will be required to perform; or a legal adviser, if there are significant contractual issues to be overcome. • A senior finance person, for both business case approval, and for monitoring of benefits against the business case baseline. • The project or program manager.

Panels of Experts A panel of experts is used to make recommendations about what the project delivers. The group may meet only infrequently, because it's likely that individuals on the panel would be needed for their advice at different times. For example, consider a project to deliver a global finance process to a range of countries. You could establish a panel of global process owners to decide where local variations are required to the global process (for example, local variations may only be needed for local taxation and legal requirements). Finance experts in each of the subprocess areas (for example, accounts payable and accounts receivable) could be consulted to decide which local process variations are acceptable, and which are not. You can also use this panel of experts approach with supplier and customer representatives, if this is appropriate for your project.

Oversight Teams Oversight teams are useful when you need to supervise the work and decisions that senior project team members are making, as a way of validating that the work and decisions made are appropriate. This is particularly useful when the project is being implemented by an external group, or by an inexperienced internal team. This oversight team is likely to consist of a small number of individuals, who will probably be assigned to this role part time (with the exception of very large projects). For an IT implementation, a typical oversight team would consist of a project manager, a technical manager, and a change manager. They would review key deliverables, attend key project meetings, and hold discussions with key team members and stakeholders to understand project progress.

Structuring Your Project's Governance Requirements There's no single answer to what appropriate governance arrangements look like. You must assess your project's needs to decide what is appropriate. Here's a checklist that will help you think about this:

• Which stakeholders are really important to the success of your project? And are their different interests likely to lead to competing priorities within the project? (If they are, a steering group or other forum will enable them to discuss these competing priorities and create a single list of products for the project to deliver.) • What is likely to cause the most significant issues within the project? (Use your log of critical risks to identify these.) Who will be able to help you if these become major issues? What is the best way to engage these people before any issues arise, so that they're available to you for support if the issues do occur? • Which of your project decisions involve several departments or functions? What is the best way to coordinate these decisions across these departments? • What profile does the project have within the organization? (The higher the profile, the stronger the governance needs to be.) • Whose support is critical for the sponsor to be effective? How is this support best given? • What is the attitude of key stakeholders to any change that the project will bring? If they're reluctant or if they refuse this change, what is the best way to engage them? Who is in the best position to convince them that this change is in their best interests, and what will convince them? • Who must sign off on the project deliverables to enable the project to proceed? How is this most effectively achieved? Who has the power to block the project, and for what reasons?

Key Points Effective project governance is critical to the success of many projects. Structure this governance so that it supports you and your project sponsor. By doing so, you can ensure that your project receives the support it needs when it needs it, which can make the difference between success and failure for the project.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly version

Ask questions, or share your experience

What members say... Yolande wrote A number of years ago I was involved in managing a big project in a neighbouring country. Seeing that it involved a lot of travelling and extra logistical problems (because it was cross-border) I really came to value weekly meetings with the steering group. It is easy to get so caught up in the day to day running of the project, that you could digress from the strategic plan. You could also try and do so many things on your own while a lot can be handled by various members of the steering group (in keeping with their roles and portfolios) - you only need to ask. When really starting to use this 'back-up' group (as I liked to think of them), I could really focus on what needed to be accomplished on a week to week basis in order for the project to be completed on time. Kind regards Yolandé September 6, 2010

Return to top of the page

Project Charters Getting Your Project Off to a Good Start You've just been appointed project manager for a new project. Senior managers have already signed off the project's business case, and you're busy recruiting your full-time project team. You're also identifying a wider group of people in your organization from whom you'll need to get support for certain project tasks.

You can use a Project Charter in discussions with your team, and other stakeholders. © iStockphoto/Yuri_Accurs

Some of these people have already been involved in developing the business case, and some are completely new to the project. As project manager, you'll often need to implement a business case that's already been approved. You'll have team members who have had different levels of involvement in the project so far. The problem is that some of these people may have different views of the project's goals, particularly if the project has been planned over a long period of time. So, how can you get your team working in a positive and productive manner, and how can you make sure that everyone understands the goals of the project? This where a Project Charter can help. In this article, we'll review the reasons you might use a Project Charter, and look at the main things that you'll need to include in one.

Why Use Project Charters? Project Charters outline project goals, and give an overview of how projects will look and feel while you work on them. You can use Project Charters in discussions with project team members, governance groups, and other stakeholders – either individually or as part of workshops – as a way of ensuring that everyone understands the project's requirements. Writing a Project Charter forces you to think through the project as a whole. You must understand all of the existing project documentation, consider how you want to approach implementing certain parts of the project, and identify the key points that everyone involved in the project needs to understand. You can also use a Project Initiation Document (PID) instead of a Project Charter for these purposes as they are very similar documents. However, a Project Initiation Document is usually much more detailed. So a Project Charter is more suited to projects where

you don't have the resources to write a detailed Project Initiation Document, or where you want to start work on the project quickly. Tip:

The project management methodology that your organization uses may also determine whether you should use a Project Charter or a Project Initiation Document.

Format of a Project Charter You can deliver your Project Charter as a report or a presentation. • In report format – Use this if the Project Charter must be selfexplanatory. For example, you may want to use it as a team reference document, to provide a baseline of what you and your stakeholders require and expect from the project. You can then submit the Project Charter as part of the project approval process. • In presentation format – Use this if you'll present the Project Charter as part of a discussion. For example, you can use the charter to give a project overview to your team at a project meeting; or use it to brief your governance group and stakeholders at their first project meeting.

Contents of a Project Charter The contents of each Project Charter are specific to the project, but they generally include the following: 1. Background and rationale. 2. Project requirements. 3. Project delivery. 4. Next steps.

1. Background and Rationale This section describes how the project has reached this point. In particular, it will: • Identify the opportunities the project will exploit, or the issues it will resolve. • Provide a record of key events and discussions so far, including any key decisions that you have already made. • Refer to the project mandate or to other statements made by senior managers that have helped identify the project and its requirements. • Identify the project sponsor and any other key people who have been involved in initiating the project, such as people involved in creating the project mandate, business case, or strategy document. • Provide references and links to other existing project documentation that project team members may need for more

detail. This could include the project mandate, business case and strategy documents.

,

2. Project Requirements This section gives more information on the project itself. • Objectives – List the project's objectives. Prioritize these objectives, if appropriate. • Customers and other stakeholders – Identify the customer(s) of the project. Describe the main interests and concerns of other key stakeholders. It's often useful to include a high-level stakeholder analysis at this stage. • Scope – Define the project's scope (what you need to do to deliver your project). Remember that scope creep (uncontrolled changes in your project's scope) is a common problem with managing projects, so it's definitely worth spending time on this area. You can specify scope by defining the project's functionality, systems, interfaces, processes, departments, and external stakeholders (such as suppliers and customers). It's also sometimes helpful to state what is not part of the scope of the project. • Constraints – List the key constraints, limitations and restrictions that could affect the project. These may be in the original project mandate, or they may have been part of later discussions. An example constraint could be, "the project cannot be delayed beyond September 30, 2010 because the output must satisfy a legal requirement." Or, "staff from the finance department cannot contribute to workshops during March, because of their commitment to preparing year-end statements." • Milestones and deliverables – Give the timing for project phases, and identify key milestones. It's important to specify which dates you have already agreed to, and which timings are open to discussion or subject to confirmation. But bear in mind that any deadlines that you set here will be used by stakeholders and governance groups in the future. If there are expectations about the quality of the finished project or interim deliverables, list these here as well. • Costs, benefits, and assumptions – Outline the high-level business case costs and benefits. Identify where you can find more details or the full business case. Remember to include qualitative as well as quantitative benefits . Also, list all of the assumptions that you have made in your projected cost and benefit statements. Tip:

Investigate assumptions as early as possible within the project delivery timelines. Assumptions that are wrong can be expensive to fix, and may delay the project.

For example, if the business case assumes that there is sufficient IT hardware to cover the project needs, investigate this as early as possible. If this assumption is not true, you’ll need time to negotiate an increase to your project’s budget.

3. Project Delivery This section of the Project Charter focuses on how the project will be delivered. • Challenges, risks, and issues – Identify any key challenges, risks, and issues that might affect the project. Focus on the big items - not necessarily on everything that you can think of. For example, if project timelines are aggressive and your department has an unsuccessful track record of implementing projects with short timescales, this might be a risk. Tip:

Discuss and agree the key challenges, risks, and issues with the project team during the early stages of the project. This will help team members to engage with the project, and allow them to take ownership of it. • Project approach and key principles – Identify the key principles that you have already agreed on about how you will deliver the project. This is particularly important for complex projects, as well as for projects that require significant changes within your organization. Say, for example, that three geographic regions were to be included in phase one of the project. The central project team could then produce a core implementation strategy that each region would then customize for its specific needs. • Governance framework – Explain how the project will be governed, and who is involved. In particular, describe the approval processes for phase exit and entry , and for any critical project deliverables. • Team roles and responsibilities – It's useful to include all project roles, not just full-time roles. Be sure to include those people involved in project governance ; and identify who is responsible for managing communication within the project, and for managing relationships with your key stakeholders. • Team management processes – If you've already agreed your processes for reporting; planning; managing risks and issues; and, time recording; then identify what you require from each member of your team. Many project teams like to create a list of "ground rules" that outline what people can expect from other team members.

4. Next Steps A Project Charter is often used as part of a team workshop or briefing, so it's useful to include a set of next steps so that team members know their responsibilities, and can start working on the project as soon as they are ready. Typical next steps are for team members to: • Review earlier project documentation (such as the project mandate and business case). • Create their approach for implementation, and record this in a strategy document. • Plan the next phases of the project in detail. • Map out resources required throughout the project.

Key Points Project Charters are useful documents that help you ensure that everyone knows the goals of a project. They minimize any confusion about what must be done within it, and explain how things should be done. Using a Project Charter gets your project team off to a good start by creating a positive and productive work environment, where everyone knows what their roles and responsibilities are.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote Hi Enzo, Welcome to the Club and glad you liked the article. I'll pass your suggestion to our editorial team to include an example for this article. The Club has many resources that are of great value on a professional and personal level so if you are looking for something specific, just let me know. Hope to see you around either with questions or your thoughts on other discussions. Midgie April 23, 2012 theilard wrote Precisely....Very important project charter! It would be appropriate to insert an example to follow (I apologize for my english approximated) Enzo April 20, 2012 mayc wrote That is so true Michele. I have had more than a few of my own projects fall very short of expectations because I dove right into the work without an adequate plan. It's always something I struggle with, trying to balance the time demands of getting a project finished and still wanting/needing to take the necessary time to plan and organize. Experience has taught me though to weigh on the side of planning whenever possible and practical! May May 31, 2010 zuni wrote In the fast paced environments we work within it is tempting to take short cuts and get on with what needs to be done. Taking the time to complete a project charter at the front end will save you a lot of rework later on. Michele May 31, 2010

Dianna wrote A project charter is such an essential element. It really sets the right tone for the project so that people know what they are responsible for right from the start. This is probably the best way to build in personal accountability - something that will help ensure your project reaches a successful conclusion. Dianna May 28, 2010

Return to top of the page

Project Close Activities Ending Projects Properly Projects usually have a clearly defined end – a bridge opens for public use, a product launches, or new software rolls out to everyone in your organization. As you approach the 'go live' stage and you're getting ready to hand the new process over to 'business as usual', are you looking forward to relaxing for a while, or are you already planning your next project?

Have you planned for the finish line? © iStockphoto/hidesy

Either way, before you move on to new challenges, it's important you don't ignore the final step of project closure. This doesn't just mean dotting the 'I's, and crossing the 'T's, or tying up any loose ends. It means capturing the lessons you've learned during the project, so that your team – or other departments within the organization – can benefit from them next time. And, it also means taking stock of what you've achieved, and celebrating your successes. The steps you need to take to formalize the project's acceptance are sometimes called the 'close project process.' This process verifies that the project has delivered the required outcomes, and that stakeholder expectations have been met. It also makes sure that everyone involved in the project knows how to move forward. Without formal closure, there's a risk that issues may arise, and no one will be assigned to resolve them. Project closure has many different elements, and the best way to carry out a closure is to plan for it from the start. This way, you have the opportunity to decide which criteria you'll use to show that the project is actually completed, and you can budget time and resources for the closing activities. As with all goals, it's important to know what you need to do to cross the project finish line. Sometimes, a project is cancelled before it's finished. When this happens, some parts of project closure become irrelevant. However, other elements may still need to be completed. In this article, you'll learn the steps for closing a project properly. Start by adding the following guidelines for project closure to your overall project plan. We've arranged them using the project closure outputs defined by the Project Management Body of Knowledge (PMBOK) Guide, and endorsed by the Project Management Institute (PMI). As

you read, think about the specific methods you'll use to plan sufficiently for closure practices.

Administrative Closure These activities relate to the overall management and oversight of the project. You need to address issues such as these: • Decide how you'll test deliverables (in some projects, for example in complex systems implementations, testing may occur much earlier than the closure project stage.) • Establish a plan to review and analyze 'open' issues. • Decide how you'll collect project records, and who will be responsible for doing so. • Determine how you'll analyze success or failure (this is often expressed in a project's Project Initiation Document , as modified by scope control processes.) • Gather lessons learned so you can apply them in future. • Plan for knowledge transfer. If you used external consultants, decide how you'll capture and retain their knowledge of the project details. • Establish project finances. This includes details like closing project codes in the finance system, and accounting for any remaining assets. • Decide how to manage communication related to closure. How many meetings will you hold, who will attend, and what specific closure documents will you need? • Archive project information. • Shut down the project office. A Post-Implementation Review (PIR) is an essential part of administrative closure. This formal review process helps you determine the overall effectiveness of the project. It provides an excellent framework for gathering lessons learned, and maximizing the benefits of the program.

Contract Closure These activities formalize the acceptance of the project outcome and deliverables. There may be an actual contract document when dealing with external customers. If the project is for an internal department, you may simply have an acceptance email. Either way, planning for contract closure is important, because you need to know exactly what defines project completion before you begin. Here are some things to consider: • Determine how you'll define acceptance criteria. • Define exactly what the acceptance criteria are (again, this is usually defined in a Project Initiation Document, as modified by the scope control process). • Identify who is authorized to approve project completion, and determine that criteria have been met.

• Determine how you'll control and manage the inevitable changes to the contract. • Decide what terms are needed if the project is not completed. During the project closure phase, the project team is responsible for meeting predefined criteria. It's also important to make sure that the client or end user is fully satisfied with the results. If any changes have been made to the contract before project completion, the contract document may need to be updated appropriately. The business requirements analysis is a key input to the project closure process. The more of these up-front planning tools you use, the easier it will be to bring the project to a close.

Transition/Handover of Project Results As well as formally acknowledging that the project criteria have been met, determine how you'll hand over responsibility for the project result to 'business as usual'. When a project deliverable is being developed, the project team is in control. However, when the deliverable is ready to use or implement, then the end users need to know what to do. To plan for handing over the final product, be sure to address these issues: • Determine what end-user training is required (again, in complex projects, this may need to happen much earlier than the project close stage). • Identify who will provide the training, and when. • Determine how much time the handover activities will take. • Decide how and when handover will take place. • Identify who will formally approve the transition process. After the final transition to your client, internal or external, you should receive a formal statement of acknowledgment. This finalizes your contractual obligations, and it gives the project team final recognition of their accomplishment. Consider a project completion celebration for the team, end users, and other key stakeholders. This is a great opportunity to recognize a job well done, and it can motivate workers as they prepare for their next assignments. It's important to recognize team members' achievements, both privately and publicly. Thank and praise each person individually. Then announce the project's completion, and highlight how the team's efforts benefited the organization.

Organizational Updates Archive the project information so that it's an accessible resource for future project teams. This function is easy to overlook, especially as team members separate and move on to other work. As with the other project closure activities, the more proactive you are with planning, the better the result. If you establish archive expectations at the start of the project, you'll be more likely to collect and store the

information you need. Your archive system should include these types of items: • Project files – planning documents, risk documents, status reports, presentations, financial reports, contracts, and significant communications. • Formal acceptance documents – statements issued by end users, approved change requests, and documented issues and solutions. • Project closure documents – contracts, invoices, schedule of training provided, and an 'open issues' file. • Historical information – lessons learned, and a knowledge database. You should gather and store these unique organizational assets electronically as well as physically. Many of these will be computer files, so back them up regularly. With physical files, make sure the information is well organized, and stored where people can easily access it.

Key Points The end of a project is a significant event. Therefore, it needs its own set of processes and activities for formal closure. This shows that the project goal has been met, and it provides a sense of accomplishment for the project team. Closure also ensures that lessons learned are gathered and stored, and that end users' needs and expectations have been met. With an official close, you know that the stakeholders are satisfied. Then you're free to reassign the project team, and reallocate resources to other projects – and start the cycle all over again.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Project Dashboards Quickly Communicating Project Progress In today's busy organizations, project and program managers need to know exactly how the projects they're responsible for are doing. But they also rarely have the time to read through detailed status reports covering all aspects of the project. Perhaps Project A is on time © iStockphoto/jgroup and on budget, but is it going to deliver all of the functionality that your sponsor needs? Or maybe engineers have been working overtime to ensure that every last bug has been ironed out. But how can you find out what this overtime has done to the budget? From this "time versus information" dilemma grew the concept of the Project Dashboard. Just as a car's dashboard provides immediate and up-to-date information about the speed of the vehicle, the amount of gas in the tank and the temperature of the engine, a Project Dashboard provides immediate and up-to-date information about the status of a project. A common and easily understood approach to using the dashboard is to use red, yellow or green symbols that quickly identify whether the thing being measured is in good shape (green), requires attention (yellow), or is critical condition (red). With a Project Dashboard you no longer have to wade through 3 different reports to determine whether the production department received the widgets it needed, and got permission to hire its new employees. Instead, if the widgets had arrived but a decision on staffing was pending, you would see that the Materials gauge was in the optimum zone and that the Human Resources gauge was registering in the warning zone:

With the overall simplicity of a dashboard, you need to remember that dashboards are not, in and of themselves, a panacea. The end product is only as good as the inputs. A dashboard is only an effective tool if firstly the right things are being tracked and secondly, the classifications being made are well-judged. Tip 1:

It's easy to descend into a quantitative and analytical mess with Project Dashboards. At root, managers want a simple, quick way of seeing whether there are problems they need to address. Reliance on a quantitative approach gives people a way of "wriggling out" of their accountability for reporting this. As a "client" of the Project Dashboard, you need to insist that the people reporting to you are personally accountable for their Project Dashboard judgment calls. Tip 2:

If you're a client, beware false positives. Make sure you allocate time to go into detail on individual cases, so that you can confirm to yourself that classifications are fair and reliable. Otherwise you risk being disastrously hoodwinked! On the other hand, make sure that people don't waste your time by flagging up trivial issues as needing attention. Make sure people take responsibility for solving these themselves!

How to Use the Tool Follow these steps to use the Project Dashboard: Step One: Assess your goals and expectations for the dashboard. Why you are you using it? What should it tell you? Here are some examples: • How far off my budget am I? • Are we on schedule in meeting project milestones? • Do we have the resources we need in place? • What is the status of the various ongoing tasks? • Are the project risks controlled? Step Two: With the person reporting to you, agree what should be shown on the Project Dashboard, and how this should be represented. If you're monitoring a business, perhaps there are key indicators that you watch that show you what's going on? Or if you're responsible for a project, perhaps you want to monitor individual streams of activity within the project, keep a sharp eye on the critical path, or monitor other aspects of it? Also agree how information will be represented, and the sensitivity with which information is represented: For example, you may not be at all worried if people slip a couple of days behind on a task, just as long as they catch up. And just seeing a list of twenty items monitored may be enough, rather than having to scan a 30 page dashboard. Whatever you decide, keep it as simple as possible, and make sure that the people reporting to you remember the purpose of the

dashboard – to keep you informed, and alert you to issues you need to resolve. Step Three: Make sure that people are held personally accountable for their Project Dashboard judgment calls. You need to know: • Who, precisely, is responsible for making the judgment call; and • Who can override this judgment call. Step Four: Work with the Dashboard. Get experience with it. Add or eliminate measures as you find you do or do not need them. Increase or reduce the sensitivity of reporting. Get people used to making good judgment calls. And make sure you leave enough time to validate the information being reported.

Key Points The Project Dashboard is a useful technique for quickly communicating the status of projects that you're responsible for. It quickly shows you whether individual parts of the project are on course, are worrying, or are in serious trouble. As with any simplification of reality, it's vulnerable to confusion and misreporting. It's therefore essential that you avoid excessive complexity, and insist that people reporting information to you are accountable for their reporting, and that you regularly allocate time to assure the accuracy of people's reporting.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote It's great to know we have an Excel guru in our midst - macros scare the heck out of me and don't even go there with pivot tables! You're right though, Excel is a powerful tool for scorecards becuase you can extract data quickly. Thanks for the tips. Dianna February 10, 2007 kohakumark wrote I use Excel for my scorecard, and use a summary page giving info on the most important KPI's to be viewed. Hidden comments are in the cells which show the criteria for the KPI as well as the conditional formatting to instantly tell the viewer the status of the KPI. The scorecard also links to and automatically builds graphs on other pages which are linked to via macro buttons. I love excel ! February 10, 2007 caz66 wrote Hi there I've just joined the club and work in a a really complicated Programme Office - we're the outsourced provider in a joint venture, and so have to report to the purse-string holders in the other organization on a weekly basis. We have loads of projects going on, and our reports are massively complicated spreadsheets which lead to endless discussions by teleconference every Friday morning. I'm going to suggest adding the dashboard colours so we can shorten the teleconferences by skilling all of the green items it will be really visual and easy to use. I just hope we don't finish up with the "wars" you mention, Max! Thanks for the great tip - I feel I'm getting my money's worth already! Caro February 8, 2007 MaxZero wrote I guess whether they're quantitative or not depends on whether they're wired into a Management Information System... And I'm nervous about a quantitative approach as it can take so much

time and effort to calibrate these to give useful information that busy executives can lose interest before they start giving good results. Much better to keep it simple and have managers responsible make the assessments of colour as Helena describes. (I can understand how people don't like being forced to reduce all of the complexity of a project stream into a simple red, amber or green but I think that's just part of the job. After all, someone's got to simplify the complexity, and why not the person who most understands it? Time to earn your salaries, project managers!) But this has to be done sensitively - I've seen at least one "war" started by this technique: "How dare you red light me! It was xyz who screwed up - and he's green lighted!" October 13, 2006 Dianna wrote I think people are afraid of dashboards - they appear to be very analytical and quantitative and drilling things down to numbers, times, dollars, etc... is intimidating to people who are used to working with ideas, concepts, and people. Technical people love this type of framework and "people" people, shy away from it. How I would approach introducing dashboards is to talk about the idea extensively and use very simple examples that everyone can relate to. Then I would start with a very simple project and hold regular (daily?) meetings to go over the dashboard progress and help people to understand the inputs. Basically, I'd hold their hand until they "get" how easy and powerful the concept is. After one project like this, I'd be willing to bet the employees would embrace dashboards in many different areas of the business. Hope that helps a bit.... Dianna October 12, 2006 JulesD wrote I'm a big fan of this technique. But I find that it's not always welcomed by the people who are supposed to need the info and action issues. Does anyone have any tips about how to get this kind of reporting working / fully accepted? I'd appreciate some tips... October 12, 2006 Helena wrote

Hi there Project dashboards certainly are a very effective way of reporting progress. Recently, I was involved with a Programme Office that had to report on about 20 projects on a weekly basis to the programme sponsors. We used Excel to do this, and assigned what we called a RAG (red/amber/green) status to the project. What we did wasn't that scientific - project managers just made an informed decision about whether the project overall was red, amber or green, and put in commentary. We discussed any of the projects which weren't green at a weekly teleconference. But back to HOW we used Excel to do this. We had a spreadsheet which listed all of the prokects. There was a RAG status column. To update this, you just typed R, A or G into the cell, and it turned red, amber or green because the person setting up the spreadsheet had set the conditional formatting for every cell in that column. Do this by highlighting a cell or group of cells, and doing FormatConditional Formatting. Then set up 3 conditions: one that sets a red background (on the Patterns tab) if the cell value is R, one that sets it as amber if the value is A and one that sets it to green if the value is G. Simple, cheap and effective! Of course, it helps if you have a colour printer available... Enjoy being in the driving seat with your project reporting. Best wishes Helena October 11, 2006

Return to top of the page

Project Initiation Documents Getting Your Project Off to a Great Start Have you ever been part of a project where not everyone has the same view of where the project is heading? This lack of clarity can breed confusion: People start pulling in different directions, building up unrealistic expectations, and harboring unnecessary worries and fears. © iStockphoto/kzenon

While it's normal as part of a project to put the detailed plans, controls and reporting mechanisms into place, how do you get everyone on the same page to start with? This is accomplished by creating a Project Initiation Document (PID) – the top-level project planning document. In it, you bring together all of the information needed to get your project started, and communicate that key information to the project's stakeholders. With a well-put-together Project Initiation Document, you can let everyone understand where the project's heading from the outset. Your Project Initiation Document does the following: • Defines your project and its scope. • Justifies your project. • Secures funding for the project, if necessary. • Defines the roles and responsibilities of project participants. • Gives people the information they need to be productive and effective right from the start. By creating a PID, you'll answer the questions: What? Why? Who? How? When? You can also use a Project Charter instead of a Project Initiation Document for these purposes as they are very similar documents. However, a Project Charter usually has less detail. So a Project Initiation Document is more suited to projects where you have the resources to write a more detailed document. "Project Initiation Document" and "PID" are terms used in PRINCE2®. PRINCE2 is a registered trade mark of AXELOS Limited.

Tip:

The project management methodology that your organization uses may also determine whether you should use a Project Charter or a Project Initiation Document.

Constructing a PID Although most project-driven organizations have their own templates for Project Initiation Documents, the information contained in those documents is often quite similar, despite variations in the terms used. Here, we work through the most common sections, and look at the information that should be covered in each. Start by downloading our free Project Initiation Document Checklist. Use this checklist to mark off each part of your PID as you complete it – either on your corporate template or on a PID that you construct from scratch. Note:

Our checklist is for guidance only. In your situation, it may be appropriate to leave some items out and/or add others.

Section 1: What? This section tells the reader what the project is seeking to achieve. In it, describe the problem that the project is seeking to solve, as well as a full definition of the project. This section will typically cover the following topics: Background

What is the context of the project, and why is the work needed? Briefly describe the idea or problem, and discuss why this project is relevant and timely. The details will come later, so use this section to highlight briefly how this project came to be. Project Definition

• Purpose: Why are you doing this work? Describe the desired end result of this project. • Objectives: What specific outcomes will be achieved, and how will you measure these outcomes? Remember to limit the number of objectives for your project – four or five goals are typically enough. • Scope: What are the boundaries for this project (for example, type of work, type of client, type of problem, geographic area covered)? List any areas excluded that you believe stakeholders might assume are included, but are not. The more specific you are, the less opportunity there is for misunderstanding at a later stage in the project. • Deliverables: What will the project deliver as outputs? Where you can, describe deliverables as tangible items like reports, products, or services. Remember to include a date that each deliverable is expected. You'll use this information to monitor milestones. • Constraints: What things must you take into consideration that will influence your deliverables and schedule? These are external variables that you cannot control but need to manage.

• Assumptions: What assumptions are you making at the start of the project? If necessary, schedule work to confirm these assumptions.

Section 2: Why? Build a business case to show why your project is going ahead. Describe the effect the project will have on the business, and support this with a detailed account of the risks that should be considered. Business Case

• Benefits: Why are you carrying out this project, and what benefits do you expect it to deliver? Include information on how these benefits will be measured. For more on benefits management , click here . • Options: What other courses of action were considered as this project was designed and developed? • Cost and Timescale: Provide a breakdown of project costs and related financing. • Cost/Benefit Analysis: How are the costs of the project balanced against the expected returns? For details of how to construct a cost/benefit analysis , click here . Risk Analysis

• Risk Identification: Identify the risks within the project, and that you'll either need to manage or accept. • Risk Prevention: Describe what you are going to do to mitigate or manage risks. • Risk Management: Where you can't prevent risks, what are your contingency plans for dealing with them? What actions will you take should the risk materialize? • Risk Monitoring: What processes do you have in place to routinely assess the risks associated with your project? For more on how to identify and manage risk

, click here

.

Section 3: Who? Describe how the project will be organized and managed. Identify reporting lines, and outline specific roles that will be filled. You need to be clear about staff roles so that you don't duplicate responsibilities, and so that everyone is clear about what's expected of them. If this is a long-term project, you may even consider developing job descriptions for team members. Roles and Responsibilities

• Project Organization Chart/Structure: Create a diagram that shows the lines of authority and reporting for each project team member. • Project Sponsor: Who has the ultimate authority and control over the project and its implementation? • Project Manager: Who is the Project Manager, and what are his or her responsibilities?

• Project Team: Who are the key members of the project team? What are their roles and job descriptions? What are their phone numbers and email addresses? What is their original department or organization? And to whom do they report to on a daily basis?

Section 4: How and When? Provide broad information about how the project will be implemented. Outline how the project will roll out by defining timelines, resources, and management stages. This is a high-level overview that will, as the project proceeds, be supported by more detailed project planning documents. Initial Project Plan

• Assignments: What major tasks (with milestones) will be completed during the project? • Schedule: Provide a report of the estimated time involved for the project. You've probably already prepared a high level Gantt chart or similar schedule, so the PID simply summarizes the anticipated schedule. • Human Resources: How many days activity will be needed to complete the project? How many support staff will be needed? Will you need to bring more people onto the project team? • Project Control: How will progress be monitored and communicated? • Quality Control: How will the quality of deliverables be evaluated and monitored?

Key Points A Project Initiation Document is a guide to a project, clearly laying out the justification for a project, what its objectives will be, and how the project will be organized. This helps ensure that everyone knows what's going on right from the outset. The amount of detail included should be sufficient for the reader to understand the basic purpose of the project and to determine, in principle, the overall feasibility of the project objectives and plan. The PID is supported by many detailed planning documents that may not be entirely completed by the time that the PID is prepared.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Project Issue Management Identifying and Resolving Issues In the life cycle of any project, there will almost always be unexpected problems and questions that crop up. When these issues arise, you have to be ready to deal with them – or they can potentially affect the project's outcome. Since most issues are, by their nature, unexpected, how do you make sure you'll be able to Have a plan in place to resolve issues. deal with them quickly and © iStockphoto/mikdam effectively? Ideally, you need an issue resolution process in place before you start your project – to make sure that you stay on schedule, and meet your objectives. Issue management is the process of identifying and resolving issues. Problems with staff or suppliers, technical failures, material shortages – these might all have a negative impact on your project. If the issue goes unresolved, you risk creating unnecessary conflicts, delays, or even failure to produce your deliverable.

Issues versus Risks Issues and risks are not quite the same thing. However, the exact nature of both is largely unknown before you begin. With risks, you usually have a general idea in advance that there's a cause for concern. An issue tends to be less predictable; it can arise with no warning. For example, being unable to find qualified staff is an identifiable risk. However, when one of your staff is in a car accident, and hospitalized for three weeks, that becomes an issue! It's important to identify risks before the project begins. A Risk/ Impact Probability Chart provides a useful framework to help you prioritize your risks. You can then develop a plan to manage those risks proactivelywith solutions that you've already thought through and prearranged. However, when it comes to issues, you have to deal with them as they happen. Issue management, therefore, is a planned process for dealing with an unexpected issue – whatever that issue may be – if and when one arises. Tip:

When you don't identify and reduce risks at the beginning of a project, they can often become issues later on. Make sure you understand your risks early. Learn from previous projects, and benefit from the team's past experiences. This way, you'll have fewer issues to manage as you move forward.

Issues Log Issues – otherwise known as problems, gaps, inconsistencies, or conflicts – need to be recorded when they happen. When you create an issues log, you provide a tool for reporting and communicating what's happening with the project. This makes sure that issues are indeed raised, and then investigated and resolved quickly and effectively. Without a defined process, you risk ignoring issues, or not taking them seriously enough – until it's too late to deal with them successfully. An issues log allows you to do the following: • Have a safe and reliable method for the team to raise issues. • Track and assign responsibility to specific people for each issue. • Analyze and prioritize issues more easily. • Record issue resolution for future reference and project learning. • Monitor overall project health and status. You can create an issues log by hand, build your own spreadsheet or database, or buy issue management software from a wide variety of vendors. Alternatively, you can use our free Issue Management Log. However, do bear in mind that the success of your issue management process doesn't necessarily depend on which tracking mechanism you use, but rather on the type of information you track. You can include following information in an issues log: • Issue type – Define the categories of issues that you're likely to encounter. This helps you track issues and assign the right people to resolve them. You could have broad descriptions like these: • Technical – Relating to a technological problem in the project. • Business process – Relating to the project's design. • Change management – Relating to business, customer, or environmental changes. • Resource – Relating to equipment, material, or people problems. • Third party – Relating to issues with vendors, suppliers, or another outside party. • Identifier – Record who discovered the issue. • Timing – Indicate when the issue was identified. • Description – Provide details about what happened, and the potential impact. If the issue remains unresolved, identify which parts of the project will be affected. • Priority – Assign a priority rating to the issue. Here's an example: • High priority – A critical issue that will have a high impact on project success, and has the potential to stop the project completely.

• Medium priority – An issue that will have a noticeable impact, but won't stop the project from proceeding. • Low priority – An issue that doesn't affect activities on the critical path, and probably won't have much impact if it's resolved at some point. • Assignment/owner – Determine who is responsible for resolving the issue. This person may or may not actually implement a solution. However, he or she is responsible for tracking it, and ensuring that it's dealt with according to its priority. • Target resolution date – Determine the deadline for resolving the issue. Tip:

If a date for resolution changes, keep both the old date and the new date visible. This helps you spot issues that have been on the log for a long time. Then you can either give them extra attention, or take them off the list if they're no longer important. • Status – Track the progress of the resolution with a clear label identifying the issue's overall status. Here's an example: • Open – The issue has been identified, but no action has yet been taken. • Investigating – The issue, and possible solutions, are being investigated. • Implementing – The issue resolution is in process. • Escalated – The issue has been raised to management or the project sponsor/steering committee, and directions or approval of a solution is pending. • Resolved – The resolution has been implemented, and the issue is closed. Tip:

Use 'traffic lights' when reporting issues. This provides an easy-tosee indication of whether issues are under control. Traffic lights could be used as follows: • Red – Cannot proceed before issue is resolved. • Yellow – Resolution in process, and you'll be able to proceed soon. • Green – Resolution implemented, and issue no longer exists.

• Action/resolution description – Describe the status of the issue, and what has been done to find and implement a resolution. Include the dates of each action. Here's an example: • January 5 – Assigned issue to Samantha. • January 7 – Testing started to identify origin of problem.

• January 8 – Solution suggested, and sent to steering committee for approval. • January 10 – Approval received. Assigned implementation to Gregory. • January 14 – Solution successful. Issue resolved. • Final resolution – Include a brief description of what was done to address the issue.

Issues Management Framework Supplement your issues log with a framework, or process, for dealing with those issues. This framework helps the project team understand what to do with issues once they've been identified and logged. Developing the framework answers questions like these: • How will you assign responsibility for resolving the issue? For example, is there one person who handles all technical issues? Who would handle a vendor issue? • How will you know when to escalate an issue to management or the steering committee? You may want to create a matrix of potential business impact versus issue complexity to help you decide which issues should be taken to higher levels of management. • Which criteria will determine an issue's priority status? • Who will set the target resolution date? • How will issues be communicated within the team? Will you use regular meetings, log checks, status update emails, and so on? • How will you identify different issues if several occur during one project? It is helpful to number them so that you can identify issues easily when discussing them in progress meetings. • If change orders are needed, how will those be handled? • When the resolution affects the budget or schedule, what will the update process be, and who will be responsible? One of the key challenges of issues management is to resolve the problem quickly and then move on, with as little impact to the project as possible. The framework provides a structure for making decisions when issues arise. Remember to consider your team's needs as you develop the framework. It's also important to make sure you cover all issues in your PostImplementation Review . This is where you capture lessons learned for future projects. The more you learn about your issues, the better prepared you'll be for the next project. Some issues might occur again, so by recording what you've learned from previous projects, it will be easier for subsequent project teams to identify the issues, and resolve them successfully. Other issues might be part of a risk pattern that you can proactively identify and manage with early risk assessment.

Key Points An issues management process gives you a robust way of identifying and documenting issues and problems that occur during a project. The process also makes it easier to evaluate these issues, assess their impact, and decide on a plan for resolution. An issues log helps you capture the details of each issue, so that the project team can quickly see the status, and who is responsible for resolving it. When you add an issues management framework, you have a comprehensive plan to deal with issues quickly and effectively. This organized approach to managing issues provides many valuable insights that can be used to refine and improve future project results.

Download Worksheet

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Project Management Phases and Processes Structuring Your Project For all but the smallest projects, experienced project managers use well-established project management methodologies. These are often published systems – such as PMBOK (Project Management Body of Knowledge) or PRINCE2 – but they can also be in-house methodologies that are specific to the organization.

Control each project phase with an exit gate. © iStockphoto/Daft_Lion_Studio

These approaches have some differences in emphasis, and they tend to use slightly different terminology, but they generally share two key features: projects are delivered in stages, and certain common project management processes run across these stages. This is illustrated in figure 1, below. Figure 1 – Project Management Structure

This article explains these phases and processes in more detail.

Tip:

If any of the terms used in this article are unfamiliar to you, refer to our article Words Used in... Project and Program Management .

Project Phases Phases, or stages, are very important for project managers. By thinking in terms of phases, you can ensure that the deliverables produced at the end of each phase meet their purpose, and that project team members (or sub-teams) are properly prepared for the next phase. You identify the required deliverables for each phase from the Work Breakdown Structure (WBS) for it. The WBS is drafted as part of your preparation activities, and then validated by the rest of the project team. At the end of each phase, someone signs off on the deliverables from that phase. (In your preparation phase, think through who needs to approve each deliverable. Approvers may include the project board, project sponsor, or key stakeholders.) Once the deliverables are approved, the phase is completed and the project team can pass through the "gate" to the next phase. This is why the term "stage/gate" is used so often in project management. The exact phases, and the order in which they're completed, may vary slightly, depending on what you need to achieve with your project. The phases are as follows: • Project strategy and business case. • Preparation. • Design. • Development and testing. • Training and business readiness. • Support and benefits realization. • Project close. Let's explore each phase in more detail.

Project strategy and business case In this phase, you define the overall project business requirement , and propose the approach or methodology that you want to use to address it. The gate at the end of this phase is the approval of your high-level project proposal and of the business case that validates the approach you want to use. You must also show that you can achieve the project's goal within the required timelines and budget.

Tip:

Make sure that you review the business case at the end of each project phase to ensure that it’s still valid. If anything has changed, revise it as needed.

Preparation Here, you work with key stakeholders and project team members who have already been identified to establish and start the project: • Complete a high-level Work Breakdown Structure

.

• Determine the project's high-level plan at the milestone level . (Work with appropriate project team members to produce detailed plans at each subsequent phase. This ensures that they have a sense of ownership of these plans.) • Identify and recruit project members. • Produce the Project Initiation Document

.

• Select third parties to use in the early project phases (for example, IT subcontractors or partners). • Put actions in place to secure key resources. (For example, reserve rooms for the training phase, and allocate desks and PCs/ printers for the project team.)

Design I this phase you start the work involved with creating the project's deliverables, using the project strategy, business case, and Project Initiation Document as your starting point. Then work with relevant stakeholders to develop the designs of the main deliverables. In larger projects, you may use business analysts to help you with this. You probably have a project board or project sponsor who is responsible for signing off the overall design, but make sure you also get input from other stakeholders as well. This helps build business ownership of the project deliverables. If changes to processes are required, use a Flow Chart or Swim Lane Diagram to create a detailed map of how things will work. At this stage, you must do everything you can to think through and deal with project issues before you start to build project deliverables – problems are almost always easier and cheaper to fix at design stage than they are once the detailed work of implementation has started. Select stakeholders carefully for the detailed design phase. A good detailed design is more likely to lead to a good project deliverable. If the detailed design is poor, the project deliverables are much less likely to meet requirements! Tip:

For projects that have significant technical risks and uncertainties, consider including a feasibility or proof-of-concept phase. This

increases your certainty that what you're planning (probably at great expense) will work, while allowing you to cancel the project at minimum cost if the proof-of-concept fails.

Development and testing With all of the planning and designing complete, the project team can now start to develop and build the components of the project output – whether it's a piece of software, a bridge, or a business process. As part of this phase, you need to test these components thoroughly to confirm that they work as they should.

Training and business readiness This stage is all about preparing for the project launch or "go live." Do the following things during this phase: • Train users. • Put in place ongoing support. • Transfer data to new systems. • Identify what's required for the project to be effective from the launch date, and ensure that you adequately address this.

Support and benefits realization Make sure you provide transitional support to the business after the project is launched, and consider what's required before your team members are reassigned. Project teams are often assigned to other work too soon after the project has gone "live", meaning that project benefits are often not fully realized. Monitor the delivery of project benefits . You can use this to promote your project or to give you information about other actions needed to ensure that the project is successful. You can monitor benefits as part of "business as usual" activities, and you should (ideally) continue to do so after the project is closed.

Project close Closing a project is not the most exciting part of the project lifecycle, but, if you don't do it properly, you may obstruct the ongoing delivery of benefits to the organization. Make sure you do the following: • Complete and store documentation. • Carry out a Post-Implementation Review , so that you and your colleagues can use the experience you've gained in future projects. • Use your business connections to reassign project team members to appropriate roles in the organization. You don't want to lose the experience and knowledge that they've gained from working on the project.

Project Management Processes The key project management processes, which run though all of these phases, are: • Phase management. • Planning. • Control. • Team management. • Communication. • Procurement. • Integration. Let's look at each process in more detail. • Phase management – Here, you ensure that you adequately satisfy the conditions for completing each phase, and for starting the next one. To do this, make sure that you fully understand the "gates", or deliverables that must be completed and approved by the appropriate stakeholders before you can exit a phase. Deliverables and sign-off requirements are usually identified in the Project Initiation Document , so review this appropriately during the project. • Planning – Carry out high-level planning for the whole project at the start of the project, then do more detailed planning for each phase at the start of each phase. Ensure that you have the right people, resources, methodologies, and supporting tools in place for each planning phase, so that you can deliver the project on time, on budget, and to appropriate quality standards. • Control – It's essential to control scope , cost , and issues ; and to manage time, risks , and benefits effectively. Create reports that contain the information you need to create an accurate picture of how things are proceeding. A common way of doing this is to use a Project Dashboard . • Team management – As project manager, you are responsible for managing the project team. Working on a project is often different from most "business as usual" activities, and project work may require a different approach and set of skills. As such, you'll probably need specific project management training and support. And there are additional complexities in managing team members who have project responsibilities as well as other roles at the same time (see our article on Managing CrossFunctional Teams for more on this). • Communication – Make sure that you're clear about who is responsible for communicating to team members, the project board, the different stakeholders within the business, and relevant third parties. Inadequate communication is a frequent problem area for projects, and it needs considerable attention to communicate well. Our articles on communication skills are a useful starting point for developing these essential skills. • Procurement – This is a specialist area. Many projects hire third parties to manage purchasing, particularly when it involves IT

systems. Managing these third parties is often the role of the project manager. See our articles on Request for Proposal Documents and Procurement Management for more on this. • Integration – Many projects do not stand on their own within an organization – they often impact other areas of the business. Make sure that you consider how your project will interface with other projects or functions.

Key Points Formal project management involves following an established project management methodology. In turn, most of these methodologies follow a set of common project phases, with common processes that run across each phase. To explore project management further, take our Bite-Sized Training session, What is… Project Management?

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... James wrote Hi Brynn Glad that we've been able to help!

James December 8, 2009 ladyb wrote What a great article! I've got a copy of the PMBOK sitting on my desk, it's probably been there for years and I get so frazzled by the complexity and detail of it. Your summary is exactly what I need to get organized and set myself up for the planning stages. I resist project planning because I've never had a real good yet simple big-picture view. Now I do! Thanks!!! Brynn December 7, 2009

Return to top of the page

Project Milestone Reporting Keeping Projects on Track by Monitoring Significant Check Points Many managers will have been in situations in which they're told that work is "80% done" at a certain stage of a project, only to find that that project then massively and embarrassingly over-runs by weeks or even months. This is because the last 20% of the work takes longer than planned.

A significant point along the way. © iStockphoto/amygdala_imagery

If you've ever been in this situation and suffered the painful consequences, you'll know why experienced managers carefully monitor how actual completion dates compare against planned completion dates at certain "milestones" within projects. This allows them to take corrective action, or manage people's expectations appropriately, and this is where Project Milestone Reporting becomes important. A real life milestone is a marker that tells you how far you are from a certain point – so you know how far you have come, or how far you have to travel. Project Milestones perform exactly this role in a project plan. They mark significant events, deliverables or interdependencies that needs to be monitored to keep the project on track. Project Milestone Reports show you what has been achieved and what else needs to be done to complete your project successfully and on time. Project Milestone Reporting is just one of many ways to monitor and present the status of a project. It's a useful approach in large or complex projects (with many interdependencies) because it helps present information in a meaningful yet concise way, showing what has actually been achieved, rather than the gory detail of how it's been achieved. This article helps you think about how you want milestones to be reported to you. Tip 1:

Many organizations have specific approaches and methodologies for managing projects, and for reporting their progress and status. Before you specify a completely new approach, see if any of the existing approaches meet your needs.

Tip 2:

Remember that it takes time to prepare these reports. If you ask for too much detailed information, or ask for information you don't actually need, you'll diminish the effectiveness of the manager or team member preparing the report. After all, time spent reporting is time not spent working on the project! Project milestone reports come in many different forms. Some are narrative reports. Others are quantitative or graphical, using spreadsheets or project management software to manage the milestone data and track progress and completion. If your team uses project management software, the chances are the software will help them prepare milestone reports in a particular way, and it's best to make the most of these in-built features if you can. If you need to design your own milestone report, our template is a good place to start. Together with the report description below, it will help you understand the principles of project milestone reporting in more detail, and so help you use this reporting tool in the best way for your project.

Creating a Milestone Report Start by downloading our free project milestone report template. This contains all of the elements typically found on a milestone report. The first part of a milestone report ("Milestones Completed") describes what has happened so far. It provides a quick summary of what has been accomplished and when. Description of Milestone: Here you provide details about what was accomplished in order to complete the milestone specification. Due Date: Record when the milestone was due according to the current project plan. Actual Completion Date: Record when the milestone was actually accomplished. Comments: This section is for providing details about modifications from the original plan i.e. why the due date was missed or why deliverables were changed. Tip 3:

Insist that deliverables are only shown as completed when they are 100% completed. 99% still leaves wriggle-room, and is not good enough!

Tip 4:

Make sure you inspect a selection of the completed deliverables to make sure they actually are completed, and are completed to an acceptable quality. The next section is used to report on the status of Future Milestones. Here you want to make note of the status of the milestones and understand changes to the original plan should they be necessary. Remember, milestones are critical events, so by reporting on their status you give yourself a formal method to modify the master project plan before too many tasks and responsibilities get off course. Description of Milestone: What has to be accomplished in order for the milestone to be considered complete? Due Date: What is the due date of the milestone based on the original plan (or previously modified plan)? Status: Here you record whether the milestone is on target, is at risk of getting off target, or is already off course. Our sample report uses a Green, Amber, Red system but that can be modified to suit the particular situation. Modified Due Date: Modifying a milestone due date is a last resort option. If this is necessary, record the modified due date. Remember that changes to milestones often mean changes to other dates in the project plan. Required Actions: This is where you note what needs to be done to bring a milestone back on target and/or the repercussions of having to modify a due date and what has been done to address those issues. Tip 5:

Make sure the time spent completing Milestone Reporting provides benefit to the project. This means that you should continually assess whether it is worthwhile for your project and, if you decide that it is, include only the elements that will help you keep your project on target.

Key Points Milestone reports help you monitor the progress and outcomes of projects you are watching over, so that you can take corrective action where necessary. They are also a valuable control checkpoint that helps the project manager keep all the pieces of a project working smoothly and in co-operation with one another. The format of a milestone report varies from organization to organization but the content remains quite similar: Milestone

descriptions, a note of their status, and relevant comments. When it's complete, one short report will show you the status of every milestone, and help you to plan and prepare accordingly.

Download Worksheet

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... dazzle359 wrote Excellent tool and so important. Seeing those first milestones completed in a project is motivation to continue. Also provides site of the goal (or endpoint). April 19, 2007 dp7622 wrote I really like this report format - simple, easy, and very clear. I'm going to use this with my current project. Thanks!

Don Powell April 19, 2007

Return to top of the page

Project Schedule Development Planning the Timing and Sequence of Project Activities Can you imagine starting a long car trip to an unfamiliar destination without a map or navigation system? You're pretty sure you have to make some turns here and there, but you have no idea when or where, or how long it will take to get there. You may arrive eventually, but you run the risk of getting lost, and feeling frustrated, along the way.

Schedules specify the sequence of project tasks. © iStockphoto/AndrewJohnson

Essentially, driving without any idea of how you're going to get there is the same as working on a project without a schedule. No matter the size or scope of your project, the schedule is a key part of project management. The schedule tells you when each activity should be done, what has already been completed, and the sequence in which things need to be finished. Luckily, drivers have fairly accurate tools they can use. Scheduling, on the other hand, is not an exact process. It's part estimation , part prediction, and part 'educated guessing.' Because of the uncertainty involved, the schedule is reviewed regularly, and it is often revised while the project is in progress. It continues to develop as the project moves forward, changes arise, risks come and go, and new risks are identified. The schedule essentially transforms the project from a vision to a time-based plan. Schedules also help you do the following: • They provide a basis for you to monitor and control project activities. • They help you determine how best to allocate resources so you can achieve the project goal. • They help you assess how time delays will impact the project. • You can figure out where excess resources are available to allocate to other projects. • They provide a basis to help you track project progress. With that in mind, what's the best way of building an accurate and effective schedule for your next project? Project managers have a variety of tools to develop a project schedule – from the relatively simple process of action planning for small projects , to use of Gantt Charts and Network Analysis for large projects . Here, we outline the key tools you will need for schedule development.

Schedule Inputs You need several types of inputs to create a project schedule: • Personal and project calendars – Understanding working days, shifts, and resource availability is critical to completing a project schedule. • Description of project scope – From this, you can determine key start and end dates, major assumptions behind the plan, and key constraints and restrictions. You can also include stakeholder expectations, which will often determine project milestones. • Project risks – You need to understand these to make sure there's enough extra time to deal with identified risks – and with unidentified risks (risks are identified with thorough Risk Analysis). • Lists of activities and resource requirements – Again, it's important to determine if there are other constraints to consider when developing the schedule. Understanding the resource capabilities and experience you have available – as well as company holidays and staff vacations – will affect the schedule. A project manager should be aware of deadlines and resource availability issues that may make the schedule less flexible.

Scheduling Tools Here are some tools and techniques for combining these inputs to develop the schedule: • Schedule Network Analysis – This is a graphic representation of the project's activities, the time it takes to complete them, and the sequence in which they must be done. Project management software is typically used to create these analyses – Gantt charts and PERT Charts are common formats. • Critical Path Analysis – This is the process of looking at all of the activities that must be completed, and calculating the 'best line' – or critical path – to take so that you'll complete the project in the minimum amount of time. The method calculates the earliest and latest possible start and finish times for project activities, and it estimates the dependencies among them to create a schedule of critical activities and dates. Learn more about Critical Path Analysis . • Schedule Compression – This tool helps shorten the total duration of a project by decreasing the time allotted for certain activities. It's done so that you can meet time constraints, and still keep the original scope of the project. You can use two methods here: • Crashing – This is where you assign more resources to an activity, thus decreasing the time it takes to complete it. This is based on the assumption that the time you save will offset the added resource costs. • Fast-Tracking – This involves rearranging activities to allow more parallel work. This means that things you would normally do one after another are now done at the

same time. However, do bear in mind that this approach increases the risk that you'll miss things, or fail to address changes. Use of Project Stages:

One of the biggest reasons that projects over-run is that the 'final' polishing and error-correction takes very much longer than anticipated. In this way, projects can seem to be '80% complete' for 80% of the time! What's worse, these projects can seem to be on schedule until, all of a sudden, they over-run radically. A good way of avoiding this is to schedule projects in distinct stages, where final quality, finished components are delivered at the end of each stage. This way, quality problems can be identified early on, and rectified before they seriously threaten the project schedule.

Project Review Once you have outlined the basic schedule, you need to review it to make sure that the timing for each activity is aligned with the necessary resources. Here are tools commonly used to do this: • 'What if' scenario analysis – This method compares and measures the effects of different scenarios on a project. You use simulations to determine the effects of various adverse, or harmful, assumptions – such as resources not being available on time, or delays in other areas of the project. You can then measure and plan for the risks posed in these scenarios. • Resource leveling – Here, you rearrange the sequence of activities to address the possibility of unavailable resources, and to make sure that excessive demand is not put on resources at any point in time. If resources are available only in limited quantities, then you change the timing of activities so that the most critical activities have enough resources. • Critical chain method – This also addresses resource availability. You plan activities using their latest possible start and finish dates. This adds extra time between activities, which you can then use to manage work disruptions. • Risk multipliers – Risk is inevitable, so you need to prepare for its impact. Adding extra time to high-risk activities is one strategy. Another is to add a time multiplier to certain tasks or certain resources to offset overly optimistic time estimation. After the initial schedule has been reviewed, and adjustments made, it's a good idea to have other members of the team review it as well. Include people who will be doing the work – their insights and assumptions are likely to be particularly accurate and relevant.

Key Points Scheduling aims to predict the future, and it has to consider many uncertainties and assumptions. As a result, many people believe it's more of an art than a science. But whether you're planning a team retreat, or leading a multimillion-dollar IT project, the schedule is a critical part of your efforts. It identifies and organizes project tasks into a sequence of events that create the project management plan. A variety of inputs and tools are used in the scheduling process, all of which are designed to help you understand your resources, your constraints, and your risks. The end result is a plan that links events in the best way to complete the project efficiently.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... crissmc wrote Scheduling is, to me, the hardest part of project management. "80% complete for 80% of the time" is so true. Good article. Thank you January 9, 2009

Return to top of the page

Rationalizing Your Project Portfolio Delivering Strategic Benefits With Limited Resources You've submitted the budget for the projects you’ll be working on for the next six months. But the head of your Strategic Program Office has just called to say that you just can’t do all of that! Why? Well, it’s not because he's questioning the benefit of What should you prune? these projects – after all, the © iStockphoto/LianeM business case of each one has already been approved. The problem is that funds are limited and the portfolio as it stands needs more cash than you’ve got. You now need to re-work your overall plan to reduce the costs by 15%. So how do you decide which projects to keep, and which ones to delay or abandon? This article gives you a robust process for doing just that.

How to Use the Tool Follow these steps to rationalize your project portfolio:

Stage 1: Preparation Step 1 – Understand the Business Plan

Your projects should have been designed to contribute – directly or indirectly – to the delivery of your organization’s business plan . So the first thing you need to do is understand that plan fully, so that you can make informed decisions about how to shrink your project portfolio. If you don’t, and you cut a project you didn’t realize was strategically important as a result, you risk making it impossible for the business plan to be implemented. Note:

You might think that if the whole original project portfolio was needed to implement the business plan, then it’s going to be impossible to deliver the plan if that portfolio is reduced. This isn’t necessarily the case, as you’ll see later on in this article. Step 2 – Understand Your Scarce Resources

Next, you need to be quite clear about what has changed. What has driven the need to rationalize your project portfolio? Which resources are now scarce?

You should focus tightly on reducing usage of these resources in the steps that follow. The flip side of this is that you may want to increase your use of other resources to compensate, so you need to know exactly what these are too. In the example we gave at the beginning of this article the scarce resources was cash. In other situations, people/expertise, equipment or even time could also be more limited than you had originally thought. Some definitions:

The word program is used differently in different organizations, but a generally accepted meaning is that a program is a group of related projects, many of which are being worked on simultaneously. For example, a consumer financial services organization might have a savings program, made up of the projects needed launch different savings products. A project portfolio, on the other hand, is a set of generally unrelated projects or programs designed to deliver an overall plan. At the highest level, your organization’s business plan is delivered through a project portfolio. This could include a new products program (with savings programs within it), but also an office relocation project, and a server replacement program, say.

Stage 2: Identify Possible Changes to You Project Portfolio The steps in this stage are iterative rather than sequential. You need to investigate what you could do first, and note the implications that each would have on other projects' scopes, delivery timescales, costs, benefits, risk profiles, and impacts; and on the overall business plan. You then need to go back through the steps and keep on tweaking until the scope of your project portfolio is acceptable. Tip:

There are often unspoken conditions attached when senior managers ask for cost reductions, however these might not be immediately obvious to them or you. Make sure that you understand if it’s acceptable to reduce the benefits being delivered or increase project timescales, say, so that you can come up with viable changes. Step 3 – Review Which Projects are Essential and Which are "Nice to Have"

The easiest way to reduce costs, and reduce pressure on scarce resources, is to stop projects. Review your project list – is there anything that you can do without? When conditions get tougher you can often view your proposals more critically, and see things that you can actually do without.

Tip 1:

When business planning is poor, leaders often approve "pet projects." These are projects that they like or favor the most, but are not necessarily the projects that are the most needed. Look out for these! Whilst it may be “politically” difficult to cut these, delaying or removing them from your portfolio is likely to give you the biggest gains towards your rationalization target. Tip 2:

That said, individual managers within your organization will have invested a lot of time, credibility and emotional energy in getting projects within the portfolio approved. Clearly, changing, deferring or canceling these projects could cause a great deal of anger and frustration. Be sensitive in the way you talk about projects; ensure that senior managers are involved in communicating both the need for rationalization and the detail of how it will be achieved; and make sure that you communicate with key stakeholders appropriately to develop the best possible plan (read our article on stakeholder management for more information on this). Step 4 – Extend Project Timescales

Another relatively straightforward way to reduce the demands on cash flow, people or equipment is to extend the timescale of individual projects. The basic question is: Could the whole project be delivered later and still achieve the same benefit? For example, if your project was to upgrade all of your organization’s PCs in 6 months, could this be done over 12 months instead? Or could a product upgrade be launched in June instead of January? A variation on this is to phase the project: Rather than doing everything now, the project could be delivered in phases. This phasing can be organized in a number of different ways, for example: • Geographically/by market sector: Rather than implementing a new product everywhere in the world this year, could it be launched in the US now, and in the rest of the world next year? Could the new product be launched via independent financial advisors now, but for Internet-based sales later? • Functionally: Could Marketing and Finance have their PCs upgraded now, but Production be delayed until next year? • By scope: Could the essential components of the new system be delivered now, and the rest delivered as “upgrades” later? Extending the timescale quite often results in the project costing more in the end, but if this isn’t the prime consideration, that may be acceptable.

Step 5 – Adjust Your Portfolio

Your overall project portfolio should have been designed to deliver your organization’s business plan. But, with the rolling nature of projects, it’s easy for this to become misaligned. So your next task is to assess whether the overall mix of projects and programs in the portfolio really has the right scope to deliver the benefits that your organization needs. Analyze the projects in terms of: • Benefits: Prioritize the projects according to the size of benefits delivered and how closely these fit strategically with the business plan. Which projects are essential (with high-value benefits that deliver a core part of the business plan), and which are more peripheral? • Funding: Review the funding that's required for each project. Which projects will give the best benefits for the investment? If cash flow is important, do a cash flow forecast for the project lifecycle. Do any of the projects have a particularly worrying funding profile? • Scope: Do any of your projects have unnecessary scope? Do any of them overlap? Could the scope (and therefore the demands on scarce resources) of any projects be reduced without reducing the overall scope of the portfolio? • Risk: Understand the risks involved with each project. In general, projects that offer a high return tend to be more risky. When you're rationalizing a portfolio, it's tempting to cut out projects that deliver the lowest benefits, however these are often the lowest risk projects. By cutting them, you increase the overall risk in the portfolio. This is important, because if you are pursuing too many high-risk projects at the same time, there’s a danger that some will fail, or that you’ll need all of your best people to ensure that the projects do deliver! Your analysis in each of these areas will likely come up with differing, though overlapping priorities. Keep cycling through these four areas until you come up with the best mix of prioritized, reshaped projects.

Key Points It’s a common occurrence – usually during an organization’s budgeting process – that program or project portfolio managers need to reduce the amount of resource that their projects are using. Right now, cash is probably the most scarce resource, but lack of availability of key individuals or equipment can also mean that project portfolios need to be scaled back. Rationalizing a project portfolio is an iterative process. You can reduce the scope of individual projects, extend them to reduce the intensity with which they use scarce resources, you can delay projects, and you can cancel them altogether. By carefully balancing various aspects of the project portfolio, you can often

deliver the required strategic benefits despite rationing scarce resources.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Request for Proposal Documents Getting Better Terms With a Competitive Bidding Process All too often, organizations have problems with their suppliers. Sub-standard goods, tardy deliveries, inflated prices, and disrupted supply chains can all have an obvious adverse impact on your organization's success. So how can you help your company overcome these problems?

Getting the best possible solution. © iStockphoto

How can you get the best possible product for the lowest possible price? And how can you ensure that your business needs will be met on a timely and assured basis? Part of the solution lies in starting the relationship with your supplier with a competitive bidding process, by issuing a well-crafted Request for Proposal (RFP) to the market. This competitive bidding process seeks the best possible quotes for required products/services from vendors, measured using common set of standards. The RFP, also referred to as Invitation to Tender (ITT) or Request for Information (RFI), forms the cornerstone of this bidding process. A formal, written document, the RFP outlines information about the organization, and details the products and services to be sourced from external vendors. It lays out the specific requirements that vendors need to keep in mind when responding to the bid, and outlines how the company will review and award the proposals received. Although creating a RFP can be a long, drawn-out process, it is well worth the effort for large one-off purchases, and for ongoing supply contracts. In these cases, it yields many benefits: • It provides a detailed lead for vendors. They are therefore are able to respond with their most competitive, comprehensive quotes in terms of both quality and pricing. • Depending on how it is advertised, it allows for wide distribution to many suppliers, and thus ensures that you get the bestmatched product for your needs. • It clearly outlines the risks and benefits upfront. This ensures that only dedicated suppliers, interested in a stable relationship, apply for the contract. This translates into a more reliable supply chain.

• Since an RFP essentially reflects your organization's needs in writing, it formalizes the relationship between you and your supplier and puts you in control over the desired levels of service. • It lends clarity to any issues involved, because you identify these up front. • It provides a common standard against which to compare each bid submission. Because the format that suppliers reply in is the same, it makes it much easier to compare solutions than it would otherwise be.

Creating an RFP Now comes the key question – how do you create a RFP? Procurement requirements vary from industry to industry and company to company. Within one company they also differ for different products and services. Given this scenario, is there any general framework you can apply to create a competitive bid? Yes! While the specifics are unique to each situation, if you follow the steps below, you'll be able to issue a competitive bid in the marketplace.

Step 1: Look for Proven Formats in Your Industry If you're operating within an established company or industry, the chances are that there are established and proven RFP formats that you can draw on. Spend some time researching these. If they do, consider whether they're appropriate, and if they are, use them as a starting point for your RFP. For example, if you're sourcing a new IT system, use an RFP format that specializes in this – your IT department will point the way, and your RFP process will be much richer as a result. And if you need an extension to your office, use an approach used in the construction industry – an architect can help you out here. You can save yourself a great deal of pain by using other people's skills, and by learning from their experience! Tip:

If you find an existing RFP format, make sure it covers the points below. And consider using these as a starting point for less formal RFPs, or for RFPs in industries that don't have established formats.

Step 2: Analyze Your Requirements Start by defining exactly what you want to buy. This includes: What are you looking to source and at what price? Gathering all the information regarding the bid will enable you to make a sound and factual estimate for the value of your RFP.

• Deliverables: What do you want delivered? Make sure that you spend plenty of time talking to the key people involved, so that you can identify and document all of the requirements. • Scope: What is the scope of your requirements? Do you need ongoing support after the installation of a piece of machinery or an IT system, for example? • Timing: Is there a business-critical deadline by which you need to have received the goods or services? • Vendor evaluation criteria: What are the factors you need to consider, so that you get the best possible vendor, at the most competitive price, with the most suitable product? What are the criteria you will use when deciding which supplier you'll award the contract to? This could be just price, or a combination of price, delivery, quality and past experience. • Constraints: Are there any risks associated with the project? What factors will affect the quality of the product or service you want? What are the factors that can impact time schedules?

Step 3: Construct the RFP Initial analysis over, we move to the drafting stage. All the data you've gathered now needs to be converted into the RFP. The key point to keep in mind at this stage is that the RFP is much more, than a request for a price. It must elicit information that will enable to evaluate the capability and trustworthiness of the supplier to deliver what you require – which may need to take place over an extended period. Most RFPs will include the following headings (or similar ones): • Executive Summary: This covers the entire requirement, as well as some brief background information about your company so the vendors are aware of the basic nature of your firm. The objective here is to showcase your importance as a buyer. • Project Description: An overview of the project or business activity that the product or service sought will feed into, and the objectives of that project or ongoing activity. • Design and Functional Requirements: Be very precise. The more detailed the specifications are, the more accurately matched a response you will get. (However, remember that there can be different ways of achieving the same result – don't specify the solution so closely that you exclude valid options.) • Request for supplier details: It is essential that you get information about the vendor's competence and experience. References are helpful here, as are profiles of named individuals who will be carrying out work included in the deliverables. You also need a summary of the vendor's corporate history and financial details that will allow you to assess their financial stability. You also need to know the vendor's capacity to deliver and their estimated delivery time. This will help you assess whether the vendor will be able to support your required time schedules. You can also cover this area under a prequalification screening if you

want to narrow down the list of vendors you eventually want to distribute the bids to. • Your contractual terms and conditions. • Any other specific information, assumptions and clarifications. • Evaluation criteria: You may wish to inform vendors about the bid evaluation criteria on which they will be analyzed. You may also want to let them know any other specific requirements, terms and conditions you might have. • Submission guidelines: Make sure that your RFP document includes the name and contact details of the person to whom bids should be submitted, and any other logistical details such as the format of submissions required (hard copy or pdf, for example, and if hard copy, how many copies you want). • Dates: The RFP should define timelines such as the proposal return dates, project award date, project start date and any other such date you consider important. Tip 1:

Some people recommend specifying expected price ranges within RFPs. While this may be useful in some situations, no supplier worth its salt is going to quote below the bottom of a stated price range, and many may pitch their projects to fully use the maximum budget. In many cases, you'll get best value if you conceal the project's budget from suppliers. Tip 2:

Responding to RFPs can take up a lot of time, and suppliers may choose to prioritize RFPs where they have a good relationship with the potential client. Don't be arrogant in the way you treat suppliers, ensure that they have the information they need, and make sure that they have a fair amount of time to respond. The last thing you want is to spend weeks preparing an RFP, and then to have only one supplier respond.

Step 4: Logistics Think about what type of supplier is likely to be able to meet your needs. How can you get the RPF to that supplier? Is there a suitable website on which you can advertise it, or should you contact a shortlist of potential suppliers directly?

Key Points An RFP is a formal written document inviting vendors to bid for a specific product or service that you require. It should detail the company background and the deliverable desired, and should give guidelines as to how the vendors should respond. The RFP should also be used to seek details that establish the vendor's reliability.

A well-managed RFP process helps you get best value for your organization's money. It helps you procure the best products and services, at the most competitive prices, with the greatest reliability.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... amerlo wrote Don tks for your reply...it sounds good and to be honest it is one of the ideas we found suitable to accomplish our goal, but we have found very encountered opinions in terms of how to stipulate an standard for the fact to add value and its condition of intangible. Our main concern at this point is how to put in written text over the RFP document the desired level of value added i.e. we need to get assigned the best people from the consulting team, and it makes a big difference from the rest of the consulting firm employees Hope I could explain better the barriers we are dealing with... Again TKS ! [quote="dp7622":3on9lgbx]Hi amerlo

What about including a paragraph in the evaluation criteria section that specifically talks about the importance of value added activities and philosophies. Even making a statement that these "intangibles" are seen as important criteria that will be assigned a monetary value in terms of evaluating the bids received. The suppliers should then realize how serious you are about this stuff and know they are expected to indicate what else their company offers over and above the stipulated products and service. Don Powell March 31, 2008 dp7622 wrote Hi amerlo What about including a paragraph in the evaluation criteria section that specifically talks about the importance of value added activities and philosophies. Even making a statement that these "intangibles" are seen as important criteria that will be assigned a monetary value in terms of evaluating the bids received. The suppliers should then realize how serious you are about this stuff and know they are expected to indicate what else their company offers over and above the stipulated products and service. Don Powell March 30, 2008 amerlo wrote Hi All Could you kindly share with me your comments about how to include into an RFP the added value a supplier or vendor is providing to my company ? I mean...we are working directly with 3 of the ex-big six...so we are thinking seriously in starting an RFP process but we have many different opinions on this specific point of "value added"...it's a matter of intangibility I think but your comments will be very appreciate. TKS ! March 30, 2008

Return to top of the page

Risk Impact/Probability Chart Learning to Prioritize Risks Risk management is an important function in organizations today. Companies undertake increasingly complex and ambitious projects, and those projects must be executed successfully, in an uncertain and often risky environment. As a responsible manager, you need to be aware of these Preparing sufficiently for the worst. risks. Does this mean that you © iStockphoto should try to address each and every risk that your project might face? Probably not – in all but the most critical environments, this can be much too expensive, both in time and resources. Instead, you need to prioritize risks. If you do this effectively, you can focus the majority of your time and effort on the most important risks. The Risk Impact/Probability Chart provides a useful framework that helps you decide which risks need your attention.

How to Use the Tool The Risk Impact/Probability Chart is based on the principle that a risk has two primary dimensions: 1. Probability – A risk is an event that "may" occur. The probability of it occurring can range anywhere from just above 0 percent to just below 100 percent. (Note: It can't be exactly 100 percent, because then it would be a certainty, not a risk. And it can't be exactly 0 percent, or it wouldn't be a risk.) 2. Impact – A risk, by its very nature, always has a negative impact. However, the size of the impact varies in terms of cost and impact on health, human life, or some other critical factor. The chart allows you to rate potential risks on these two dimensions. The probability that a risk will occur is represented on one axis of the chart – and the impact of the risk, if it occurs, on the other. You use these two measures to plot the risk on the chart. This gives you a quick, clear view of the priority that you need to give to each. You can then decide what resources you will allocate to managing that particular risk. The basic form of the Risk Impact/Probability Chart is shown in figure 1, below.

Figure 1 – The Risk Impact/Probability Chart

The corners of the chart have these characteristics: • Low impact/low probability – Risks in the bottom left corner are low level, and you can often ignore them. • Low impact/high probability – Risks in the top left corner are of moderate importance – if these things happen, you can cope with them and move on. However, you should try to reduce the likelihood that they'll occur. • High impact/low probability – Risks in the bottom right corner are of high importance if they do occur, but they're very unlikely to happen. For these, however, you should do what you can to reduce the impact they'll have if they do occur, and you should have contingency plans in place just in case they do. • High impact/high probability – Risks towards the top right corner are of critical importance. These are your top priorities, and are risks that you must pay close attention to. Tip 1:

It's natural to want to turn this into a two-by-two matrix. The problem here is where the lines dividing the quadrants of the matrix lie. For example – should you ignore a 49 percent probability risk, which will cause a 49 percent of maximum loss? And why, in this example, should you pay maximum attention to a

risk that has a 51 percent probability of occurring, with a loss of 51 percent of maximum loss? Tip 2:

In some industries, you need to pay close attention to even very unlikely risks, where these risks involve injury or loss of human life, for example. Make sure you pay due attention to these risks. To use the Risk Impact/Probability Chart, print this free worksheet, and then follow these steps: 1. List all of the likely risks that your project faces. Make the list as comprehensive as possible. 2. Assess the probability of each risk occurring, and assign it a rating. For example, you could use a scale of 1 to 10. Assign a score of 1 when a risk is extremely unlikely to occur, and use a score of 10 when the risk is extremely likely to occur. 3. Estimate the impact on the project if the risk occurs. Again, do this for each and every risk on your list. Using your 1-10 scale, assign it a 1 for little impact and a 10 for a huge, catastrophic impact. 4. Map out the ratings on the Risk Impact/Probability Chart. 5. Develop a response to each risk, according to its position in the chart. Remember, risks in the bottom left corner can often be ignored, while those in the top right corner need a great deal of time and attention. Read Risk Analysis and Risk Management for detailed strategies on developing a risk response plan.

Key Points To successfully implement a project, you must identify and focus your attention on middle and high-priority risks – otherwise you risk spreading your efforts too thinly, and you'll waste resources on unnecessary risk management. With the Risk Impact/Probability Chart, you map out each risk – and its position determines its priority. High-probability/highimpact risks are the most critical, and you should put a great deal of effort into managing these. The low-probability/high-impact risks and high-probability/low-impact risks are next in priority, though you may want to adopt different strategies for each. Low-probability/low-impact risks can often be ignored.

Download Worksheet

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Hi Icham, I'm not sure there is any one person or organization credited with developing the Risk Impact/Probablity Chart. It appears to have evolved quite organically and stems from the philosophy that risk=probability*impact. I read in a couple sources on the web that it has been around since the 50s and 60s and originated in the the healthy and safety industry. Is there a reason you are looking for the creator? Dianna May 15, 2013 lcham wrote Does anyone know who the creator of this method of measuring risk was? May 13, 2013 dp7622 wrote I don't see the problem hjb. When you assess risk you assess it from a variety of perspectives therefore the direction of impact is

expected to change. So the impact, regardless of impact on what or who, is important regardless, right? What am I missing? And although I agree probability of risk and impact of risk are not related to one another in that they don't correlate negatively or positively, they are still dimensions important to risk prioritization. I want to be concentrating on risk that is highly probable and that is associated with a significant negative impact. If it's risky, the probability and impact have to be somewhere in the plot so knowing where on the plot seems inherently useful. Am I really being obtuse or what? May 22, 2008 hjb123 wrote Some problems with the Impact X Probability model............. 1. There is no logical relationship between Probability and Impact each is important but not related. 2. Impact on what? One often hears of impact on the schedule, the cost etc. The schedule does not care, the cost does not care, the project does not care. Any impact only has meaning when related to a stakeholder in the project - to one person impact on cost is the most important thing to another it will be time, etc. 3. Any risk that is more than 50% probable is not a risk, by definition it is going to happen, so treat it as a part of the project plan and not part of the risk plan. If we removed all risk items that were more than 50% likely top happen away from the risk register and into the project plan then most risk registers would be pretty small Lastly, has anyone noticed the direct relationship between the riskiness of a project and the time spent doing risk analysis? One way of increasing the riskiness exponentially is to devote even more time to defining the risks. Seriously though, if we applied more rigorous and meaningful formulae and effort to risk management we might get somewhere - we might start by checking how much we and our colleagues understand about probability - but we probably won't!

May 22, 2008 mayc wrote That's a great way to conceptualize the idea of prioritizing risk. I've tended to do this in my head but I like the idea of graphing it. I can see it being really useful for communicating risk. Picture speaks a thousand words sort of thing. I think I might also use it as a tool my staff can provide to me to show the work they've

done on project risk analysis. May 9, 2008

Return to top of the page

Scope Control Avoiding Too Many Changes in Projects Have you ever been on a project that seemed to develop a life of its own? Suddenly, instead of one key objective, you had to take care of three secondary objectives before you could get back on track – and then you couldn't finish on time? Let's look at a home repair Controlling which project changes you accept. example. You want to replace © iStockphoto your kitchen countertop. But then you think the back tiling could be updated and replaced too. And you certainly can't replace the countertop without a new sink and faucet. Oh no – the sink you want doesn't fit into the old space. OK, you'll just move the plumbing pipes, right?! Before you know it, you've torn apart your whole kitchen, and you're waiting for new cabinets, appliances, and flooring. You're trying to figure out how you'll live in a house with no kitchen for the next six weeks, and you don't know how you'll pay for all these little extras and upgrades that seemed like a good idea at the time. Have you ever experienced this with a business project? Projects can quickly grow beyond their initial boundaries if you don't carefully control changes to them. It's called "scope creep" – new objectives and needs "sneak up" on you with no warning. This can lead to the following: • An extended project schedule – You need extra time to explore the new requirements and then complete the work. • Increased project costs – More time and additional requirements often mean higher costs. • Decreased overall value – Project stakeholders expect results on time and on budget, so when you don't deliver, they're not satisfied. To minimize the risk of scope creep in your projects, you need to take appropriate measures to manage the scope of the project, and keep it under your control.

Scope Creep Management Control is the key. Projects can and will change. Almost inevitably, as you begin work, you'll discover situations and results that you didn't anticipate. You could decide to adopt a "no change" policy and complete the project exactly the way you originally intended. However, you'd probably miss ways to improve the project outcome.

The objective of scope control is to anticipate as many of these potential changes as possible before they happen, and then have a process in place to evaluate and accept only those changes that are reasonable and appropriate. Furthermore, it provides a framework within which stakeholders can understand the cost and delay that changes involve, and decide whether or not these are acceptable. Scope change and scope creep are not the same. They each refer to modifying the original requirements, specifications, or objectives. However, the difference is this: scope change is achieved through a defined process, but scope creep happens without a plan. You control scope change – but scope creep controls you!

Strategies for Controlling Scope Creep Scope control starts well before a project begins. It's built into the project plan, and it allows you to maintain power over what happens, when it happens, and why it happens. Try the following to help control the scope of your project: • Develop a clear project vision – You need to understand why the project is important. • What underlying need will be met if your project is successfully executed? • How complete is your vision? Create prototypes, talk directly to key stakeholders, and include end-users in the planning and development process. The more complete your vision, the tighter your initial project plan will be. • Determine project priorities – Which elements of the project are most important to the project's sponsors and stakeholders? • What "must" you have, and what would be "nice to have"? • What is most important? Is completing the project on time more important than completing it within your budget? Where does customer satisfaction fit in? Is it better to schedule extra time to gather customer feedback – or do you want to roll out the product quickly, and then make changes later? • What risks are associated with your priorities and tradeoffs? • Formally define the project's requirements – Conduct a business requirements analysis . This is a structured process for understanding the fine detail of what's needed within the project, and for agreeing this with everyone involved. • Create a detailed schedule with major milestones – Use this to allocate resources and build in extra time for the unexpected. This can give you flexibility to assess and implement legitimate scope changes. Tools like GANTT charts , PERT charts , and Work Breakdown Structures can be used for effective scheduling.

• Develop a process to manage scope changes – You'll probably be asked to change the scope at some point, so set clear guidelines for evaluating and executing changes. • What criteria will you use to evaluate proposed changes? • How will you manage the change process? • How will you assess any risks that proposed changes may bring, and how will you manage these? • How will you assess the impact of the change on the business case for the project? • How will you document your changes and how they affect the project over time? • Who will sign off on changes? • How will you communicate your scope change plan to all stakeholders and get agreement from them? Address this issue with the project sponsor early on, and gain agreement that you will accept no change without due process. If this is your own project, you may need to set boundaries and simply say no to project changes. You can usually make something better if you work long and hard enough – that's why some perfectionists have such a hard time getting anything done! Use your judgment to determine when the current objectives and requirements are sufficient. Consider releasing later versions or providing upgrades in the future to meet changing needs. • Identify project phases – Use predetermined breaks in the process to properly evaluate and accept additional requirements. If appropriate, delay any scope changes until you reach a new phase.

Key Points Scope creep is hard to prevent, because most large projects encounter new and unexpected issues after they begin. But don't allow these issues to grow too numerous or too big: uncontrolled changes can affect your time and budget, they can reduce the overall viability of your project, and they can undermine the project's business case. To avoid this, carefully define your original requirements, and create a plan to deal with the scope changes that you'll inevitably face. With a scope control plan, you can manage the number of changes, the impact of those changes, and when and how those changes are integrated. It puts you back in control of the project – and it helps ensure that you'll successfully reach your goal.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... bigk wrote Hi Colin Can't find an easy workaround for the printing output you need. All other software suggested seems to have good support, pdf and files export, but they are all a cost. Will check details thanks, cost is always an issue. There are two other software items that meet the requirements better but there is a cost. Thanks for the suggestion will see how get on with the details. Don't need print but see what you mean about being restrictive, is an issue, better print support would be better. Until get cash to buy other one could use this. Thanks Bigk August 14, 2009 colinscowen wrote Xmind is a freeware mindmapping system, that is fairly easy to use, and which, if you buy the pro version allows you to develop Gantt and excel type charts from the same data that is used in the

mind map. The pro version is very cheap, the details are on their website. I am currently using the free version to track a project I am working on, and it is satisfying my, admittedly rather personal and basic needs, and I plan to buy a monthly subscription to the pro version to test the Gantt output. This program is let down by limitations in printing output though, especially with large maps, but there are work arounds, and hey, no one's perfect. Regards, August 14, 2009 bigk wrote Hi Looking at these already, let you know how it goes in a few days. Limited on cash, but intention is to use something more than excel, using excel only as prototype for working with the items. Don't like mentioning short of cash, do know the software mentioned. Will reply again soon, arranging test. Thanks for your input and help. Bigk August 14, 2009 Dianna wrote Hi bigk - do you use a project dashboard? These are really helpful: http://mindtools.com/community/pages/ar ... PPM_92.php for communicating where things are at within a project. As well, GANTT charts are time-tested and very reliable: http://mindtools.com/community/pages/ar ... PPM_03.php Along woth that goes Critical Path Analysis and PERT Charts: http://www.mindtools.com/community/page ... PPM_04.php Microsoft Project is a very powerful software application, but many people prefer Excel Have a look at these tools and see if you can use them to accomplish your objective. Dianna August 13, 2009 bigk wrote

Hi A question, should I ask this elsewhere? What tool could I use combined with a time-line project management tool? Reason. Improve method or use. Requirement. Trying to sort what tool to use when working with multiple deadlines running through a project. Each are a deadlines, date gets set. No issue. Work time available is compared to time or resource available. Monitoring these through a time-line or calendar with notifications, but looking for something that might help highlight time or action. Could use mindmap method, but also looking into how to create a tool or model to use as method to compare the variables and define the type of tasks needed. This is similar to using spreadsheet with items defined and then a time and action typed assigned. Monitor this by allowing a time projection of outcomes for the schedule and the amended time or action required so can compare the changes or actions needed. If I used a report to output the main items to report then it would give a comparison for actions or items that need a change added to the overall schedule. This mostly gives the required items to report. Current status of actions, current deadlines. New deadlines, actions that need re-scheduled or new deadline agreed. Is there something similar I could look at to compare? Still looking but am trying some of the tools here as well as software. Thanks Bigk August 13, 2009 bigk wrote Hi Agree. A deadline is set as a deadline. A new deadline is set for reason.

Time can be focused on the changes or actions that need completed. The gains made with the time taken in the project so far can allow focus towards getting project results delivered or if any actions are needed because of a changed deadline. Evaluating progress while amending any schedule deadlines. Should have used the word "agreed" in my message. Thanks for your input. Bigk August 13, 2009 Midgie wrote Hi Bigk, I do believe that is is never acceptable to miss deadlines. If you have additional changes that have been agreed, and new deadlines negotiated, then you work towards that new deadline. Rather than thinking that you've 'missed' the original deadline, it has simply been shifted as a result of the new work. Midgie August 13, 2009 bigk wrote Hi Checking how to use with project management guidelines, checking how to use with a work schedule. I would agree that not adding changes to the original project target date is what to use. Changes could be added and usually are, but the delivery date often needs set. The changes could be started as a different project to the original project. Changes to a project are different from changes that are additions. It is better delivering on time or to a re-scheduled deadline, than being in the process of completing changes and revisions and missing a deadline. Bigk August 11, 2009

Return to top of the page

SIPOC Diagrams Making Sure Your Change Process Serves Everyone You're ready to start improving your systems. You want to increase quality and profitability by reducing error and waste. But where do you start? And how do you make sure that the process is comprehensive, and gives its customers what they want, right from the start? Make sure your processes are robust and

comprehensive. The first step is to find out © iStockphoto exactly where you are now. You can then create an accurate "roadmap" to get from your current position to your desired endpoint.

SIPOC Diagrams are useful tools for doing this in business. They provide a simple way of taking a "before" picture, so that you can compare this with your "after" picture, hopefully demonstrating improvement. (SIPOC, coming from Six Sigma, stands for Suppliers, Inputs, Processes, Outputs and Customers.) The Six Sigma methodology provides a firm foundation for making changes in a controlled and effective way. SIPOC is part of the "Measure" phase of Six Sigma's core DMAIC sequence (Define, Measure, Analyze, Improve, Control). More than this, SIPOC Diagrams help you ensure that your new processes produce the right outputs for the right people, comprehensively, and right from the start. It's so much better to spend time ensuring this up front, than to charge in enthusiastically with a change process, only to find – on implementation – that suppliers and customers are screaming because you haven't fully understood their needs and requirements!

What Does the SIPOC Diagram Show? A complete SIPOC diagram provides an "as is" view of a current process as it exists today, and it clearly identifies all of the elements affecting and affected by the process – so that these can all be given due consideration when the process is reviewed. By taking the time to identify these, you can make sure that you fully understand the current position; that you have understood who and what is involved with the process; and that you know comprehensively who benefits, and in what way.

Simple Example

A Program Office is responsible for producing a weekly status report for the Program Manager and other key stakeholders, that shows the status of each project within the program portfolio. This is done by collating reports from Project Managers and extracting figures from the accounts system.

How to Use the Tool To create your own SIPOC diagram, start by downloading our free worksheet. Then follow these steps:

Step 1: List Major Elements of the Process When building a SIPOC diagram, begin in the middle, with the overall process you're examining, because this is the part of the operation over which you have the greatest control. Identify the major steps of your current process. In simple terms, how does your process take inputs, and turn them into outputs? Write these in the flow chart template on the worksheet. Example

Collect progress reports on each project from Project Managers. Extract project spend and budget figures from accounts system. Collate onto Program Dashboard spreadsheet, and format. Distribute by e-mail.

Step 2: Identify Outputs What are the outputs that result from the process? What products does your process create? Work with your team to list everything your process produces on the way to your customer. Example

A visual Program Dashboard using colors to identify deliverable, compliance with financial projections, compliance with the schedule, and overall status for each project and for the program.

Step 3: Define Customers Who are the internal and external customers who receive and use your outputs? Brainstorm all of these, and consider checking this against a client list, perhaps extracted from your accounts receivable system.

Example

The Program Manager, and the Steering Group.

Step 4: Determine Inputs What inputs or raw materials are necessary to perform the process? Inputs can include people, as well as information, necessary conditions, and supplies. Example

Progress reports from Project Managers. Project budgets. Current spend on each project.

Step 5: List Suppliers Who are the suppliers of your inputs? You've identified the necessary raw materials, now determine where they come from. Consider checking your analysis against, for example, your accounts payable system to make sure your list is complete. Example

Program Managers. Accounts staff. Program Office assistant who does the collation and formatting.

Allow plenty of time for your team to develop its SIPOC diagram. For a complex process, your worksheet diagram may cover an entire wall – this would have space for everyone to add items as they think of them, perhaps over a period of several days. One important benefit of a SIPOC is that it can give you a chance to think of everything ahead of time – before you implement a process change – so that you don't miss important details. When you finally change the process, you want to take EVERYTHING into consideration. When you believe that your SIPOC Diagram is as comprehensive and complete as possible, you're ready to start thinking about your new process. Follow the flow from Supplier to Customer. Where does the existing process work well? Where are there problems? Is there waste? Are there opportunities for improving the process? Studying the diagram will, most likely, give you plenty of new ideas. Example

Conditional formatting could be used in the spreadsheet color the statuses for each project, and for the overall program, automatically. For a more ambitious process improvement, an intranet-based application could be developed, into which Project

Managers could input their reports directly and which was also linked to the accounts system. If this were accessible by all key stakeholders, they could be automatically notified as soon as each week's report was complete, so the Program Office would no longer need to do anything at all.

Key Points SIPOC Diagrams show the relationships between Suppliers, Inputs, Processes, Outputs, and Customers (and sometimes Customer requirements). Unlike normal process flow charts, they explicitly bring Suppliers, Inputs, Outputs and Customers into the analysis process, making sure that changes to the process take into account all of these. They are part of the Measure phase of the Six Sigma program, giving you a high-level process map and a thorough summary of your current situation. Start creating your SIPOC in the middle – that is, first map the Process that's currently in place. Then list Inputs and Outputs. This sequence helps focus your thinking on the Process, with its costs and impacts. Build the SIPOC with careful consideration of all factors. This is your chance to get a "big picture" view before you start to change any details.

Download Worksheet

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Yolande wrote Very valuable article once again! During a process of change and rationalisation that I was part of a few years ago, the one thing we had to go back to over and over again was the question: Who are our customers? It basically boils down to the "Define your Customer" step in the SIPOC process. That really helped us to keep focussed. The other very valuable step that we (unknowingly) took was to evaluate our target output all the time - it also helped us to keep on track and to ensure that we reached the goal of the process that we started with in the first place. Regards Yolandé August 14, 2008 miadanu wrote Thank you for this. It is particularly timely for me as I start my new role in about 4 weeks as a project / mini-programme manager (so not focused on the IT technical support anymore) and the major project that I am tasked with is all around process improvement and making effective use of IT to automate the new process. As it happens I have open on my desk in front of me some materials on LEAN and Value Stream Mapping that I am revising, so seeing this pop-up adds another tool to my basket of tricks August 13, 2008

Return to top of the page

Stakeholder Analysis Winning Support for Your Projects Try this out in our Interactive Stakeholder Analysis Screen App! "Stakeholder management is critical to the success of every project in every organization I have ever worked with. By engaging the right people in the right way in your project, you can make a big difference to its success... and to your career." As you become more successful in your career, the © iStockphoto/timsa actions you take and the projects you run will affect more and more people. The more people you affect, the more likely it is that your actions will impact people who have power and influence over your projects. These people could be strong supporters of your work – or they could block it. Stakeholder Management is an important discipline that successful people use to win support from others. It helps them ensure that their projects succeed where others fail. Stakeholder Analysis is the technique used to identify the key people who have to be won over. You then use Stakeholder Planning to build the support that helps you succeed. The benefits of using a stakeholder-based approach are that: • You can use the opinions of the most powerful stakeholders to shape your projects at an early stage. Not only does this make it more likely that they will support you, their input can also improve the quality of your project • Gaining support from powerful stakeholders can help you to win more resources – this makes it more likely that your projects will be successful • By communicating with stakeholders early and frequently, you can ensure that they fully understand what you are doing and understand the benefits of your project – this means they can support you actively when necessary • You can anticipate what people's reaction to your project may be, and build into your plan the actions that will win people's support.

How to Use the Tool The first step in Stakeholder Analysis is to identify who your stakeholders are. The next step is to work out their power, influence and interest, so you know who you should focus on. The final step is to develop a good understanding of the most important stakeholders

so that you know how they are likely to respond, and so that you can work out how to win their support – you can record this analysis on a stakeholder map. After you have used this tool and created a stakeholder map, you can use the stakeholder planning tool to plan how you will communicate with each stakeholder. The steps of Stakeholder Analysis are explained below:

Step 1 – Identify Your Stakeholders The first step in your Stakeholder Analysis is to brainstorm who your stakeholders are. As part of this, think of all the people who are affected by your work, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion. The table below shows some of the people who might be stakeholders in your job or in your projects: Your boss

Shareholders

Government

Senior executives

Alliance partners

Trades associations

Your coworkers

Suppliers

The press

Your team

Lenders

Interest groups

Customers

Analysts

The public

Prospective customers

Future recruits

The community

Your family Remember that although stakeholders may be both organizations and people, ultimately you must communicate with people. Make sure that you identify the correct individual stakeholders within a stakeholder organization.

Step 2 – Prioritize Your Stakeholders You may now have a long list of people and organizations that are affected by your work. Some of these may have the power either to block or advance. Some may be interested in what you are doing, others may not care. Map out your stakeholders on our Interactive Screen App, and classify them by their power over your work and by their interest in your work.

Figure1: Power/Interest Grid for Stakeholder Prioritization

For example, your boss is likely to have high power and influence over your projects and high interest. Your family may have high interest, but are unlikely to have power over it. Someone's position on the grid shows you the actions you have to take with them: • High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy. • High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message. • Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project. • Low power, less interested people: again, monitor these people, but do not bore them with excessive communication.

Step 3 – Understand Your Key Stakeholders You now need to know more about your key stakeholders. You need to know how they are likely to feel about and react to your project. You also need to know how best to engage them in your project and how best to communicate with them.

Key questions that can help you understand your stakeholders are: • What financial or emotional interest do they have in the outcome of your work? Is it positive or negative? • What motivates them most of all? • What information do they want from you? • How do they want to receive information from you? What is the best way of communicating your message to them? • What is their current opinion of your work? Is it based on good information? • Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers therefore become important stakeholders in their own right? • If they are not likely to be positive, what will win them around to support your project? • If you don't think you will be able to win them around, how will you manage their opposition? • Who else might be influenced by their opinions? Do these people become stakeholders in their own right? A very good way of answering these questions is to talk to your stakeholders directly – people are often quite open about their views, and asking people's opinions is often the first step in building a successful relationship with them. You can summarize the understanding you have gained on the stakeholder map, so that you can easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters or your project. A good way of doing this is by color coding: showing advocates and supporters in green, blockers and critics in red, and others who are neutral in orange.

Figure 2: Example Power/Interest Grid With Stakeholders Marked

Figure 2 shows an example of this – in this example, you can see that a lot of effort needs to be put into persuading Piers and Michael of the benefits of the project – Janet and Amanda also need to managed well as powerful supporters.

Example You can create your own example of Stakeholder Analysis at work – whether for your current role, a job you want to do, or a new project. Conduct a full stakeholder analysis. Ask yourself whether you are communicating as effectively as you should be with your stakeholders. What actions can you take to get more from your supporters or win over your critics? Add your stakeholders to our free Interactive Screen App below. You can move your stakeholders around, or change their color, depending on what your full analysis reveals.

Add Name

Download

Clear

Key Points As the work you do and the projects you run become more important, you will affect more and more people. Some of these people have the power to undermine your projects and your position. Others may be strong supporters of your work. Stakeholder Management is the process by which you identify your key stakeholders and win their support. Stakeholder Analysis is the first stage of this, where you identify and start to understand your most important stakeholders. The first stage of this is to brainstorm who your stakeholders are. The next step is to prioritize them by power and interest, and to plot this on a Power/Interest grid. The final stage is to get an understanding of what motivates your stakeholders and how you need to win them around.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

Next Handling "Politics" Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... snoopdogg wrote This is an excellent article about stakeholders and how they may influence your projects or your interests at work. I understand that it is very important to first understand who are the stakeholders at your workplace, how interested they are and how much power they have over what you are doing at your workplace. The article also mentions points out that we need to know what motivates them and accordingly create a stategy that will ensure that you gain their support or that your work goes smoothly. I would really appreciate it if someone can point point out, with suitable examples, how we can find out what what motivates our stakeholders and what can we do that can gain their support. Regards,

aJ April 29, 2012 James wrote Hi Agora Great point! The problem with treating organizations as stakeholders is that its too easy to forget that they are simply groups of individuals, and lose focus on precisely which individuals you need to be influencing. There may be many individuals within an organization - contact people, influencers, budget-holders, sponsors, and so on - who contribute towards a decision, and you need to be influencing all of these if you want things to go your way. James December 30, 2011 agora wrote Hello It makes much more sense to me to put individuals' names in the grid! I have heard about this method before but I did not really pick it up, probably because in my mind stakeholders were first of all organisations... but with individuals it makes much more sense as you can also take into account their personalities (some like to be informed a lot, or pampered, others don't, even in one single organisation)... Thanks for this! December 30, 2011 Dianna wrote Stakeholder analysis is a technique you can use to identify and assess the importance of key people, groups of people, or institutions that may significantly influence the success of your activity or project. When you conduct an analysis at the beginning stages of a project you it helps you better understand the support and potential pressure points you may experience from interested parties along the way. Then when you understand the people, groups, and institutions than can positively or negatively affect your project, you can develop strategies to get the most effective support possible and reduce potential obstacles sooner rather than later.

It's also helpful to make stakeholder analysis a dynamic element of your project planning and execution. Stakeholder interests and perspectives can change so keepign your analysis up to date is also very helpful. Dianna September 1, 2010

Return to top of the page

Stakeholder Management Planning Stakeholder Communication Stakeholder management is critical to the success of every project in every organization I have ever worked with. By engaging the right people in the right way in your project, you can make a big difference to its success... and to your career. – Rachel Thompson (Mind Tools), experienced change management consultant

Who needs to know what, and when? © iStockphoto

Having conducted a Stakeholder Analysis exercise, you will have most of the information you need to plan how to manage communication with your stakeholders. You will have identified the stakeholders in your job and in your projects, and will have marked out their positions on a stakeholder map. The next stage is to plan your communication so that you can win them around to support your projects. Stakeholder Planning is the process by which you do this. To carry out a Stakeholder Planning exercise, download our free Stakeholder Communications worksheet. This is a table with the following column headings: • Stakeholder Name. • Communications Approach. • Key Interests and Issues. • Current Status – Advocate, supporter, neutral, critic, blocker. • Desired Support – High, medium or low. • Desired Project Role (if any). • Actions Desired (if any). • Messages Needed. • Actions and Communications. Using this table, work through the planning exercise using the steps below:

1. Update the Worksheet with Power/Interest Grid Information Based on the Power/Interest Grid you created in your Stakeholder Analysis , enter the stakeholders' names, their influence and

interest in your job or project, and your current assessment of where they stand with respect to it.

2. Plan Your Approach to Stakeholder Management The amount of time you should allocate to Stakeholder Management depends on the size and difficulty of your projects and goals, the time you have available for communication, and the amount of help you need to achieve the results you want. Think through the help you need, the amount of time that will be taken to manage this and the time you will need for communication. Help with the project could include sponsorship of the project, advice and expert input, reviews of material to increase quality, etc.

3. Think Through What You Want From Each Stakeholder Next, work through your list of stakeholders thinking through the levels of support you want from them and the roles you would like them to play (if any). Think through the actions you would like them to perform. Write this information down in the "Desired Support," "Desired Project Role," and "Actions Desired" columns.

4. Identify the Messages You Need to Convey Next, identify the messages that you need to convey to your stakeholders to persuade them to support you and engage with your projects or goals. Typical messages will show the benefits to the person or organization of what you are doing, and will focus on key performance drivers like increasing profitability or delivering real improvements.

5. Identify Actions and Communications Finally, work out what you need to do to win and manage the support of these stakeholders. With the time and resource you have available, identify how you will manage the communication to and the input from your stakeholders. Focusing on the high-power/high-interest stakeholders first and the low-interest/low-power stakeholders last, devise a practical plan that communicates with people as effectively as possible and that communicates the right amount of information in a way that neither under nor over-communicates. Think through what you need to do to keep your best supporters engaged and on-board. Work out how to win over or neutralize the opposition of skeptics. Where you need the active support of people who are not currently interested in what you are doing, think about how you can engage them and raise their level of interest. Also, consider how what you are doing will affect your stakeholders. Where appropriate, let people know as early as possible of any difficult issues that may arise, and discuss with them how you can minimize or manage any impact.

Tip:

It is usually a good idea to manage people's expectations about likely problems as early as possible. This gives them time to think through how to manage issues, and preserves your reputation for reliability. Once you have prepared your Stakeholder Plan, all you need to do is to implement it. As with all plans, it will be easier to implement if you break it down into a series of small, achievable steps and action these one-by-one.

Key Points As the work you do and the projects you run become more important, you will affect more and more people. Some of these people have the power to undermine your projects and your position. Others may be strong supporters of your work. Stakeholder Management is the process by which you identify your key stakeholders and win their support. Stakeholder Analysis is the first stage of this, where you identify and start to understand your most important stakeholders. Once you have completed your Stakeholder Analysis, the next stage is Stakeholder Planning. This is the process you use to plan how to manage your stakeholders and gain their support for your projects. To prepare your plan, go through the following steps: 1. Update the planning sheet with information from the power/interest grid. 2. Think through your approach to stakeholder management. 3. Work out what you want from each stakeholder. 4. Identify the messages you need to convey. 5. Identify actions and communications. Good Stakeholder Management helps you to manage the politics that can often come with major projects. It helps you win support for your projects and eliminates a major source of project and work stress.

Download Worksheet

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Hi Lefteris, What might help you are the two Bite Sized Training sessions we have on stakeholder management, the first one ( http://www.mindtools.com/community/Bite-SizedTraining/ StakeholderManagement.php ) provides a step by step on completing a stakeholder analysis and the second ( http://www.mindtools.com/community/Bite-SizedTraining/ ManagingStakeholders.php ) provides a scenario that you work through. Take a look at these and see if they help you do some comparatives. Dianna July 19, 2012 lkanavas wrote Hi Very useful article indeed, is there an example worksheet filled in anyone can provide with pls? I am just interested in comparing to our own filled in worksheets to perform some comparative analyses.

Regards Lefteris July 18, 2012 Rachel wrote Hi All I've chosen this article to be our featured favorite this week because, from my past experience as a project manager, I always found that successful stakeholder management was key to so many aspects of project success from definig business requirements to staying on schedule. Click the link below to find out how to plan your stakeholder communications so that your project stays firmly on track. http://www.mindtools.com/community/page ... PPM_08.php Best wishes Rachel May 4, 2010 Dianna wrote A project's success is mitigated in large part by the amount of support it receives. You can have the best plan, the best team, and the best vision however, if don't have sufficient backing from key stakeholders it may be doomed before it even gets off the ground. And this lack of support isn't always obvious unless you uncover your stakeholders and understand their needs right from the start. In my experience, the most successful projects have been those where I mapped out my stakeholder's needs as part of the planning process. From there it is a matter of managing the communication as the project proceeds. What experiences, good and bad, have you had with project stakeholders? Dianna March 22, 2010

Return to top of the page

The ADKAR® Change Management Model Using Goals to Accomplish Change "ADKAR" is a trademark Prosci® (see prosci.com/). We have no association or connection with this organization. Clearly, for change to be successful, people have to change the way that they work. Typically, you'll persuade them to do this by explaining the need for change, by getting their buy-in, by training them, and by giving them support. But how do you know if you've communicated enough? Or Use this model to help you achieve change trained enough? And which successfully. outcomes should you © iStockphoto/scibak concentrate on during each stage of a project, to make sure that you implement change effectively? The ADKAR® Change Management Model helps you answer these questions by providing a clear communication goal for each stage of your change project. By focusing on what you need to do to achieve these goals, you can get everyone on board with your project, and implement change successfully.

About the Model The ADKAR Model was created by the Prosci research organization in the late 90s, following research involving more than 300 companies engaged in major change projects. It was then published in Jeff Hiatt's 2006 book, "ADKAR: A Model for Change in Business, Government and Our Community." The model focuses on the way that you share information with the project's stakeholders – the people affected by the change. According to the model, for change to succeed, you need to achieve five successive knowledge-sharing goals as the project proceeds. These are: 1. Awareness (of the need for change). 2. Desire (to participate in and support the change). 3. Knowledge (of how to change). 4. Ability (to change). 5. Reinforcement (to sustain the change). You need to achieve each goal before you can move on to the next.

To start with, stakeholders must be made aware of the need for change. You then need to translate this awareness into a desire to be involved in it, so that people put in the effort needed to create a good design for the project. Once the design has been approved, your stakeholders should then know what they need to do to make the change project happen. And after the implementation has been completed and the project is "live," users need to be trained so they are able to apply the new skills and behaviors that will make the project a success. These behaviors should then be reinforced, so that the project continues to be a success. The graph in figure 1, below, outlines when you need to achieve each goal. Project phases are shown on the vertical axis, while each of the five ADKAR goals is shown on the horizontal axis. However, this is provided as guidance only – the stage at which you need to achieve each goal may vary, depending on the project.

The main advantage of using the ADKAR Model is that it encourages you to focus on achieving clear, finite communication goals at specific project stages, rather than just doing many activities and hoping that what you do is sufficient to achieve your project's overall objectives.

Using the ADKAR Model The ADKAR Model is useful in a range of change management situations. For instance: • During planning, so you can think about how much time you'll allocate for communication. • When you're in the middle of a project phase, where it helps you think about whether your planned activity is achieving its goals. • When you're not getting the results you expected. We'll now go through the ADKAR goals, and show you how to achieve them in practice.

1. Awareness Building awareness of the need for change usually takes place during the Business Case and Preparation phases of a project. Here, you need to think about the people who are your project's stakeholders, and ask yourself what they need to know, understand, or experience so that they can "buy in" to the change. To do this, make sure that you and your management team communicate your vision for change to stakeholders, and that you give them access to all of the information they need to understand this. (At this stage, make sure that you listen carefully to their feedback, and adjust the vision if you feel this is necessary.)

2. Desire to Participate and Support the Change Next, you need your stakeholders to want to participate with and support the change. You should focus on this goal in parallel with the Design phase of your project: this is the time where stakeholders can start to see the detail of what the project will look like, understand the impact it will have, and see the benefits it will bring. There are many reasons why people may support or resist change, so gaining people's desire to participate can often be difficult. You can see some of the reasons that stakeholders may support or resist change below: Supporting Factors • Discontent with the current state. • Enhanced job security. • Affiliation and sense of belonging. • Career advancement. • Acquisition of power or position. • Incentive or compensation. • Trust and respect for leadership. • Hope about the future state.

Resisting Factors • The threat of job losses. • Imminent negative consequences. • Worry about loss of productivity during the change process. • Worry about increased workload, particularly during any parallel run of new systems against old systems. • Worry about loss of personal prestige, power or benefits, particularly with people who are experts in the old system.

Tip 1:

Our articles on Beckhard and Harris's Change Equation , The Change Curve , and Coaching through Change will help you think about how to overcome people's natural resistance to change. Tip 2:

The higher the impact and significance of the change, the less likely it is that you'll gain everyone's support. It's important, therefore, to identify whose support is critical – Stakeholder Analysis and Influence Mapping will help you do this. Tip 3:

It's often difficult to understand why other people may not be excited by the change that you're advocating. But remember, they haven't been through the same thinking process that you have. Try to think about how they see things , and identify what information or insights they would need to see things the way you do.

3. Knowledge of How to Change The next step is to help people learn the skills and gain the knowledge they need to deliver change. It's useful, here, to conduct a Training Needs Assessment to identify the skills that people need to develop. Common ways of delivering this training are through Instructor-Led Training and On-the-Job Training , although the precise approach that you use will depend on the project.

4. Ability to Change Now you need to give people opportunities to apply their new skills, and you need to provide them with extra support whilst they're trying out unfamiliar processes. (For example, you may want to use coaching or mentoring at this stage.) As people start to become more comfortable with new processes and improve their skills, they may identify issues that weren't obvious beforehand. For instance, let's say an organization has sent a group of managers on a training course to improve their focus on customers. On their return, they get extra support using these skills through coaching and mentoring, and through use of peer-to-peer knowledge sharing sessions. However, as they implement their new processes and skills, it becomes clear that other changes are needed for them to behave in a fully customer-focused way. They decide to change the way that they file customer records, they move the location of the office reception, and they change the way that support staff are organized, so that they can help customers more effectively.

Tip:

Listen carefully if people start to identify new issues once the project has been implemented. This shows that they're taking ownership of the change, and are thinking about how they can do things in an even better way.

5. Reinforcement to Sustain the Change Once your users are fully effective and all of the project deliverables are in place, you're ready to move on to reinforcement in order to sustain the change. There are several positive things that you can do here, such as giving financial or non-financial rewards, adjusting compensation arrangements, and ensuring that people are rewarded in nonfinancial ways for their contribution. You will also need to continue communicating your vision, as well as letting people know about the success of the project and the things that it has achieved. Tip:

Remember, stakeholders can "slip back" at any point during the change process. For instance, a stakeholder might withdraw his or her desire to support the change (goal 2) as more detailed information about the concept and design is revealed. In this situation, you ideally need to re-establish their desire before you can move back to ensuring that relevant knowledge is once again being shared (goal 3).

Key Points The ADKAR Change Management Model helps you implement change effectively by providing a clear information-sharing goal for each stage of your project. The model describes five successive communication goals, which are: 1. Awareness (of the need for change). 2. Desire (to participate and support the change). 3. Knowledge (of how to change). 4. Ability (to change). 5. Reinforcement (to sustain the change). You need to achieve each goal before you can move on to the next. The main benefit of using the ADKAR model is that it encourages you to focus on achieving clear, finite communication goals as you work through the stages of your project.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Lakewood wrote Hi all I've been so busy working change management these past few days, I have not had a moment to reply. Later this week or over the weekend I'll put time aside and document some of the lessons and takeaways I gained from the training I took. -Robert. August 3, 2011 GoldenBoy wrote I love this model. It is explicit, easy to implement, and defines each stage clearly. one thing our organisation does not lack is change - we are going through a major change in delivery and targets as we speak; one thing our organisation does lack, however, is the ability to communicate that change effectively. I think this model will help us through what will be a very hectic and - for some - uncomfortable few months. I wish I had known of this model earlier, but as I can see, it is very adaptable and I will be using it for the remainder of the period. August 3, 2011

Yolande wrote Hi Robert I had smile at your comment about the organisation you work for being somewhat reluctant about change...believe me...most of them are! However, it's great that you have at least arrived at a stage where things are starting to happen. Change isn't always comfortable, but it's necessary. I agree with you that the ADKAR model is a great model to use; I find it simple and user-friendly. If you'd like to share any special insights gained at the workshop you attended, feel free to share them - we love to learn over here! Kind regards Yolandé July 25, 2011 Lakewood wrote I recently participated in a three day training session on Change Management using the ADKAR (Prosci) system. Very pleased with the training, the model and structure. As a project manager in an organization that has been somewhat resistant to change, I learned so many valuable skills that I've already been able to put to good use! Well worthwhile. -Robert. July 23, 2011 MichaelP wrote This a great structure to support a change process and I have used it successfully. In my view the Knowledge sharing goals are more than simple 'communication' since you need to make sure the message is sent clearly, received, processed and understood; which can be different to just sharing the knowledge. To this extent I have requested the stake holders to tell me why they are ready to go to the next stage, vs me telling them and when the communication is this way progress is virtually guaranteed. hopefully others can share their experiences with this popular change management methodology. cheers Michael July 20, 2011

Return to top of the page

The Burke-Litwin Change Model Unraveling the Dynamics of Organizational Change Change is the only constant – or so the adage goes. Change is often a complex and arduous process, and not something you want to attempt without a solid plan. When organizations need to change, that planning process is often complicated by the need to change many elements in unison.

© iStockphoto/borchee

This interrelatedness of organizational parts can contribute to the failure of change programs. When one variable is missed, bypassed, or underestimated the whole system fails to change, leaving managers and employees with the unenviable task of putting things back to the status quo. The really brave will attempt the change process over again; others will accept defeat and resign themselves to doing what they've always done. When what people have always done already isn't working however, the results of failed change can be devastating. Whether it's revamping an accounting process, implementing a new IT system, or embarking on a new competitive strategy, positive change is revitalizing and productive. That's why it is so important to understand what needs to be addressed during any change process and why. When you understand the dynamics of organizational change, you can apply the principles to any type of change initiative that comes your way. That's an exciting and valuable skill to have and one that will make you a hot commodity in today's workplace. An useful model for understanding the organizational change process is the Burke-Litwin Change Model published by George H Litwin and W Warner Burke in 1992. This model shows the causal effects of change between 12 key areas of organizational design. Using the model, you can learn which organizational variables to change and why. You can then use this understanding to analyze, diagnose and even predict the effects of change throughout an organization.

Understanding the Model The Burke-Litwin model is used as a guide for identifying and linking factors that are critical to a successful change initiative. According to the model there are 12 of these critical factors.

Tip:

This diagram looks very complex. Please persevere! This is a useful tool, and this should all eventually make sense!

From Warner Burke, W. and Litwin, G.H (1992) 'Causal Model of Organizational Performance and Change,' Journal of Management. © 1992. Reproduced with permission of SAGE Publications.

Input: External Environment The loop starts with the external environment, shown in dark blue in Figure 1. This is what creates the need for change. Examples in include a weakening in the economy, shifts in social trends, and the arrival of new technology. By including the external environment as an input, the BurkeLitwin model goes one stage further than the Congruence Model of organizational performance. It is also considerably more complex, involving more elements. In developing their model, Burke and Litwin tried to strike a balance between reflecting the genuine complexity of the real world, and creating something that people could readily understand and use.

Throughput: Transformational Factors Transformational factors are the elements that are core to an organization's performance. They make up the fundamental structure

of an organization and are shown in sky blue in Figure 1. If you're going to make significant changes to your area, or transform an organization, you need to address these factors. • Mission and Strategy – What the organization's people believe to be the core purpose for the organization's existence; • Leadership – The actions, philosophies, and values of senior managers; and • Organizational Culture – The norms of behavior and values that are accepted and expected within the organization. To effect significant change, or even perform at acceptable levels, these three elements must be aligned. In the model, these factors are at the top of the loop and are of overriding importance when dealing with a change that is intended to shake-up "the way things are done around here." The arrows showing the interaction between these transformational factors and the transactional factors described below are shaded downwards to indicate that, although the upper and lower elements both impact each other, the impact is stronger in the downwards direction.

Throughput: Transactional Factors These are the elements of an organization that are more easily changed, but rarely have the same kind of impact on organizationwide performance as the transformational ones. They are shown in light green in Figure 1. They are important, but unless the three transformational factors support the change, modifications in these areas are likely to be temporary. • Structure – The way the organization is set up in terms of roles and functions, communication, lines of authority, and decisionmaking. • Systems – The processes and procedures that are in place to support operations. • Management Practices – How managers and people with authority and responsibility execute the strategy on a day-to-day basis. • Work Climate – The prevailing attitude and morale of the people working for the organization. • Task and Individual Skills – The degree of "fit" between the skills required for the job and the skills of the people doing the job. • Individual Needs and Values – The degree to which the processes and systems within the organization fulfill the needs of the employees and allow them to feel satisfied. • Motivation – The intrinsic and extrinsic factors that motivate people to perform well on a consistent basis. In fact, all twelve elements affect each other, but the arrows on the diagrams show the relationships between elements that the authors considered the strongest. Even so, it quickly becomes clear how a change in one element can have an organization-wide impact. And while change or improvement in any one of these transactional

factors can affect performance, the effect will only be long lasting if the underlying transformational elements are aligned. For example, if you restructure departments and create cross functional work teams without addressing the deeply held belief that functional groups operate best as distinct business units, then your restructuring may even be detrimental to performance. Likewise, if you put in place a top-notch reward and recognition system to motivate employees, but it doesn't reward people for behaviors that support the mission, then the effect may be counterproductive.

Output: Individual and Organizational Performance The outcome of the change is the effect it has on performance (shown in gray in Figure 1). This is the measure of the effectiveness of the change. It also has an impact on the external environment, which is what creates the loop. Therefore, as the output changes, so does the input and so the factors of change themselves also change, once again proving that the only constant is change!

Applying the Burke-Litwin Change Model So the theory sounds good, but how do you use it? The model's greatest value is as a framework for understanding the current situation and the collateral impact of proposed changes.

Step 1: Where is the Need for Change Coming From? Change initiatives are driven by one of two things: either something isn't working now, or something won't be working as well as you want it to in the future if you don't make changes now. Either way, the change initiatives will be focused in one of the four groups of elements in Figure 1: 1. The External Environment 2. Transformational Factors 3. Transactional Factors 4. Performance Start by deciding which group your change imperative belongs to. Then identify which of the elements in each group is key for your situation. In general, the lower down the model your key element is, the more easily you will be able to effect the change required. Example:

A small software development company had grown successfully over several years, and now employed around 60 people. However, in the last 9 months, staff had started leaving. Karen, one of the founders, set about finding out why this was happening. She contacted some of the recent leavers and found that they had been unhappy with a new emphasis she and her business partner had put on developers selling work to clients. In the past, she and her partner had cut the deals. But as the company had matured, the founders had wanted to put more of their time into a new venture,

and had figured that selling software required strong technical knowledge, so the developers themselves would be well placed do to this. While this was essentially true, the problem was that the developers didn't like doing this task, and they also felt they lacked sales skills. Using the Burke-Litwin Model, Karen concluded that "Task and Skills" was the key problem area.

Step 2: Assess the Current Situation The next step is to understand the key element in your change imperative in detail. Use the questions from the following list as a guide, and also explore the other 11 elements, spending more time on those that Figure 1 links most closely with your key element. • External Environment – What is driving the change? How will these drivers impact the organization? • Mission and Strategy – Is there a clear mission? What is it? Is there a perceived mission and strategy that is different from the formal one? Do employees believe in the mission and strategy? • Leadership – Who are the real leaders? What style do they use? Is this style successful? • Organizational Culture – What are the unwritten rules of behavior? Do any of these rules conflict with what the organization is seeking to accomplish? • Structure – How are people and functions arranged? How flexible is the structure? Where are decisions made? How is authority and responsibility divided up? How is information communicated? • Systems – What are the key policies and procedures that define how work is done? What systems are in place to motivate, reward, recognize, appraise, and compensate employees? • Management Practices – What style of management is practiced? How do managers interact with their employees? Are teams used? • Work Climate – What is the morale of the staff like? How do people get along with each other? What systems are used to resolve conflict? Are there definite dividing lines between units, departments, or locations? • Task and Individual Skills – How are job requirements defined? Who defines them? How well are people matched to their jobs? • Individual Needs and Values – Are people generally satisfied at work? What efforts are made to ensure job satisfaction? What opportunities are given for professional development and career succession? • Motivation – Are staff motivated through formal systems? Is motivation expected to be intrinsic? What impacts motivation the most? • Individual and Organizational Performance – How is productivity measured? What are the performance levels on these factors? What should be measured that isn't?

Example:

Karen looked at the following elements of the Burke Litwin Model which are the most closely linked to the key problem area of Task & Skills. • Task and Individual Skills: The new requirement to sell work had not been properly discussed with the developers before it was brought in. The approach came entirely from the founders, who loved selling; they hadn't appreciated that developers who thrived on satisfying customer needs might not enjoy brokering the deal too. • Structure: As the company had grown, its structure had not grown with it. All developers essentially had the same job description. Karen and her business partner made all the decisions. • Mission and Strategy: The company's growth targets had not been adjusted to reflect the change in approach to sales. • Leadership: Karen and her business partner were spending less time on the business, yet had not appointed anyone else to take over the parts of the leadership role they had vacated. They were charismatic leaders, so once they were not as involved, employees felt that the business lacked direction. • Motivation: Employees were demotivated by having to work they didn't enjoy and felt they were no good at. A reward system had been introduced to give bonuses based on the revenue generated by each developer, but employees felt that they could not access these bonuses as they were not good enough at selling work. • Individual Needs and Values: The developers who had left wanted to be able to focus on development work and on surpassing the expectations of clients who had already decide to "buy" from them. They did not want to have to work on winning round clients, and did not particularly value high sales bonuses. • Individual and Organizational Performance: Individual performance was dropping as developers had spent less time on development, and were not successful in their selling work. Organizational performance dropped as less work was being won.

Step 3: Incorporate All Affected Elements Into Your Change Plan Now that you understand "what" is happening, you need to figure out what you're going to change in the key problem element, and what therefore also needs to change in the main related elements. This may need to be done as an iterative process: change in one element affects a second element, which affects a third, yet the change in the third element may require another alteration back in the first element again. Example:

Karen consulted with her team of developers and, together, they agreed a new approach:

• Task and Individual Skills:Selling work would no longer be required of developers. • Structure: A new sales team would be formed, headed up by a professional sales executive. The team would include several hybrid developer-seller roles, offering an opportunity for those developers who had enjoyed doing selling work. Developers who applied for these roles would be given sales training. • Mission and Strategy: Karen and her business partner recognized that their interests were focused on their new venture, and so revised their growth expectations for the software company. • Leadership: A new Chief Executive was appointed to run the software company, with the founders moving to Chairman/ Advisor roles. • Motivation: Intrinsic motivation increased greatly as employees no longer had to do types of work for which they felt they were not suited. The reward system was enhanced to recognize developers who maintained long-term relationships with clients, as well as developer-sellers who brought in new work. • Individual Needs and Values: The developers now felt that a range of opportunities was available to satisfy their individual needs and values. • Individual and Organizational Performance: Individual and organizational performance improved. Tip:

For another similar approach to this, see our article on the McKinsey 7S Model . You may also find our articles on the Change Curve , Impact Analysis and Lewin's Change Management Model useful.

Key Points The Burke-Litwin Change Model examines organizational change and provides insight into how changes in 12 key elements of the organization's design can impact one another and overall performance. While it doesn't show us how to make the changes needed to these critical factors, it does provide an useful framework from which to analyze what needs to be done, and why. This framework can be used to keep a close eye on the impact that changes in one area have on all the other areas as development and implementation of a change plan continues. The more aware you are of the dynamics of change, the better you will be at managing and dealing with it as it happens.

Did you find this article helpful?

Click to vote no

No Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... yasmina_dumont wrote Thank you Don Yes, we're gonna try to cut the elephant (well, the biggest model) into slices, settle small issues and then recompose everything. Best regards, Yasmina February 23, 2007 dp7622 wrote Hi Yaz, I feel for you. With merger situations I've found that culture change has to be driven from the top. When you leave it to emerge on its own, there is always unwanted residual from the pre-merger organizations. Using your mission as your basis, decide what values the organization should uphold. Analyze what norms and behaviors will support those values. Then design a reward and recognition system that aggressively targets and acknowledges the behaviors

you want to encourage. Since the HQ is in Asia, the values will probably be slightly different than what folks are used to . Thsi is why the reward system has to be continuously reinforced and top executives in all countires have to model the behavior. If that is an issue, then make sure the rewards extend up to that level as well. While you are rewarding the cultural behavior, it's a good time to look at values that will improve customer service. I think you have an opportunity to really the change the dynamics and make "better logistics" a cultural competence. In other words, what you reinforce at the cultural level should clearly support high customer service and thus delivering product on time should be a key priority for everyone. From there you can start developing the actual systems that will make "better logistics" a reality. I caution you not to start too much at once though, get the cultural foundation set, reinforce with rewards, then introduce supporting systems and reward compliance with those as well. While you're at it, look into stress management tools, I hava a feeling everyone in the company will be needing them. Don Powell February 22, 2007 yasmina_dumont wrote Hello! Thank you, it's +/- what I was looking for, as I'm supposed to come with suggestion of methods to make a homogenous company culture post merger (not directly after the merger, organizational culture problem was not really discussed prior to merger) ; now the situation is as it is, and such a task at international level is far from a piece of cake... How do you remotivate people who come from a US/European company culture and are now dealing with Asian HQ, when competition is tough, logistics is not easy at all (so customers are not fully happy) and the pressure on sales is very high? And, last but not least, all the European offices were re-structured? Thanks in advance, Best, Yaz February 22, 2007

Return to top of the page

The Change Curve Accelerating Change, and Increasing its Likelihood of Success Here's the scenario: You have invested vast amounts of time and dollars in the latest systems and processes; you have trained everyone; and you have made their lives so much easier (or so you think.) Yet months later, people still persist in their old ways: Where are the business improvements you expected? And when will the disruption you're experiencing subside?

Initially, many people want to cling to the past. © iStockphoto/gunnar

The fact is that organizations don't just change because of new systems, processes or new organization structures. They change because the people within the organization adapt and change too. Only when the people within it have made their own personal transitions can an organization truly reap the benefits of change. As someone needing to make changes within your organization, the challenge is not only to get the systems, process and structures right, but also to help and support people through these individual transitions (which can sometimes be intensely traumatic, and involve loss of power and prestige... and even employment.) The easier you can make this journey for people, the sooner your organization will benefit, and the more likely you are to be successful. However if you get this wrong, you could be heading for project – and career – failure. The Change Curve is a popular and powerful model used to understand the stages of personal transition and organizational change. It helps you predict how people will react to change, so that you can help them make their own personal transitions, and make sure that they have the help and support they need. Here, we first look at the theory behind the Change Curve. Then we look at how you can use it to accelerate change and improve its likelihood of success. Note 1:

The Change Curve is widely used in business and change management and there are many variations and adaptations. It is often attributed to psychiatrist Elisabeth Kubler-Ross, resulting from her work on personal transition in grief and bereavement.

Note 2:

Here we're describing major change, which may be genuinely traumatic for the people undergoing it. If change is less intense, adjust the approach appropriately.

The Change Curve The Change Curve model describes the four stages most people go through as they adjust to change. You can see this in figure 1, below. When a change is first introduced, people's initial reaction may be shock or denial, as they react to the challenge to the status quo. This is stage 1 of the Change Curve. Once the reality of the change starts to hit, people tend to react negatively and move to stage 2 of the Change Curve: They may fear the impact; feel angry; and actively resist or protest against the changes. Some will wrongly fear the negative consequences of change. Others will correctly identify real threats to their position. As a result, the organization experiences disruption which, if not carefully managed, can quickly spiral into chaos. Figure 1 – The Change Curve

For as long as people resist the change and remain at stage 2 of the Change Curve, the change will be unsuccessful, at least for the people who react in this way. This is a stressful and unpleasant stage. For everyone, it is much healthier to move to stage 3 of the Change Curve, where pessimism and resistance give way to some optimism and acceptance.

Tip:

It's easy just to think that people resist change out of sheer awkwardness and lack of vision. However you need to recognize that for some, change may affect them negatively in a very real way that you may not have foreseen. For example, people who've developed expertise in (or have earned a position of respect from) the old way of doing things can see their positions severely undermined by change. At stage 3 of the Change Curve, people stop focusing on what they have lost. They start to let go, and accept the changes. They begin testing and exploring what the changes mean, and so learn the reality of what's good and not so good, and how they must adapt. By stage 4, they not only accept the changes but also start to embrace them: They rebuild their ways of working. Only when people get to this stage can the organization can really start to reap the benefits of change.

Using the Change Curve With knowledge of the Change Curve, you can plan how you'll minimize the negative impact of the change and help people adapt more quickly to it. Your aim is to make the curve shallower and narrower, as you can see in figure 2. Figure 2 – Using the Change Curve

As someone introducing change, you can use your knowledge of the Change Curve to give individuals the information and help they need, depending on where they are on the curve. This will help you accelerate change, and increase its likelihood of success. Actions at each stage are:

Stage 1 At this stage, people may be in shock or in denial. Even if the change has been well planned and you understand what is happening, this is when reality of the change hits, and people need to take time to adjust. Here, people need information, need to understand what is happening, and need to know how to get help. This is a critical stage for communication. Make sure you communicate often, but also ensure that you don't overwhelm people: They'll only be able to take in a limited amount of information at a time. But make sure that people know where to go for more information if they need it, and ensure that you take the time to answer any questions that come up.

Stage 2 As people start to react to the change, they may start to feel concern, anger, resentment or fear. They may resist the change actively or passively. They may feel the need to express their feelings and concerns, and vent their anger. For the organization, this stage is the "danger zone." If this stage is badly managed, the organization may descend into crisis or chaos. So this stage needs careful planning and preparation. As someone responsible for change, you should prepare for this stage by carefully considering the impacts and objections that people may have. Make sure that you address these early with clear communication and support, and by taking action to minimize and mitigate the problems that people will experience. As the reaction to change is very personal and can be emotional, it is often impossible to preempt everything, so make sure that you listen and watch carefully during this stage (or have mechanisms to help you do this) so you can respond to the unexpected.

Stage 3 This is the turning point for individuals and for the organization. Once you turn the corner to stage 3, the organization starts to come out of the danger zone, and is on the way to making a success of the changes. Individually, as people's acceptance grows, they'll need to test and explore what the change means. They will do this more easily if they are helped and supported to do so, even if this is a simple matter of allowing enough time for them to do so. As the person managing the changes, you can lay good foundations for this stage by making sure that people are well trained, and are given early opportunities to experience what the changes will bring. Be aware that this stage is vital for learning and acceptance, and that it takes time: Don't expect people to be 100 percent productive during this time, and build in the contingency time so that people can learn and explore without too much pressure.

Stage 4 This stage is the one you have been waiting for! This is where the changes start to become second nature, and people embrace the improvements to the way they work. As someone managing the change, you'll finally start to see the benefits you worked so hard for. Your team or organization starts to become productive and efficient, and the positive effects of change become apparent. Whilst you are busy counting the benefits, don't forget to celebrate success! The journey may have been rocky, and it will have certainly been at least a little uncomfortable for some people involved: Everyone deserves to share the success. What's more, by celebrating the achievement, you establish a track record of success: Which will make things easier the next time change is needed.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

Next Manage Change Learning Stream article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote

Hi Sheree, Thanks for highlighing the Change modes you have had the most success with. It helps to hear directly from those that use them! If anyone is interested we have an article on ADKAR that you can find here: http://www.mindtools.com/community/pages/article/ adkar.php A quick summary of the model is this: The ADKAR Change Management Model helps you implement change effectively by providing a clear information-sharing goal for each stage of your project. The model describes five successive communication goals, which are: Awareness (of the need for change). Desire (to participate and support the change). Knowledge (of how to change). Ability (to change). Reinforcement (to sustain the change). You need to achieve each goal before you can move on to the next. The main benefit of using the ADKAR model is that it encourages you to focus on achieving clear, finite communication goals as you work through the stages of your project. January 10, 2013 sunniegal wrote Hi everyone, I agree the change curve helps describe the stages change recipients travel through, to arrive at a "new" future state. Another model, that I find [u:1zr75jga]very[/u:1zr75jga] useful in linking business results and people in achieving change is the Prosci Change Management Methodology. Some excellent Learning Centre resources available for this methodology are here: http://www.change-management.com/tutorials.htm. Actively managing people through the change process using [color=#0040FF:1zr75jga]A.D.K.A.R. to achieve a collective change in a business or function, dramatically increases the potential for success. By understanding that organisational outcomes are the collective result of individual change, you can bring people with you on the journey, through the stages of [any] change. I hope you all enjoy my two cents worth, and benefit from another perspective of change. cheers, Sheree

January 10, 2013 James wrote Hi Yann What a great acronym! I'm guessing that SARAH is a workplace adaptation of Elisabeth Kubler-Ross' five stages of grief (denial, anger, bargaining, depression, acceptance). However SARAH is much easier to remember! James May 22, 2010 yann wrote Another version of the change curve I remember easily is SARAH: Shock, Anger, Rejection, Acceptance, Hope. The principles are obviously the same. Building on Dianna's comment, change leaders need to recognise indeed the inevitability and even necessity of the shock and anger phases, before people can move on. A delicate balance to maintain is that between accelerating change and allowing people the necessary time and space to go through the motions of shock, anger, rejection. In other words, change cannot be accelerated by skipping phases. May 22, 2010 Dianna wrote I really like the change curve because it wholly acknowledges the "fear and anger" part of the change process. Too often we try to sweep that part under the rug and it only makes it worse. People will naturally fear change and that reaction is normal so when you prepare for this fearful emotional response you can better manage the whole process. It's really help me understand my own reaction to change as well as the reactions of those around me. Dianna May 22, 2010

Return to top of the page

The Iron Triangle of Project Management Balancing Your Budget, Scope, and Schedule (Also known as The Triple Constraint of Project Management.) You're managing the implementation of a new reporting system for your organization. As your project progresses, things happen differently from how you'd planned. You find that you need extra computer hardware, and some tasks have taken longer to complete than you originally predicted.

Learn how to deliver projects within the "iron triangle." © iStockphoto/hanis

To get the tasks completed on time, you consider recruiting more contractors. But, to do this, you'd have to take other costs out of the project's budget. You think about not buying the extra computer hardware that you need, however, this would mean changing the project's scope, so that some functionality isn't delivered. In many projects, the budget, scope and schedule are closely linked. Changes to one of these three key constraints will most likely affect the others, or impact on the quality of the project. This article examines the relationship between the three constraints of budget, scope and schedule, and looks at ideas and tools for helping you deal with the issues that can affect this relationship.

The Iron Triangle The project mandate and project charter identify the project's objectives. At the core of these documents is a requirements statement that says what the project needs to deliver. This includes a definition of what is in and out of scope for the project. It also establishes the project's deadlines and its budget. These constraints of scope, budget, and schedule are known as the "iron triangle" (see figure 1).

Figure 1 – The Iron Triangle of Project Management

Original diagram in the article, "What is Project Management?" Reproduced with permission of the Association for Project Management.

These constraints are considered an iron triangle because you can rarely change one constraint without also impacting the others. The way that you deliver the project within these constraints impacts the quality of the project's outcomes, either positively or negatively. For example, suppose your project mandate is to launch a new standalone IT system. The design phase has overrun significantly. You could consider several options: • Extend your project timeline – Your stakeholders will get the system later than planned, which may cause issues, and may not be an acceptable solution to them. It will also take longer to deliver, and therefore will increase labor costs. However, there may not be any negative impact on the quality of the end product. • Re-plan the rest of the project to deliver future phases more quickly – This may increase project risks if areas such as testing and training are not completed in full. Therefore you may not meet the original quality objectives. This could also increase the cost of the project. • Change scope – You could take elements of scope (functionality, systems, interfaces, processes automated, or departments supported) out of the project so that it can be delivered within the agreed timeline and budget. This will not meet the organization's original expectations of deliverables. Overall costs may also increase if these scope areas are delivered at a later date. The art of project management is for the project team (not just the project manager) to implement the project within these constraints of scope, schedule and budget. When you have an issue that must be resolved, consider which option gives you the best solution – not necessarily the ideal solution – for your particular project.

Note:

In project management, there's a saying that, when considering the three factors of fast, cheap, and good, you can only choose two: • If you deliver the project quickly and cheaply, then it probably won't be very good. • If you deliver it quickly and well, then it won't be cheap. • If you deliver the project well and cheaply, you won't get it very quickly. While this doesn't always happen, there's some truth in these statements. If you have difficult issues to resolve, make sure you think carefully about the solution, and consider its impact on other parts of your project.

Decision Framework Use this framework to help you make decisions about issues that affect the iron triangle. Before you start, discuss with your sponsor the high-level options appropriate for your project. Understand any flexibility you may have in your project budget, delivery timelines, scope, and quality requirements.

Schedule Pressure • Review your critical path remove from this?

. Are there tasks that you can

• Re-plan to determine if you can do tasks differently, or in a different sequence, to reduce your overall delivery timeline. Are there tasks that you can do simultaneously to reduce the overall time required? • Is there contingency time built into the plan in later phases? Can you use this contingency time now, or would this just delay the problem to a later phase? • Is it appropriate to move some scope components into a future project phase so that you can deliver the current phase on time? • Review the tasks included in the plan. Are they all essential to deliver the required project outcomes? Are any tasks unnecessary?

Scope Pressure • Is the change to the scope essential to delivering this project's objectives in this phase? Would it be more appropriate to a new scope request to a "wish list" to consider later? • Can you move some scope areas into a later phase? • Is the definition of business requirements strong enough for the project to continue? Should you suspend the project and review the business requirements?

Tip:

To reduce the likelihood of the scope changing during the project, get stakeholder involvement and approval early on in the business requirements and design phases, so that your project scope definition is as complete as possible. Also, make sure that you have a robust scope control process in place, so that you don't make promises to stakeholders that you can't keep.

Budget Pressure • Can you deliver tasks more cheaply? Can you use cheaper components or cheaper resources? Can you do this without negatively affecting the required levels of quality? • Do all of your planned tasks contribute to the project's outcome? Can you stop any tasks? • Can you reduce project team expenses? For example, can you reduce travel costs? • Do you have any contingencies that you can use?

Further Tips • Beware of "scope creep" –This is when you allow many small changes to be made to your project's scope without thinking carefully about the implications. This can then lead to a set of changes that you would never have accepted if they had all been presented at once. If you suspect that this is happening in your project, conduct a project review to help you see the project as a whole. Then decide how to take things forward. • Remember your deliverables – Don't forget about what you're there to deliver. Focus on the bigger picture when making decisions, and make sure that you're managing benefits actively. • Get project sponsor and steering group support – Make sure that you keep key stakeholders informed and on board with the status of the project. Communicate serious issues, major risks, and scope change requests as soon as you can. Steering group members have the advantage of not being involved in day-to-day delivery, so they can often see things more clearly. • Focus on your project's desired outcome – For example, it may be possible to re-plan a project to deliver on schedule by reducing the time allocated to training or support before you deliver the end-product. If budget is available, you may be able to adequately make up for this by increasing the level of post-implementation support and training.

Key Points The challenge of project management is to deliver the project's objectives within the constraints of the "iron triangle" of budget, schedule, and scope, without affecting overall quality. There are many tools available to support you during the project lifecycle. As a project manager, you must make choices based on what's required for the project to achieve its overall objectives. Take positive action quickly if there are issues to resolve, if there are risks to manage, and if there are problems to overcome. This is what good project management is all about!

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Thanks flaffy! I like the additional elements of resource, risk and customer satisfaction. My perspective on tools like this is that you can add in additional parameters to help your analysis be as robust as it can and as relevant to your situation as it can. Dianna May 15, 2013

flaffyeg2013 wrote Hi Dianna, Hi Bigk, Yes you can add to or modify the three constraints it depends on how you identify your project constraints it could be four as iron triangle (scope, time, cost and quality) or six as in the PMBOK then you could add resources and risk. Also, you could add customer satisfaction. The importance of this tool when using it in analyzing change requests and identify the impacts on all constraints through integrated change control. Refer to the value it is relevant to benefits not to the constraints. Cheers, Flaffy May 13, 2013 darkchocolate wrote The term Iron Triangle is succinct. Sometimes its project sponsors who exacerbate the constraints and the ensuing negotiations between sponsors and project manager may take up time that further impacts scheduling. It can become a very tight triangle. November 13, 2011 bigk wrote Hi Dianna Transferring into practical options often needs your thoughts in the middle just as much as at the start or the end. Planning always helps in adapting to fit. This often though needs greater attention to the specific requirement to be completed. Bigk July 28, 2010 Dianna wrote Interesting point about value and it's importance to project management - that's one of the things i most appreciate about these tools is the ability to think about them crtically and then add to or modify them slightly to make them more relevant to our particular situation or experience. Great food for thought bigk thanks! Dianna

July 28, 2010 bigk wrote Hi The recent pmbok (fourth edition) has been updated, there are six items very similar to the "iron triangle" constraints, although I don't have the pmbok to check all the details, I have seen it suggested that the six items are used similar to the three items here. The triangle though might not being sufficient without using value as another constraint to assess the project and the three constraints here. It was suggested that these three items should be four items, value being the fourth rather than value being the overall objective, it might also be a constraint that should be known and assessed in cost terms. The new six items are not known as constraints but are similar to (model) the items that need monitored and quantified to use to manage the progress and the project successfully. Regarding the "iron triangle" without reference to the pmbok, I would still use another item in addition to the three constraints to manage project constraints, the next item (fourth) being value, but value in its larger context. A possible option would be to view the triangle as a non solid shape... or a triangle (with more than three items) or a circle, this could allow another item to be included or more if needed. The three or more items can all be monitored as a set of items and placed together as a circle. It has been suggested that it is a diamond or perhaps even a polygon, or a hexagonal shape, there are already a few suggestions from people who have the pmbok. If you would like another comment about the iron triangle... I have another comment about it, or how to get the information to deliver success and the project outcome success. Bigk July 28, 2010

Return to top of the page

The Planning Cycle A Planning Process for Medium-Sized Projects The Planning Cycle brings together all aspects of planning into a coherent, unified process. By planning within this structure, you will help to ensure that your plans are fully considered, well focused, resilient, practical and costeffective. Planning is an iterative process.

You will also ensure that you © iStockphoto/djgunner learn from any mistakes you make, and feed this back into future planning and Decision Making. Planning using this cycle will help you to plan and manage ongoing projects up to a certain level of complexity – this will depend on the circumstance. For projects involving many people over a long period of time, more formal methodologies and approaches are necessary (see Managing Large Projects and Programs ).

How to Use the Tool It is best to think of planning as a cycle, not a straight-through process. Once you have devised a plan you should evaluate whether it is likely to succeed. This evaluation may be cost or number based, or may use other analytical tools. This analysis may show that your plan may cause unwanted consequences, may cost too much, or may simply not work. In this case you should cycle back to an earlier stage. Alternatively you may have to abandon the plan altogether – the outcome of the planning process may be that it is best to do nothing! Finally, you should feed back what you have learned with one plan into the next. The Planning Cycle is shown in figure 1:

The stages in this planning process are explained below:

Stage 1. Analysis of Opportunities The first thing to do is to do is to spot what needs to be done. You will crystallize this into a formal aim at the next stage in the process. One approach to this is to examine your current position, and decide how you can improve it. There are a number of techniques that will help you to do this: • SWOT Analysis

:

This is a formal analysis of your strengths and weaknesses, and of the opportunities and threats that you face. • Risk Analysis

:

This helps you to spot project risks, weaknesses in your organization or operation, and identify the risks to which you are exposed. From this you can plan to neutralize some risks. • Understanding pressures for change: Alternatively, other people (e.g. clients) may be pressing you to change the way you do things. Alternatively your environment may be changing, and you may need to anticipate or respond to this. Pressures may arise from changes in the economy, new legislation, competition, changes in people's attitudes, new technologies, or changes in government.

A different approach is to use any of a whole range of creativity tools to work out where you can make improvements. These creativity tools culminate in the powerful Simplex process .

Stage 2. Identifying the Aim of Your Plan Once you have completed a realistic analysis of the opportunities for change, the next step is to decide precisely what the aim of your plan is. Deciding and defining an aim sharpens the focus of your plan, and helps you to avoid wasting effort on irrelevant side issues. The aim is best expressed in a simple single sentence. This ensures that it is clear and sharp in your mind. If you are having difficulty in formulating the aim of your plan, ask yourself: • What do I want the future to be? • What benefit do I want to give to my customers? • What returns do I seek? • What standards am I aiming at? • What values do I and my organization believe in? You can present this aim as a 'Vision Statement' or 'Mission Statement'. Vision Statements express the benefit that an organization will provide to its customers. For example, the vision statement for Mind ToolsT is: 'To enrich the quality of our customers lives by providing the tools to help them to think in the most productive and effective way possible'. While this is wordy, it explains what this site aims to do. Mission statements give concrete expression to the Vision statement, explaining how it is to be achieved. The mission statement for this site is: 'To provide a well structured, accessible, concise survey of the best and most appropriate mind tools available'.

Stage 3. Exploring Options By this stage you should know where you are and what you want to do. The next thing to do is to work out how to do it. The Creativity Tools section of this site explains a wide range of powerful creativity tools that will help you to generate options. At this stage it is best to spend a little time generating as many options as possible, even though it is tempting just to grasp the first idea that comes to mind. By taking a little time to generate as many ideas as possible you may come up with less obvious but better solutions. Just as likely, you may improve your best ideas with parts of other ideas.

Stage 4. Selecting the Best Option Once you have explored the options available to you, it is time to decide which one to use. If you have the time and resources available, then you might decide to evaluate all options, carrying out detailed planning, costing, risk assessment, etc. for each. Normally you will not have this luxury.

Two useful tools for selecting the best option are Decision Matrix Analysis and Decision Trees . Decision Matrix Analysis helps you to decide between different options where you need to consider a number of different factors. Decision Trees help you to think through the likely outcomes of following different courses of action.

Stage 5. Detailed Planning By the time you start detailed planning, you should have a good picture of where you are, what you want to achieve and the range of options available to you. You may well have selected one of the options as the most likely to yield the best results. Detailed planning is the process of working out the most efficient and effective way of achieving the aim that you have defined. It is the process of determining who will do what, when, where, how and why, and at what cost. When drawing up the plan, techniques such as use of Gantt Charts and Critical Path Analysis can be immensely helpful in working out priorities, deadlines and the allocation of resources. While you are concentrating on the actions that need to be performed, ensure that you also think about the control mechanisms that you will need to monitor performance. These will include the activities such as reporting, quality assurance, cost control, etc. that are needed to spot and correct any deviations from the plan. A good plan will: • State the current situation. • Have a clear aim. • Use the resources available. • Detail the tasks to be carried out, whose responsibility they are, and their priorities and deadlines. • Detail control mechanisms that will alert you to difficulties in achieving the plan. • Identify risks, and plan for contingencies. This allows you to make a rapid and effective response to crises, perhaps at a time when you are at low ebb or are confused following a setback. • Consider transitional arrangements – how will you keep things going while you implement the plan?

Stage 6. Evaluation of the Plan and its Impact Once you have worked out the details of your plan, the next stage is to review it to decide whether it is worth implementing. Here you must be objective – however much work you have carried out to reach this stage, the plan may still not be worth implementing. This is frustrating after the hard work of detailed planning. It is, however, much better to find this out now than when you have invested time, resources and personal standing in the success of the plan. Evaluating the plan now gives you the opportunity to either investigate other options that might be more successful, or to accept that no plan is needed or should be carried out.

Depending on the circumstances, the following techniques can be helpful in evaluating a plan: • PMI

(Plus/Minus/Interesting):

This is a good, simple technique for 'weighing the pros and cons' of a decision. It involves listing the plus points in the plan in one column, the minus points in a second column, and the implications and points of uncertainty of the plan in a third column. Each point can be allocated a positive or negative score. • Cost/Benefit Analysis

:

This is useful for confirming that the plan makes financial sense. This involves adding up all the costs involved with the plan, and comparing them with the expected benefits. • Force Field Analysis

:

Similar to PMI, Force Field Analysis helps you to get a good overall view of all the forces for and against your plan. This allows you to see where you can make adjustments that will make the plan more likely to succeed. • Cash Flow Forecasts

:

Where a decision is has mainly financial implications, such as in business and marketing planning, preparation of a Cash Flow Forecast can be extremely useful. It allows you to assess the effect of time on costs and revenue. It also helps in assessing the size of the greatest negative and positive cash flows associated with a plan. When it is set up on a spreadsheet package, a good Cash Flow Forecast also functions as an extremely effective model of the plan. It gives you an easy basis for investigating the effect of varying your assumptions. • "6 Thinking Hats"

:

6 Thinking Hats is a very good technique to use to get a rounded view of your plan and its implications. It provides a context within which you can examine a plan rationally, emotionally, optimistically, pessimistically and creatively. Any analysis of your plan must be tempered by common sense. If your analysis shows that the plan either will not give sufficient benefit, then either return to an earlier stage in the planning cycle or abandon the process altogether.

Stage 7. Implementing Change Once you have completed your plan and decided that it will work satisfactorily, it is time to implement it. Your plan will explain how! It should also detail the controls that you will use to monitor the execution of the plan.

Stage 8. Closing the Plan Once you have achieved a plan, you can close the project. At this point is often worth carrying out an evaluation of the project to see whether there are any lessons that you can learn. This should include an evaluation of your project planning to see if this could be improved.

If you are going to be carrying out many similar projects, it may be worth developing and improving an Aide Memoire . This is a list of headings and points to consider during planning. Using it helps you to ensure that you do not forget lessons learned in the past.

Key Points The Planning Cycle is a process that helps you to make good, wellconsidered, robust plans. The first step, the analysis of opportunities, helps you to base the plan firmly in reality. The second, definition of the aim, gives your plan focus. The third stage is to generate as many different ways for achieving this aim as possible. By spending time looking for these you may find a better solution than the obvious one, or may be able to improve the obvious solution with parts of other ones. Next select the best approach, and make a detailed plan showing how to implement it. Evaluate this plan to make sure that it will be worth implementing. If it is not, return to an earlier stage and either improve the plan or make a different one. If no plan looks like producing enough benefit to justify the cost, make no changes at all. Once you have selected a course of action, and have proved that it is viable, carry it out. Once it is finished, examine it and draw whatever lessons you can from it. Feed this back into future planning.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote This comprehensive tool is a must-have for people managing larger projects. It has a lot of steps and each of them is necessary if you want to bring about a successful conclusion to your project. I know it is an overused cliche, however I'll repeat it anyway because it is a fundamental truth: Failing to plan, is planning to fail... Cheers! Dianna July 12, 2010

Return to top of the page

The RACI Matrix Structuring Accountabilities For Maximum Efficiency and Results Related variants: ARCI, RASCI, RASIC, RACI-V and CAIRO Teamwork is often seen as an effective way to accomplish work goals. And there is no doubt that when teams work well together the results can be impressive. Unfortunately, the opposite is true and all too common: Teams that fail to work well can also fail to deliver the desired results.

© iStockphoto

When several people work on a project it is easy to assume that someone else is taking care of a particular detail or assignment. It is also easy to point fingers and assign blame when one of those jobs is done poorly or not done at all. Many factors can contribute to the underperformance of a team, but unless responsibilities and accountabilities are clear, there can be a significant risk that problems will arise. With complex, time-sensitive or mission-critical projects, or in situations where people are ducking responsibility, it's often worth taking the time to think through the roles that you and your team members must play in every task that your team undertakes. Without this clarity, you will most-likely find gaps, duplication and confusion. Teamwork will be frustrating, inefficient and you are less likely to deliver good results. In these situations, the delegation of tasks and other responsibilities can be too important to leave to chance. The RACI Matrix is a system that brings structure and clarity to assigning the roles people play within a team. It is a simple grid system that you can use to clarify people's responsibilities and ensure that everything the team needs to do is taken care of.

RACI explained The acronym RACI stands for: • R = Responsible. • A = Accountable. • C = Consulted. • I = Informed.

Using the RACI system, you list every task, milestone and decision, then clarify who is responsible, who is accountable, and where appropriate, who needs to be consulted or informed. Responsible – these people are the "doers" of the work. They must complete the task or objective or make the decision. Several people can be jointly responsible. Accountable – this person is the "owner" of the work. He or she must sign off or approve when the task, objective or decision is complete. This person must make sure that responsibilities are assigned in the matrix for all related activities. There is only one person accountable, which means that "the buck stops there." Consulted – these are the people who need to give input before the work can be done and signed-off on. These people are "in the loop" and active participants. Informed – these people need to be kept "in the picture." They need updates on progress or decision, but they do not need to be formally consulted, nor do they contribute directly to the task or decision. Other Variants

ARCI Some people prefer to use the acronym ARCI, reflecting the importance of the "Accountability" role. RASCI or RASIC A fifth element, "Supportive," is sometimes interjected to make the acronym RASCI. Supportive refers to people who provide resources and assistance to the people responsible for the work. RACI-V In some situations, another role is included: "Verifies." This role provides the checks needed to make sure the work is done according to predetermined criteria. CAIRO This includes a fifth category: "Omitted" or "Out of the loop". this would be used to designate people whom you consciously decide not to involve in project communications.

Using the Tool To complete a RACI Matrix: 1. List all the tasks, activities and decisions that your team works on. It's often good to involve the whole team in doing this, helping you drill down to the core tasks that must be completed if the project to be a success. 2. List all the functions of people in the team. Sometimes this means you need to list each individual team member. But if a function is performed by several people, you should list the function rather than each individual. 3. Then create a matrix (see figure 1) from the two lists you have made. List tasks, activities and decisions as row headers in the

left hand column, and place the functions/roles as column headers. Figure 1: Example RACI Matrix

Tasks, milestones and decisions

Function A (e.g. Line Supervisor)

Function B (e.g. Manager)

Task 1

R

A

Task 2

R

Task 3 Task 4

A

Function C

Function D

I

A

R

C

A

R

C

C

I

4. Now plot the RACI for each task etc listed. Indicate who is responsible, who is accountable, who needs to be consulted and who needs to be informed. 5. And now check the RACI for each task: Check this carefully, as this is the step that ensures everything gets done! For every task (row): • There must be one (and only one) person accountable • There must be at least one responsible • 'Consulted' and 'informed' are optional on each row. Also, make sure that everyone involved really needs to be. There is a saying that "too many cooks spoil the broth". Too many people involved, even if they are only 'consulted' and 'informed' can make work inefficient and more difficult than is necessary. 6. Having already checked that everything gets done, the next step of analyzing the RACI matrix helps ensure things get done right! You do this by analyzing the roles that each function will perform. This means looking vertically at the Rs, As, Cs and Is assigned and asking the following questions: • Does one person or function have too many responsibilities? If so, there is a risk that he or she may perform poorly or not be able to complete the work. • Does anyone have too many or all the As? If so its well worth looking again at the design of people's jobs. Can this person really monitor and oversee all these tasks fully and well? Or is it better to delegate some of the accountability (and hence the checking and balancing) to other people in the team? • Is any one person or function involved in every task? This is probably not necessary and you should look again at how tasks are delegated and prioritized. 7. Once you have checked completed steps 5 and 6, you have checked the completeness and integrity of the roles and

functions in your team. The final step is to communicate the RACI matrix to all team members and keep it updated as things change.

Key Points One of the biggest challenges of team working (particularly in areas where there's little margin for error) is to make sure everything is done completely and well. By taking a structured approach to role assignment using the RACI Matrix, you can plot and check who is responsible and accountable for each team task, and also check the integrity of each person's roles. In so doing, you can minimize the risk of gaps, overlaps and confusions and so have a greater chance of running a highly effective and efficient team. Once you understand people's roles, responsibilities and accountabilities, the next step is often to think through the scheduling of people's time so that projects can be completed as quickly and efficiently as possible.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... lkanavas wrote Another great article, however, can you pls provide a specific example as this would illustrate better?

Kindly L Kanavas July 18, 2012 Dianna wrote This is such an invaluable tool when you have a number of different people working on the same project. It's so easy for details to be overlooked and if you aren't really sure who is responsible for what then these overlooked items often don't get done. And that's when the back peddling begins! You start to hear things like, "I thought Steve was taking care of that" or "Well, Maryanne really should have known this would need to be done!" "I sent my part of the report weeks ago, don't know why Phil didn't notice things were falling behind." RACI helps you communication responsibilities and avoid potential oversights and shirking of responsibility. Let us know if you have used RACI or if you have any questions about it. Dianna September 30, 2010

Return to top of the page

The Responsibility Assignment Matrix (RAM) Knowing Where the Buck Ultimately Stops It takes a lot of effort to keep a large project running smoothly. With a large number of variables, people, and deliverables, it’s hard to keep on top of everything that’s happening. Consider the following scenario: Hal (the distressed project manager): "What do you mean, we don’t have the test results yet?! What has Katy been doing? Get Katy!"

© iStockphoto/joxxxxjo

Katy: "No, Hal, I wasn’t responsible for getting that done. Joan has more expertise in that area, remember? I’ll ask Joan what happened." Joan: "Gee, Katy, I know I have more experience with these reports, but I was waiting for you to contact me so we could review them together." Do you recognize anyone you know? This type of situation is repeated daily in organizations across the globe. And most of the time, there’s no incompetence or bad intentions involved. More often, problems like this are the result of inadequate planning and poor communication. Successful projects have a clear breakdown of who is ultimately responsible for each aspect of the project. Without clear, written, and agreed-upon accountability, it’s far too easy to for communication to fail and for responsibilities to be muddled. So how do you avoid this?

Developing a Responsibility Assignment Matrix One tool that project managers use to keep these assignments clear is the Responsibility Assignment Matrix (also called the RAM, or the Responsibility Matrix). This matches deliverables with the people who are responsible for them. For every piece of the project, the matrix shows who needs to contribute what for the project to be completed. For example, let’s say that you’re upgrading your customer service delivery system, and you need to train your staff to use new procedures and tools.

Step One: Define Your Deliverables Using a Work Breakdown Structure , you define three key deliverables for this training project, with a few subcategories for each: • Identify training needs: • Survey current practice. • Define new practice. • Coordinate the training: • Locate resources. • Prepare training schedule. • Manage training. • Evaluate the results: • Re-survey practices after implementation. • Analyze results.

Tip:

A Work Breakdown Structure (WBS) is a project planning tool used to break a project down into smaller, more manageable pieces of work (deliverables). It's not a list of every task: rather, it's a "tree" structure showing the meaningful groups of activities that make up the main segments of the project.

Step Two: Identify the People Involved Map out who is on your project team. By creating a chart of individuals who are available, you can then delegate work assignments based on expertise, and you can recruit talent that you’re missing. This step is often called an “Organization Breakdown Structure” because it creates an organizational chart for your team. Level 1

Project Manager: Kim

Level 2

Customer Service Manager: Ron

Level 3

Customer Experience Coordinator: Terry Training Coordinator: Nancy Customer Service Supervisor: Reagan

Level 4

Customer Service Representative: John

Step Three: Create Your Responsibility Matrix Draw a matrix. The deliverables are the column headings, and the people are the row titles. Identify training needs Person

Survey current practice

PM: Kim

Define new practice

Locate resources

Prepare training schedule

A

A

A

I

CSM: Ron

A

R

CEC: Terry

R

C

TC: Nancy

Coordinate the training

I

R

R

Evaluate the results Resurvey practices

Analyze results

A

A

R

R

R

Identify training needs Person

Survey current practice

Define new practice

CSS: Reagan

R

C

CSR: John

C

C

Coordinate the training Locate resources

Evaluate the results

Prepare training schedule

Resurvey practices

Analyze results

C

R

C

C

With your team, determine accountabilities as well as other levels of involvement for each item in your Work Breakdown Structure. A useful framework to determine role assignments is RACI defines four levels of involvement:

. This

R = Responsible (People who do the work) A = Accountable (People who make sure the work gets done) C = Consulted (People who provide input before and during the work) I = Informed (People who are kept informed of progress) Other levels of involvement may include “assist”, “coordinate”, “sign off”, and “review”. You can decide how to assign responsibility for your project and your team. But you must be sure that ultimate accountability and responsibility for performing the work are agreed upon and communicated.

Step Four: Communicate When your Responsibility Assignment Matrix is complete, communicate it to all stakeholders. It’s a good idea to post it in an area where people will see it. Used effectively, the RAM helps people understand what they should be doing at all stages of the project.

Key Points Project teams can easily lose focus on what needs to be done and who needs to do it. People may assume that somebody else is doing something – and before long, key pieces of work fall behind schedule. To avoid this common problem, consider developing a Responsibility Assignment Matrix for your team. This matrix clearly identifies which role each team member has agreed to take on for each of the project’s main deliverables. With these assignments, you can eliminate miscommunication about who’s doing what – and you can help to ensure that your project is successful.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote This is a great tool for managing any project. The step by step approach of defining what needs to get done, who do you have available (and their skills) and then assigning people to jobs sounds like such a simply approach ... yet is sometimes not done! Then, the final step of communicating to everyone about who is doing what is critical to successfully managing the project and it's implementation! Has anyone had experience of using this approach and how did it go for you? Midgie September 17, 2010

Return to top of the page

Why Change Can Fail Knowing What Not To Do There's no denying it – change is tough! When thinking about change, we often look for "how to" tips: How do you start a change process? How do you engage people in change? How do you make sure you follow through on your change plans? With something as complex as change, forward-thinking "howtos" are usually only half of the picture.

Learn how change can fail. © iStockphoto

So don't just ask how change succeeds, ask why it fails: This can offer valuable lessons as well! Look back on a recent change initiative. Have you ever caught yourself saying, "We should have done this." or "If only we'd done that."? If yes, you can probably appreciate exploring change from a failure perspective. There are so many variables to consider in any change project – and so many things that can go wrong! So let's consider "what goes wrong." Learning from experience is very powerful, and it's worth applying the lessons from other people's mistakes before you start down the path of change. Here are seven main reasons that change can fail.

Change Can Fail Because... 1. It's Not Compelling Change needs a clear and valid reason. Don't "push it through" – it's much better to convince people that it's important and urgent – only that way can you get a clear commitment from others. To ensure that you have a solid foundation to build a change movement, identify the reasons for the change. • What conditions create the need for change? • What are the underlying causes? • Have you identified and made a case for the change? • Have you identified the one crucial reason for change? Do the necessary work up-front to gain people's commitment and build their desire to see the change through to its completion. Get the right people on board, and start with a clear rationale and well-defined objectives. Kotter's 8-Step Change Model calls this

the need to create a sense of urgency. After all, it's normal human nature to resist change unless you see a clear reason for it. For detailed ideas on figuring out where change needs to happen, see the Burke-Litwin Change Model . This gives you a framework for understanding the dynamics of organizational change, and for applying it to your situation.

2. It's Not Required Change cannot be an option. People often don't want to change, and they often won't, unless they're have good reason to. This means that top management must commit wholeheartedly to the change, and they should accept nothing less from everyone else. • Do your company's leaders openly support the change? • Do they "walk the talk" and do as they say? • Do they demand commitment to change? • Do you have a way to measure staff engagement and participation? Asking people to change isn't enough – it needs to be a requirement.

3. It's Not Communicated You can demand change and create a convincing reason for it, but you also need excellent communication. Many people may, for good reasons, prefer the status quo – they'd rather leave things as they are. So make sure that the reason for change is frequently and effectively communicated. • Do your company leaders talk about the change with passion? • Do they express the vision associated with the change? • Do they focus on what's in it for individuals, as well as the overall rationale? Design communication to win people over. Be sure to address the reasons not to change – if allowed, they may become more important than the reasons to proceed. The idea of the change curve suggests that support for change usually rises slightly at first, then drops down before heading back up again. Fear, anger, and resentment are common at this lower stage, and there's a decrease in commitment. Open, honest, and sincere communication can play a large role in getting past this.

4. It Doesn't Involve the Right People Leaders are important to change. But many other people are also critical to pushing forward the change process. To avoid an "us vs. them" mindset, seek change agents throughout your organization. • Are the people expected to execute the change also involved in the planning stages?

• Do you seek their opinions for implementation ideas? • Do you use insiders to implement the change? • Do you use managers and supervisors to help win support for the process? • Do you engage informal and formal leaders (Kotter's coalition for change) in the process? Look throughout your organization. Identify the people who are most affected by the change as well as individuals who are in a position to champion the change. By combining these forces, you can effectively convince people that the change is aligned with their personal agendas.

5. The Implementation is Poorly Planned You may prepare people perfectly. However, unless your change plan is workable and effective, it probably won't be successful. The road to change has many obstacles, so your planning has to be as thorough as possible. • Have you considered the impact on people – not just on finances and operations? • Does your methodology fit your business? • Does your methodology fit your corporate culture? • What reward systems (bonuses, recognition, feedback, scorecards) can you use to support the change? • What are your contingency plans, in case things go wrong or need adjustments? • Do you have enough resources? • What are the consequences of the change to other parts of your organization? • What is the cultural impact of the change? What should you adjust to support the change? • Is your approach flexible enough to survive the unexpected and inevitable problems? • Do you know when to stop talking and start doing? Lewin's Change Management Model three-stage process:

shows change as a

1. Unfreeze (prepare the organization for change) 2. Change (help people embrace change) 3. Refreeze (help the changes settle in and become the new reality) Look at your planning and implementation from this perspective. This may help you see the bigger picture and keep your vision, despite the struggles you face.

6. Success Takes Too Long to Arrive Success can motivate. For people to keep going through the pain of change, it helps to have some obvious "wins" spread throughout the change process. Include some ways to achieve a few key results early in your implementation plan.

7. There's Too Little Follow-through Change projects usually get lots of attention up front, but then they can fade out well before completion. If done well, change can create lots of buzz and excitement. Then, if you have some quick wins, the momentum can build. However, this is when change leaders can get lazy. They may consider their work done and move onto the next project, or they may get bored with the humdrum activities of implementation, and lose focus on the things that are important. Don't let this happen! Follow through to the end, and make sure your plan is implemented. • Who is responsible for follow-through? • Is there a clear project manager whose job is to see the project to completion? • What is your plan to ensure that victory isn't declared too soon? • Are the change agents as motivated and passionate as the leaders? Have the leaders given the responsibility for passion to other people? • Have you thought about ways to keep high levels of commitment and determination? Many of the reasons that change fails can be "turned around" to make change work. Be aware of both sides of the issue, and you can better prepare for the challenge of change. See our articles on Change Management to learn how to manage the change process from start to finish. You'll find tips on what change involves, who should participate, and how to build an effective change process. This article, and the others mentioned above, will help you prepare for the changes you need to implement.

Key Points It isn't easy to lead or participate in change, and change can fail for many reasons. Understand what contributes to success – and learn what contributes to failure, so you'll know what to avoid. Then you'll have a more well-rounded and comprehensive approach to planning and preparation. That's really the key to a successful change.

Did you find this article helpful?

Click to vote no

No Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page

Why Do Projects Fail? Learning How to Avoid Project Failure We can probably all think of projects that have "failed" – perhaps processes got worse rather than better, maybe they were cancelled because of cost overruns, or perhaps systems were launched with fundamental errors. How do you know when – and why – a project has failed? In many cases, the reason for An impossible business case is one common reason for project failure. failure is obvious. However, the © iStockphoto/emmgunn definition of failure isn't always clear: one project with a significant delay might be described as a failure; yet another, with a similar delay, might be seen as a stunning success. In this article, we'll define project failure, and explore the factors that cause some projects to fail.

Definition of Project Failure A project is considered a failure when it has not delivered what was required, in line with expectations. Therefore, in order to succeed, a project must deliver to cost, to quality, and on time; and it must deliver the benefits presented in the business case. The requirements for success are clear and absolute – right? Unfortunately, it's not that simple. Because the second part of our definition of success is that the project must be delivered "in line with expectations." If key stakeholders agreed that a project had to exceed its initial budget, the project may still be considered a success. Likewise, if a project delivered everything that was in the detailed project designs, it may still be considered a failure if it didn't include vital elements that the key stakeholders needed. This doesn't seem fair, but project success and failure isn't just about the facts, nor is it simply about what was delivered. It's also, crucially, about how the project is perceived.

Reasons for Project Failure Here are some of the main reasons why projects fail:

The wrong business requirements have been addressed If your project is set up to deliver the "wrong thing," it may be considered a failure even if everything is delivered on time, within budget, and to the required quality. This seems harsh. But if your

project doesn't deliver what the organization really needs, this will inevitably negatively affect how it's perceived. This is why it's so important to conduct a thorough business requirements analysis .

It's not possible to deliver the business case If your business case can't be delivered, then you have an impossible task. To make things worse, after the business case is approved, delivery of other things then becomes dependent on your project. This makes changing your project's deadlines, budgets and expectations more difficult. For example, once you've promised to deliver a new airport baggage management system, airlines may schedule additional flights for shortly after the system's launch, so that they can take advantage of the new capacity. If the baggage system doesn't work, or if it has major problems during testing, it may be hard to convince senior managers to allow the project to be delayed, because they will have to give up promised increased revenue. When you write your business case, make sure you think through the project requirements in detail, and identify what's needed to ensure that you can deliver those requirements. Don't just list assumptions – make sure you explore them thoroughly. Review other, similar projects, so that you don't forget any major items. If you're delivering a new system, review your hardware and interface requirements. If you have major risks, include sufficient contingency resources (people, budget, and time) to manage those risks appropriately. Remember that implementing change is hard ! Be realistic, and be ready to have some difficult conversations. For instance, your CEO may be disappointed that he can't have what he wants before the year end, or key users may say that they really need a fully featured product at the end of phase one. However, it will be a lot harder to have these conversations at a future date, when your project is in trouble! In many cases, business case documentation is written before a project manager is assigned. If you're the incoming project manager, make sure you don't simply accept these documents as they are! You're responsible for delivering the project, so be sure to review the business case. Validate assumptions, and identify any gaps or areas that need more detail. If difficult conversations are needed, have them now. Once deadlines, requirements, and budgets are set, expectations are much more difficult to change!

Governance is poor Few projects ever start without a sponsor . This is the person who has identified the need for change in an area of the business, and who is committed to making that change happen. He or she plays a vital role in ensuring the project's success. A good sponsor can make a mediocre project fantastic, and a poor sponsor can delay and frustrate a fantastic project team.

The project sponsor is supported by the project's governance bodies , usually in the form of a steering group. These governance roles are essential: they provide direction, guidance, and critical review of the project and its progress. As project manager, you're involved in the day-to-day running of the project, but governance groups can take a step back and look at the project from a different perspective. They can ask difficult questions about progress and performance. They may see things that you've overlooked. However, they can also support you by providing contacts and insights that help you get things done, and by providing "political cover" when you need it. Project managers don't usually have any influence over who their project sponsor is. Sponsors either self-select, or they're chosen because of their position in the organization. However, you often have more influence over who is in your steering group. As such, if you know that your project sponsor lacks passion for the project, or if the sponsor doesn't like to say no to people who keep trying to expand the project scope, then make sure you balance this with tougher or more engaged steering group members.

Implementation is poor If you deliver your project competently, you'll avoid poor implementation – right? Unfortunately, it's not that clear. Delivery can be complex. You need to manage risks, issues, and scope; manage your team; and communicate with stakeholders. Delivering change is hard, and not everything is in your control. Therefore, being competent isn't enough for good implementation, but it's a good start! There are a lot of tools available to help you. Take our quiz on your project management skills to get started.

People lose focus on the project's benefits Projects are based on a list of benefits that must be delivered. For example, you may need a faster customer service process, you may need to produce products more cheaply, or you may need to improve the quality of your service. These benefit statements should be refined so that they're clear, concise, and quantified. From these benefit statements, a set of "things to do" is generated. For example, you may need to consult customers, redesign products, or implement a new system. The outcome of this is a business case document that analyzes the project in terms of costs, and of the benefits will be delivered. The project team then focuses on detailed planning, and on delivering the line items in the project plan – building a new system, developing training packs, mapping out new processes, and so on. At this stage, the team may forget about the benefit requirements. This often results in a project deliverable that's well built, but doesn't provide the necessary benefits. For example, if the project plan focuses on designing and building a system, you could get a fantastic system, but one that's not being used by the business.

To avoid this problem, adopt a benefits management approach throughout the life of the project, and remember the need to deliver the required benefits when you're planning and delivering your project.

The environment changes This is probably the trickiest area. If the business's needs change, then your business case can become outdated before you've actually completed the project. You may have to review your original requirements and goals partway through the project to decide how to proceed, and this may result in changing the scope of your project – or even canceling the project altogether! If you're working in an environment that's changing fast, you can help reduce the risks by doing the following: • Making timely decisions – If the project is clearly not going to be able to deliver the revised requirements, don't ignore this. The sooner you communicate this, and the sooner you make a decision about the project's future, the better. • Considering smaller projects – It's more difficult to change direction in a large cruise ship than in a tugboat. So, think about whether a proposed project's scope and delivery timeline are appropriate within your business environment. Delivering projects in smaller pieces is not always appropriate, but it's worth considering. • Managing expectations – Just because you cancel a project does not automatically mean that the project is considered a failure. This depends on many factors, including how you manage the involvement of key project stakeholders in the decisionmaking process.

Key Points For a project to be successful, it's not enough simply to manage your project competently, and deliver a good quality product. To avoid failure, make sure you have identified the right business requirements, created an achievable business case, put strong project governance into place, managed a high-quality implementation, focused on benefits, and monitored your changing environment. Above all, be sure to manage the expectations of your stakeholders, so that they stay supportive. After all, these are the people who will declare your project to be successful – or otherwise.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Midgie wrote Hi Meagan, It is indeed easier to remember why things didn't work vs. why they did I call it selective memories! Yet, when we take the time to reflect upon all the positives, we can find a lengthy list of things!! By the way, that is one of the things I love about Mind Tools ... it does put ideas and tools in one place for easy reference, and in a very easy to understand and apply manner! If you are looking for a particular tool or resource, just let me know and I'll see if we have something that fits the bill! Hope to see you around the Forums. Midgie May 11, 2010 MeaganS wrote Sometimes it's easier to remember why things didn't work vs. why they did. Showing it from this side, you realize how many skills are required to lead a project team and get the job done. Good leadership...good organizational skills...good communication skills (listening too!)...good emotional intelligence...good influencing skills....good decision making skills....good problem solving skills...am I missing anything? Thanks for putting all of these ideas and tools all in one place for easy reference. May 10, 2010

Return to top of the page

Words used in... Project and Program Management The terms "project management" and "program management" are familiar ones in most businesses and industries. Yet these terms, and other specialist words in the field, can mean different things to different people. Often, this is because people pick these buzzwords up and start using © iStockphoto/mattjeacock them, without ever really understanding the ideas behind them. This can lead to a great deal of confusion! This "Words" page is designed to help you navigate your way through the minefield of project and program management "speak": It provides a quick reference glossary of words commonly used in the field of project and program management, with typical definitions. If your organization uses a specific project management methodology, always refer to your methodology-specific glossary. This page covers the following terms:

People and Organization • Program Manager • Project Analyst • Project Manager • Project Office • Project Sponsor • Stakeholders

Documents • Business Case • Change Control • Post Implementation Review (PIR) • Project Charter • Project Initiation Document (PID) • Project Mandate • Work Breakdown Structure (WBS)

Monitoring and Reporting • CARDI Log – (Constraints/Assumptions/Risks/ Dependencies/Issues) • RAG Status • Project Dashboard

Scheduling • Critical Path • Crash • Gate • Milestone • Gantt Chart • PERT Chart

Costing • Fixed Price • Cost Plus Pricing • Time and Materials Pricing

General Terms • Baseline • Scope • Escalation • Slippage • Turnkey Projects • PRINCE2 • PMBOK • Agile Project Management Terms are defined below: Agile

Agile Project Management uses short development phases and integrated testing phases, rather than the single development phase associated with traditional "waterfall" project management approaches. It's most suitable for projects that are fast-moving or subject to frequent change, such as IT projects and business startups. Baseline

The initial approved project plan (including scope, budget and schedule). The progress of the project is monitored against the baseline, and any changes to the plan are expressed relative to the baseline.

Business Case

The business case sets out the benefits the project is designed to deliver, how it will achieve them, what it will cost and how long it will take. It is usually produced in two stages: the Initial Business Case is used to get approval in principle for the project. Once this is secured, the project manager's first responsibility will be to develop the full business case, including detailed costings and schedules. Usually, this will also have to be approved by a senior management group before the project can go ahead. CARDI Log

A CARDI Log records Constraints, Assumptions, Risks, Dependencies and Issues that are associated with a project. For each type, it will usually show who identified the constraint, assumption, risk, dependency or issue; who is responsible for managing it; and the action that is being proposed or taken. Of the five parts of the log, the Risk Log is generally the most used. A risk is potential issue: conversely, an issue is a risk that has actually happened. Change Control

If a change needs to be made to some aspect of the baselined project plan, a Change Control document needs to be filled in, and approved. This will record the justification for the change, who approved it, and the impact the change has on cost and schedule. Approved changes are gathered together in a Change Log. Cost Plus Pricing

Cost Plus Pricing is a form of contract pricing where the contractor calculates the price of work based on the cost, plus a fixed fee or (more usually) a percentage fee. This form of pricing is attractive to contractors as it limits the risk to them. It's usually less attractive to project managers because it makes budgeting difficult, and means that the project risks additional costs if timescales are extended, or if additional equipment needs to be brought in. Cost Plus Pricing is particularly risky for project managers because contractors are not motivated in any way to work quickly or efficiently (in fact, it incentivizes contractors to prolong projects.) Crash

When the overall project schedule needs to be reduced, and it's acceptable to incur extra cost to do this, the project's critical path is "crashed" or shortened by allotting extra resources to key activities on it. Critical Path

During a project, many activities take place at the same time. However some activities have to be done in sequence. The critical path of a project is the sequence of tasks which defines the minimum possible duration of the project. Delays in any of the activities on the critical path will delay completion of the project.

Escalation

If a problem occurs in a project that the person responsible can't resolve, it is escalated up the project or program management hierarchy until it reaches someone who can authorize a solution. Fixed Price

A form of contract pricing where a price is agreed in advance with the contractor for the delivery of specified works. Project managers like this form of pricing because it allows them to be in control of their project costs. Contractors dislike it because they risk making a loss if unforeseen circumstances mean that they have to do more work than they had expected; or if they had under-estimated the amount of work that would be needed to deliver in the first place. As a result, the prices quoted for fixed price contracts may be inflated to cover this risk. Gantt Chart

A Gantt Chart is a planning tool that helps project managers organize and schedule the tasks that need to be completed in a project. It can also help managers communicate this schedule. Gate

Many large projects are divided into stages such as investigation, development, testing, and release. There is a gate before each stage, and the project manager will decide when the project is ready to go through that gate, so that the next stage can be started. Milestone

Milestones are major points of achievement, or significant events in a larger project. They are usually monitored in a Project Milestone Report . PERT Chart

PERT charts are visually like Critical Path Analysis charts, but they attempt to estimate the time that each activity will take more accurately by using a formula to calculate the most likely activity duration based on the shortest and longest possible times as well as the expected time. Time estimation is a key issue in time management, and there's a tendency for people to under-estimate the time needed to complete an activity. Use of PERT helps people to take better time estimates. PMBOK

The Project Management Body of Knowledge (PMBOK) is an internationally-recognized standard for project management practice and information. It is published by the Project Management Institute, based in the US. Post Implementation Review (PIR)

A PIR is a review done a few months after a project goes live to assess whether or not it has delivered the business benefits its outputs were designed to deliver.

PRINCE2

Standing for PRojects IN Controlled Environments, PRINCE 2 is probably the most widely-used project management methodology. Originally developed for use with IT projects in the public sector in the UK, but is now used world-wide across a wide range of private sector industries as well. Program

A set of related projects. While projects are finite in duration, programs are often ongoing – for example, a new product development program. Program Manager

The person in charge of a program. Project Analyst

Someone who supports the Project Manager of a larger project by carrying out research, drafting documents, and tracking budgets and schedules. Project Charter

Project charters are drawn up early on in a project's lifecycle, and set out: the overall purpose and scope of the project; and the names of the sponsor, main stakeholders, and proposed project manager. They are often necessary during the first stages of gaining approval for the project. Project Dashboard

A project dashboard is a highly-visual report showing the progress of projects within a program. They are most useful when issued regularly – typically on a weekly basis, and are particularly useful to Program Managers and sponsors. Project Initiation Document (PID)

Drawn up early on in a project's lifecycle, the PID is a guide to a project, clearly laying out the justification for a project, what its objectives will be, and how the project will be organized. This helps ensure that everyone knows what's going on right from the outset. It is more detailed than a Project Charter, and will contain the detailed Project Business Case as well as an initial project plan. It is produced after the project has been approved. Project Manager

The person responsible for ensuring that a project is delivered to specification, on time, and on budget. Project managers have to coordinate the activities of a great many specialists. Project Mandate

The document that usually triggers a project. It is produced by senior managers. It usually refers to what the project needs to achieve and how it fits into the overall strategy. It usually identifies any key constraints and scope boundaries. It may also include an outline business case or alternatively the development of this initial business

case may be the first task required before the project is fully approved for implementation. Program Office/Project Office

In larger projects and programs, there is often a Program Office, staffed by a Program Office Manager, and possibly an administrator and even accountant as well. The program office function consolidates regular progress reports from the managers of individual projects for the Program Manager; maintains a central database of project documents; rolls out and enforces consistent document templates and formats; and carries out other centralized administrative tasks to support the project staff. Project Sponsor

The "champion" of a project, who wants the projects intended benefits delivered to improve the part of the organization for which he or she is responsible. RAG Status

RAG stands for Red-Amber-Green and describes the status of a project or a part of a project on a Project Dashboard . Risk Log

See CARDI Log. Scope

The extent of what the project is designed to do. This covers functionality, systems, interfaces, processes, departments and external stakeholders (such as suppliers and customers). As well as stating what is included in a project and its boundaries, it is sometimes helpful to specify certain things that are out of scope for the project as well. Projects which suffer from "scope creep " are highly likely to exceed their original schedule and budget. Slippage

This is the amount of time a project, or an activity within a project is behind schedule. Stakeholders

Stakeholders are the groups or individuals who have an interest in the outcome of the project, although the interest that each group has is usually specific to them. Typical stakeholders can include shareholders, customers, suppliers, alliance partners, and members of the project team. Stakeholder Management can be a very important part of a project manager's and project sponsor's job. Time and Materials Pricing

A form of pricing similar to Cost Plus Pricing where the work done is charged according to the amount of time spent on it and the cost of the materials used. Turnkey Projects

The name "turnkey" comes from the idea that the project sponsor can simply "turn a key" on an delivered project which then "switches on". Turnkey projects are often part of larger programs – for example, a

property developer might hand over the plumbing or the soft furnishing provision of a development to an external contractor. The developer would expect all aspects of the work to be fully functioning when the plumber's or furnisher's sub-project was complete. Work Breakdown Structure (WBS)

A Work Breakdown Structure splits large project tasks into more manageable pieces of work, or actions. These can then be allocated to teams or individuals using a Responsibility Assignment Matrix .

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... Dianna wrote Hi joe, are you referring to Mind Tools in general or in this article specifically? We have many resources that reference SWOT analysis both at the business level and for personal analysis. Let me know if you'd like a list of them. Cheers! Dianna February 13, 2012 joe0823 wrote Anyone know if S.W.O.T analysis is mentioned anywhere

February 13, 2012 Dianna wrote That's fabulous feedback - thanks unsecgen! There are lots more things to learn at the club and I look forward to hearing more from you. You can read articles and tools, participate in training sessions, and ask questions in the forums. We are here to help in any way we can. Let us know what you need. In the meantime enjoy your time spent here and I hope to "see" you around. Cheers! Dianna August 20, 2010 unsecgen wrote This piece really assited me in knowing the fundamentals of Project Management. I did a presentation and it did help me a great deal. I am priviledge to be a part of this group. Regards. WFG August 20, 2010 cobberas wrote Wow - what a terrific glossary for PM. I wish I'd had this when I did my 1-semester PM unit in my IT course!! Nonetheless useful now I'm amazed at the number of people who use the term "critical path" to mean the complete project schedule; I was starting to doubt my own understanding. Thanks Team. cos April 15, 2008

Return to top of the page

Work Breakdown Structures Mapping Out the Work Within a Project You know what your project has to deliver and you're clear about what its scope is. So now you need to do some planning. But where do you begin? Whether you project is big or small, one of the first challenges of project planning is to break the overall deliverable down into manageable chunks. Later, Break large pieces of work into chunks. you'll use this to work out the © iStockphoto/alexpacha schedule, identify the resources you'll need, and work out what the cost of it all is likely to be. One of the most popular ways of this is to use a "Work Breakdown Structure". This technique, developed by the United States Department of Defense and NASA in the 1950s and 60s, is often used by professional project managers, using formal project planning methodologies. But you'll also find it useful for smaller, less formal projects – and even if your job title isn't "Project Manager". These might include a running marketing campaign, managing an office move or even organizing a company "away day". A Work Breakdown Structure is a detailed list of all of the things that need to be delivered and the activities that need to be carried out to complete the project. As shown in Figure 1 below, it's represented as a tree-structure, with each deliverable or activity broken down into further components. Figure 1: Work Breakdown Structure Format

There are several different approaches you can use when constructing a Work Breakdown Structures:

• Process or activity-oriented – this involves breaking the project into the different activities it involves such as management, needs analysis, purchasing, testing, installation and training. • Achievement-oriented – this involves breaking down the overall project objective into achievements such as having fully trained users, and acceptance of a system against test plans. • Function or product-oriented – this involves breaking the project up according to the different parts of the final product e.g. hardware, software, data and service elements. Different approaches suit different circumstances. The achievementoriented approach is useful because it helps you to keep sight of how what you're doing contributes to the overall project deliverable. A function-oriented approach is useful where different people have different skills, and you need to organize work to take advantage of these different skill-sets. And a process-oriented approach allows you to break work down into conceptually simpler elements which can be approached one-by-one. Other approaches suit other situations, and some mix the approaches.

How to Use the Tool Use the following steps to analyze your project: 1. Choose which approach you want to use for your Work Breakdown Structure: process/activity; achievement; function/ product-oriented; a different approach; or a combination of approaches. 2. Break the project down according to this approach. And then break it down further so that the lowest level shows clearlydefined, achievable chunks of work. Try to create no more than 3 or 4 levels in total, with ideally no more than nine elements at each level. The final level of detail you go to will depend on the nature of the activities and the experience of the staff you will be assigning the activities too, but try to avoid going into too much detail while still ensuring that the Work Breakdown Structure is comprehensive. Your Work Breakdown Structure should certainly not be a list of one-hour jobs! Tip 1: How far to break down...

What you're trying to do here is break the project down into manageable elements so that you allocate resource and estimate time and cost. Within your Work Breakdown Structure, try to break work down to a level where you understand tasks reasonably well, and can estimate resources needed with a reasonable level of confidence. (If you're doing this as part of a large program, break work down as far as individual projects that you feel comfortable delegating.)

Tip 2: Beware exhaustion

As you're breaking work down, it's easy to lose concentration, meaning that you can miss important tasks, and skip over unknowns without noticing them. Make sure that you validate your breakdown with key stakeholders to make sure it's comprehensive. If you're using this tool with people who want to get on with other stuff, it's easy to rush this stage and tolerate chunks of activity that are too large or are too loosely defined. Be careful and be thorough, particularly if you're likely to be facing deadlines or working within tight budgets. Tip 3: Be careful of commitment

Use of Work Breakdown Structures is very much a "topdown" approach to identifying work. The thing most likely to cause you problems when using it are the "unknowns". These are tasks that you don't fully understand, and which could be quite simple, but could also be complex, expensive and time-consuming. If there are significant unknowns, mark them as such, and make sure you schedule early work to investigate them and clear them up. And make sure that you communicate these unknowns as risks to the clients of your project. 3. If your project is reasonably large or complex, number each element or activity using a hierarchical numbering system as shown in Figure 2 below. This allows everyone to be completely clear about which activity or milestone is being referred to in project reports.

Figure 2: Part of an Example Work Breakdown Structure

Tip 4:

If you are working with a team on this exercise, you may find it simplest to work with sticky notes on a large sheet of paper, and only transfer your WBS to a computer later.

Key Points Good planning is a requirement for any successful project. And creating a Work Breakdown Structure during the planning phase is a good way of identifying the tasks that need to be completed. Creating a Work Breakdown Structure is just one part of the wider activity of planning. More detail about planning can be found in Mind Tools Project Planning section and in our Bite-Sized Training session on Planning Small Projects .

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience

What members say... dtrainor wrote I agree that mind maps are extremely useful, particularly when I'm trying to find the scope or bounds of a complex problem. They definitely appeal to the visual thinker! I hadn't thought of them in the context of a WBS before but I could see how that way of thinking might help. Thanks for the advice. Regards, David May 23, 2011 Dianna wrote Hi Johann, Aren't Mind Maps one of the best tools around? I find they help me get my head around so many issues and can be applied to so many things. Using them in conjunction with a WBS makes total sense!! Here is our article on mind maps for anyone who isn't familiar with the technique or needs a brush-up: http://mindtools.com/community/pages/article/newISS_01.php Please do share any other tips like this Johann! Dianna May 18, 2011 jhnshe wrote I used WBS in card- / paper-form in the past;

later I used the "Mind Map" technic to develop a WBS using a computer and find it very useful. May 18, 2011 Rachel wrote I'm a fan of the work breakdown structure principle, and personally, I use it for projects whether they are big or small. There was some debate with some of my colleagues about whether project planning can really be a top down activity. My take on this is - yes, plan top down, as it keeps you focused on what you're trying to achieve. By all means validate bottom up (it's intuitive to want to do so), but make sure your additions are still focused on the goals and big deliverables. R November 5, 2006 Jara wrote Thank goodness I'm not the only one who is a bit clueless about the many acronyms used for these types of tools (among other things)! I do feel a bit inadequate at times but I just smile and nod and pretend I know what is being talked about because I don't want to appear stupid. It's not the first time, and it certianly won't be the last but at least I know what WBS stands for now. Thanks Fidget for making me feel a bit more normal!!!:shock: Jara November 4, 2006 Fidget wrote This is really handy. While I'm not directly involved in projects at work, I work with people who are, and they're always bandying around 3-letter acronyms like WBS. This is a really helpful explanation for people like me, so next time someone mentions one, I won't look clueless, but will nod knowledgeably! Have a good weekend, now! November 3, 2006

Return to top of the page

Working With Project Sponsors No project will ever get off the ground without a sponsor. He or she is the person who has identified the need for change in an area of the business, and is committed to making that change happen. The project sponsor is the person who proposes the project, and who procures the resources – the people, the money, and the time.

A project's sponsor is the 'client' who wants it delivered. © iStockphoto/melhi

The sponsor has the authority and influence within the organization to champion the project, and ensure it has all the support it needs to succeed. In other words, the project sponsor is the internal 'client' to whom the project manager has to deliver the project on spec, on budget, and on time. The project manager/project sponsor relationship is, therefore, extremely important to a project's success. If you're a project manager, then understanding exactly what a project sponsor does is critical to managing this relationship effectively and proactively.

The Role of a Project Sponsor First and foremost, a sponsor must have the authority and commitment to ensure a project's success. While a project manager's influence is often limited to the project team, the sponsor is the one who leads and directs the overall business environment related to the project. Therefore, the sponsor is responsible for making sure the organization understands the value of the project, and is ready to receive and implement the project's deliverables, The project sponsor usually holds a senior position within the business function that will ultimately support the project. This way, the sponsor has significant input into the project, and is highly committed to the results. Some of the key project sponsor responsibilities are as follows: • Aligning the project with organizational objectives – Promoting the project, monitoring the political environment, and making changes as necessary. • Appointing the project manager (PM) – Ensuring that the PM understands his or her role and responsibilities. • Approving the project plan – This includes the project scope, schedule, budget, and objectives. • Holding the PM accountable for keeping the project on track – Meeting regularly with the PM, and holding the PM accountable for key deliverables according to the project plan.

• Supporting the PM – Being available for consultations and meetings, and helping the PM avoid and reduce the impact of obstacles. • Providing funding – Obtaining the necessary financial resources, or liaising with the person or group that authorizes funding (for example, the company owner, board of directors, external funding sources). Ensuring that project assets are used properly (this financial obligation is often the basis for all of the other responsibilities of a project sponsor). • Helping the PM obtain other necessary resources – This includes managing cross-functional relationships, and protecting promised resources, so they don't get reassigned elsewhere. • Actively promoting the project – Communicating the benefits and importance of the project. • Mentoring and supporting the PM – Empowering and motivating the PM, building the PM's confidence and leadership skills, and dealing with issues that the PM can't resolve. • Approving major changes – This includes supporting the need for additional resources, and otherwise changing key parts of the project plan when necessary. • Monitoring and reviewing progress – Providing the PM with strategic direction, validating project phases, and signing off on deliverables. • Celebrating the project's success – Recognizing the team's effort, supporting implementation as needed, and contributing to the final review process, including the Post-Implementation Review . In summary, the project sponsor is an executive-level champion who ensures that the project gets what it needs, and delivers what it should. Clearly, project sponsorship is an active position that involves a continuous commitment throughout the life of the project. Large projects often have a steering committee, which is typically headed by the project sponsor. This committee has final budget approval, makes decisions about scope and objective changes, and is the highest authority for resolving issues and disputes.

Characteristics of a Great Project Sponsor To fill this critical role, a person needs to be passionate about the project, and able to communicate that passion effectively. Here are some of the key requirements for an effective project sponsor: • Having sufficient influence within the organization to champion a cause. • Understanding the organization's strategy, and how the project's objectives help to deliver it. • Having the authority to make final decisions. • Have a vested interest in the project outcome. • Understanding the project objectives.

• Being able to solve problems involving different stakeholders and competing needs. • Having enough time to dedicate to project meetings and responsibilities. • Communicating effectively with all levels of the organization. If you're asked to be a project sponsor, or if you're looking for the right sponsor, you should be aware of these qualities. However, if you're a project manager, and you need to work closely with the sponsor, you can do certain things to take charge of the relationship, and help ensure the project's success. We'll discuss some of these next.

Working Effectively With Project Sponsors Having the right sponsor is only half the battle. The project sponsor and project manager must work well together. They may already have a working relationship, because they often work in the same office and for the same company. Sometimes, however, the project sponsor and project manager come from different organizations. Knowing how to make this important relationship work is key to the project's success. Here are some tips for project managers to improve the way they collaborate with their project sponsors: • Discuss project expectations right from the start – Make sure you're both clear about the objectives and the project specifics. • Take responsibility for the quality of the relationship – Set the tone for the relationship, and for the type of communication you'll use. • Find out how much the sponsor knows – Determine how much information the sponsor has about project details, and be prepared to provide any missing information. • Agree on the sponsor's role and responsibilities – Discuss issues like these: • How does the sponsor want the PM to report progress? • How will progress be reported to senior management? • What kind of issues does the sponsor want to be involved in? • Which deliverables will the sponsor approve? • How will the sponsor be involved in requested changes? • What is the best time and means of communication? • Introduce the sponsor to the project team – Give the sponsor an opportunity to provide an executive-level perspective on the project and its expected outcomes. • Meet regularly and communicate openly – Have ongoing discussions on matters of importance, and continue to build your relationship. • Respect the sponsor's time – Carefully prepare for meetings, and summarize information as much as possible. Make it as easy as possible for the sponsor to get the information needed.

• Be open and honest with the sponsor – Address problems and delays in a timely manner, and give the sponsor enough time to deal with issues that need to be resolved. The more trust you develop, the better the project outcomes will be. Project managers typically focus on one project, whereas a sponsor may oversee several projects at the same time. Take this into consideration, and make the communication process as simple and straightforward as possible. An effective project manager acts as a guide, and makes it easier for the sponsor, who has ultimate accountability for the final result.

Key Points The project sponsor's influence, commitment, and effectiveness directly impact a project's success. Project sponsorship, however, requires certain skills as well as active participation. Throughout the project, there are tasks to be completed, actions to be taken, and decisions to be made. Sponsors are ultimately responsible for initiating the project, and for supporting the achievement of its outcomes. They have a governance role – ensuring that the project is completed according to its plan, scope, schedule, and budget. Project sponsors and project managers can do many things to improve project outcomes. It's a partnership of shared responsibility: the project manager focuses on specific deliverables, and the project sponsor focuses on overall outcomes. This relationship is a top priority, and it can be managed from both sides for maximum effectiveness.

Click to vote no

Did you find this article helpful? No

Click to vote yes

Yes

Where to go from here:

Next article

View print friendly versio

Ask questions, or share your experience Return to top of the page