© iStockphoto
Browse by Category
Project Management Framework Scheduling Scope Management Building Support for Your ProjectsCommunication Change Management Project Improvement and Review
Further Resources
Bite-Sized Training™ Learning Streams Book Insights Expert InterviewsProject Management – Start Here!
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.
This section of Mind Tools teaches more than 50 individual project management skills. Start with ourquiz , which helps you assess your current skills levels. Then explore thekey areas of project management, learn how toschedule projects, and find out how to
manage changeso that your projects are accepted and embraced by the people they affect.
TheBrowse by Categorybox below will help you target specific project management skills areas, while you can look through thefull listof tools to find interesting topics. Enjoy using these tools!
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 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
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
Scheduling
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
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
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
Scope Management
The RACI Matrix
Structuring Accountabilities for Maximum Efficiency and Results
Influence Maps
Uncovering Where the Power Lies in Your Projects
Project Dashboards
Quickly Communicating Project Progress
Project Milestone Reporting
Keeping Projects on Track by Monitoring Significant Check Points
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
Communication
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
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
Project Improvement and Review
What Is Project Management?
Stakeholder Management
Managing Stakeholders
Scenario Training
Planning Small Projects
Winning Support for Your Project
Managing Change
Manage Change
Bite-Sized Training™
Learning Streams
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
Where to go from here:
Next articleInnovations in Office Design, with Diane Stegmeier
Opening Day: Your project's complete!
© iStockphoto/Ridofranz
Where to go from here:
Next articleView print friendly version
Project Management – Start Here!
Project Management is a well-established 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 examples of projects are 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 Bite-Sized Training sessionWhat Is... Project Management?
Simple projects can be completed with simple plans.
© iStockphoto/AndrewJohnson
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.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 fromTo-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 bybrainstorming 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 beprioritized 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 youdelegate 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 anAide Memoire . This is a checklist that you
progressively refine and improve to make sure that you remember to do everything important for success.
Did you find this article helpful?
Click to vote noManaging Bigger Projects
Action Plans are useful for small projects, where deadlines are not particularly important or strenuous, and where you don't need to co-ordinate 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 ToolsProject Managementsection to develop your project management skills. In particular, see our article on Gantt Charts , and take ourHow Good are Your Project
Management Skills test.
Our Bite-Sized Training session onPlanning Small Projects
also teaches some useful project planning techniques.
You can also use Action Plans in conjunction with yourTo-Do Lists , orAction 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. Pleaselet us knowif you know who the originator is.
No
Click to vote yes
Yes
Where to go from here:
Next articleView print friendly version
Ask questions, or share your experience
What members say...
Dianna wroteHi 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
Useful in business, as well as emergency situations.
© iStockphoto
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. That may help the next project – 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 theDeming Cycle, or Plan-Do-Check-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 avoidgroupthink , 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.
Did you find this article helpful?
Click to vote no NoClick to vote yes
Yes
Where to go from here:
Next articleView print friendly version
See our articles onrunning 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.
Ask questions, or share your experience
What members say...
Midgie wroteIn 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
Agile Project Management is about developing successful solutions in a fast-moving environment.
© iStockphoto/aluxum
Agile Project Management
Organizing Flexible Projects
Picture a start-up technologybusiness, 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!
They can only find out so much through market research, so 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 re-evaluating 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 theAgile 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,
Did you find this article helpful?
Click to vote no NoClick to vote yes
Yes
Where to go from here:
Next articleView print friendly version
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.
Ask questions, or share your experience
What members say...
SimonICT wroteJust 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.
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
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?
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 pre-sprint planning meeting a few days before the pre-sprint, a mid-pre-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
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
Can people see that the alternative would be better?
© iStockphoto/mikdam
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 long-established competitor 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
Did you find this article helpful?
Click to vote no NoClick to vote yes
Yes
Where to go from here:
Next articleView print friendly version
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.
What members say...
bigk wroteHi 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.
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
Getting the very most from your projects.
© iStockphoto
Benefits Management
Getting the Greatest Possible Benefit From a Project
Projects are the engines ofchange 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.
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 thecost-benefit analysis to include the benefits you've identified.
• Remember to look for tangible and intangible benefits. For a list of the types of benefits which stakeholders may be seeking, seeMiadanu's helpful poston 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 benefitsdashboard 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 onscope 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.
Did you find this article helpful?
Click to vote no NoClick to vote yes
Yes
Where to go from here:
Next articleView print friendly version
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.
Ask questions, or share your experience
What members say...
Dianna wroteHi 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
Help people make a smooth transition during change.
© iStockphoto/maigi
Bridges' Transition Model
Guiding People Through Change
People are often quiteuncomfortable 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.
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 youlisten 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.
