Skip to main content

Tag: Change Management

Leadership Lessons – Change in Seven Questions

What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate! 

How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water, and we start all over again.

Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.

This isn’t exactly news. We sort of get this. Ask any audience to tell you the secret to good Change and they will repeat back “Communicate, Communicate, and Communicate some more!” as if it was forcefully injected into their cerebellum. The problem arises when the questioning becomes a bit more detailed, “What exactly should we communicate?”

The response to that question is usually either a blank stare or the reasonable recitation of the reporter’s standby; Who, What, Where, When, How and Why. Not a bad start. If you’re writing a news article, then these are good solid questions. The Change Management problem requires all of those, and a few others besides. It’s not that the reporter’s questions are a poor tool; it’s just that they don’t address the peculiar psychology of the Change challenge.

For what it’s worth, here’s a carefully selected list of questions specific to Change Management. If we take the time to answer these, then we’ve covered the bulk of the key concerns of those facing the Change we’re contemplating.

1) Why?

This is the winner, the key question; it’s almost the only question worth discussing. If someone asks me to move from one side of the room to the other, or to stop using system ‘X’ instead of system ‘Y’, my response is always the same. “Why?” Understanding why a Change is necessary is the most important question we have about any Change. Without a good answer, we’re reluctant to do anything different.

There are lots of good answers to the “Why?” question. One good one is “Trust”. If I trust you and you ask me to do something, my trust in you might be sufficient to prompt me to Change. If that trust doesn’t exist? Then the reason for Change had better convince me, or I’m not moving from where I am.

2) WIIFM (What’s in it for me?)

The fly in the ointment for many organizations, “It’s not about you!” they cry as they bend over backward to avoid answering this question. Here’s the newsflash, as long as they are concerned about the WIIFM question, they don’t pay attention to any other information. More precisely, until that WIIFM question is answered, they can’t pay attention to anything else.

The best way to think of the WIIFM question is as a nasty, vicious guard dog, blocking the gate to our attention. Until that dog is thrown a bone, no information about the Change, sometimes not even the answers to the “Why?” question, is getting through to our reasoning process.

Even if we honestly have no information about the WIIFM question we must still acknowledge that the question exists and that as soon as we do have more information, we’ll get back to the audience.

3) Monday?

Assume, for the moment, we have returned from our strategic planning weekend with a wondrous, phenomenal vision of the future of our organization. Also assume, for the moment, that our ability to convince everyone that this is indeed the direction in which our organization should move, is up to the task. Assume that we’re silver tongued devils and get everyone on board, on the bus, bought in and generally all fired up. With me so far?

Now they have a question. What do we do differently, specifically and precisely on Monday (or next Friday…or next month… ) to start moving us towards the promised land of milk and ever flowing honey?

It’s a fair question. If we want people to Change, we must describe what they’re going to do differently in terms that everyone can understand. If we can’t, then we go back to the drawing board, our vision is flawed and unattainable.

4) Won’t?

What won’t Change? What will remain the same during this Change?

The problem here is that when we face a Change, all we see are the unknowns, we lose sight of the fact that only one ‘small’ part of our status quo is going to flux. That the rest of our surroundings will likely remain the same.

For example? When the accounting system is going to Change, we’re still going to report to the same boss, earn the same paycheque, receive the same benefits etc. In fact, most of our status quo will remain the same. This works for nearly all Change, the only time everything Changes is when we die, and then? It’s not our problem anymore. In nearly all other cases regardless of the size of the Change, nearly everything else remains the same.

5) Might?

What might go wrong during this Change? And what contingency plans have we put in place to mitigate those risks?

The worst thing we can do when heading into the uncertainty of Change is to insist that nothing can go wrong. That’s not only asking for the Gods to pay attention to us, but it also communicates to those around us that we haven’t really thought this through. Although if we’re looking for a sure-fire way to lose the trust of those who follow us, insisting, “Nothing will go wrong” is a wonderfully effective strategy.

6) Will?

What’s going to hurt?

Change hurts. That’s almost the ‘First Law of Change’. If we’re doing something significantly different, then we’re going to be at the bottom of the learning curve. Even if we pay close attention to training and support and fall back positions, we’re going to make mistakes, production will decline, and we’ll get things wrong. If we pretend that the Change will be painless, that it will be “transparent to the user”, then people will know we’re lying, or at least overly optimistic. 

7) Signposts?

Change doesn’t always happen quickly, sometimes it’s slow, almost glacial in nature – we need some way of measuring our progress towards a goal. Without feedback we lose both the motivation and the will to make sacrifices to move forward. The question on the table is, “How do we know we’re succeeding in our efforts?”

These aren’t the only questions we need to answer during a Change, but they’re crucial ones and if the answers aren’t forthcoming, neither will the Change. Stick them on the wall in front of you when crafting a Change message and ask, “Am I answering these? If not? Why Not?”

© 2015 Peter de Jager – Reprinted with Permission. 

Agile Doesn’t Mean Accept All Change!

bondale march4

With few exceptions, gone are the days when a team would plan a business project to a low level of detail, secure approval from their customer on scope, schedule and cost baselines, and then not have to be concerned about anything changing over the project’s lifetime.

The greater the level of requirements uncertainty or the more dynamic the enterprise environmental factors and competitive pressures are, the greater the likelihood of change.

On a traditional project, two common alternatives are practiced.

If short-term profit motives, fixed timelines or limited budget are the priority, then applying strict project change control practices ensures that change is managed, but likely at the cost of customer good-will. Taken to the extreme, administrative and analytical efforts spent on analyzing multiple change requests might actually prevent the team from delivering scope in a timely or cost-effective fashion.

If customer satisfaction trumps everything else, then scope creep might be encouraged and the delivery organization absorbs the costs of the additional work. However, the clock keeps ticking and even if the customer is not out-of-pocket as a result of these changes, their time-to-market objectives may not be met.

Agile projects are supposed to address this challenge. Rather than considering change as an evil interloper to be shunned at all costs, it is welcomed as an expected guest that will ensure the project team delivers the right scope to achieve expected business outcomes.
But does this mean that there should be NO change control on agile projects? Unfortunately, this is one of the pervasive myths of agile. Agile doesn’t imply throwing out tried and tested practices but rather encourages the use of the right tool for the right job in the right manner.

Without some level of change control, two scope management issues could emerge.

  1. Fundamental architectural elements are expected to be designed, implemented, refactored and stabilized in early iterations. However, if new work items get added by the project owner which imply significant changes to the implemented architecture, these changes might negatively impact deliverables which have already been transitioned to an operational state. This will result in a lot of re-work. The implications of this re-work could cause the team to be unable to meet a customer’s minimally acceptable product needs within their approved cost and schedule constraints. Additionally, team members might experience a drop in morale and productivity as they’d witness that a significant portion of their previous work effort had been wasted.
  2. The project owner takes the team on a work item walkabout. Instead of scope getting refined and distilled through progressive iterations, the project owner continues to introduce new critical requirements in each iteration which appear to have very little to do with those identified before. The team completes work items at a good velocity, but the backlog never seems to shrink and once again, the likelihood of the team delivering a minimally acceptable product on time and on budget is reduced.

Do either of these scenarios mean that the project manager should turn a blind eye to what is going on or should whip out their handy PCR template and enact strict change control?
They could, but that would be a regression to traditional methods of dealing with change.
A different approach might be to have a discussion with the project owner at the end of the current iteration as part of the planning for the next iteration. The project manager should provide the project owner with a facts-based revised iteration plan and request a decision on how to proceed.

Faced with this information, a project owner usually has the following three choices.

  1. If the underlying rationale supporting the business case is no longer sufficiently compelling to justify further investment, and the significant shifts in scope actually are signs that a new project should be justified and initiated, it might make sense to stop the project.
  2. If the project owner is willing to fund additional iterations beyond the current plan then they can provide team members with a better understanding as to why the significant shifts in scope are occurring and the team can continue their work with renewed vigor.
  3. If additional iterations cannot be funded or if a minimally acceptable product has to be delivered by the end of the current iteration plan, then the project owner will need to reprioritize the backlog with support from the team to fit within the current iteration plan.

On well-managed agile projects, change does not get suppressed, nor does it get free rein. It is appropriately managed to deliver business value in a time and cost effective manner.

Agile Transformation Through Effective Change Management Part-2

Last month’s article presented ways in which the first four stages of Dr. Kotter’s eight-stage change process model can be applied when attempting to institutionalize agile approaches, and this sequel covers the remaining steps.

If you’ve used some of the tips I had provided in the previous article, you should have key stakeholders embracing the immediate need for this transformation and have a well-defined end state vision. In addition, you’ll have defined a strategic plan to achieve that vision, and have effectively and frequently communicated the rationale for moving to agile methods and what the end state will look like.

So what’s next?

Empowering broad-based action

It does no good to train staff and then expect them to start managing projects in an agile manner if there are impediments in place which would prevent this.

Performance measurement systems are one example of this. If the objectives and measures defined for project team members are still based on silo-based role accountabilities which incent them to only focus on their area of specialization you are unlikely to get their full engagement in becoming generalizing specialists who are expected to put team success ahead of individual success.

Another example is over-prescriptive governance practices. While properly implemented agile approaches are more disciplined than most standard methodologies, teams are encouraged to utilize and adapt those working patterns which are best suited to their being able to maintain good velocity and high quality. If they are constrained with regards to how they complete work items, this is likely to be a source of reduced productivity.

It is important to do a holistic identification of what organizational, policy, process or cultural blockers might exist which would prevent successful agile adoption and to develop a plan to overcome these.

Generating short-term wins

It’s surprising how often agile implementations are attempted on multiple fronts with projects that might not be the best fit even in highly mature agile organizations.

Agile transformations, like any other process improvement initiative, aren’t free and the return on investment is likely to take a year or two. To avoid flagging interest and funding support, it is important to achieve some quick wins.

Part of the planning for the transformation needs to include the identification of a handful of projects which would be the focus of the initial implementation. Only one or two of these projects should be active at a time to enable the transformation team to closely monitor and learn from those project teams’ experiences.

Consolidating gains and producing more change

While it is important to focus on achieving quick wins with a few small projects, it is a mistake to declare victory too early as it is easy for staff to devolve from being agile to doing agile.

To avoid backsliding, the roadmap of agile projects should include progressively larger or more complex initiatives to help overcome doubts that the approach is only suited to small or low complexity projects.

As there are likely organizational blockers which will take a while to overcome, there needs to be continued, incremental effort towards resolving those.

It is also critical to recognize and promote those who are actively supporting the end state vision – often times, the team members on the first one or two agile projects make the best change advocates within their respective functional areas, and they should be provided the tools and encouragement to help with dissemination and sustainment of the behavioral changes.

It is also important to recognize that not everyone will be thrilled with the changes and while every attempt should be made to coach them to overcome their doubts and fears, they should also be monitored closely to ensure they are not sabotaging change efforts.

Hiring approaches should be reviewed to ensure that candidates are evaluated based on their fit with the developing culture and the desired end state.

Anchoring new approaches in the culture

The final step requires that the principles are firmly embedded in the culture of the organization such that leadership succession or other changes such as the acquisition or integration of other companies doesn’t result in the agile investment being marginalized over time.

To achieve this, it requires an undeniable track record – multiple projects of different levels of complexity need to have been successfully delivered using agile methods. It also requires ongoing reinforcement at all levels of the right kinds of behaviors. Finally, continued emphasis on hiring the right people, especially those in leadership positions will be crucial to sustaining the change.

Dr. Kotter’s quotation from Leading Change perfectly summarizes the effort required to successfully institutionalize agile delivery approaches. “…if shared values are the product of many years of experience in a firm, years of a different kind of experience are often needed to create any change. And that is why cultural change comes at the end of a transformation, not the beginning.”

Don’t forget to leave your comments below.

From the Sponsor’s Desk – The Importance of Principles

Davidson Jan28
In my last post, Guiding Community Change, we looked at how a community based initiative went from being a source of distrust and discord to a shining example of collective and collaborative community action. That fundamental change in direction delivered a community asset that will be enjoyed by present and future generations for years to come.

This post is a bit different. It’s not about a project or a major change. It’s a story about one man’s values and the lasting legacy he left through the actions he took over time. However, it does relate to project and change management in this sense, as Peter Drucker once so succinctly put it: “Culture eats change for breakfast”. Projects that fail to consider their relationships to an organization’s culture and core values are destined for trouble. Perhaps that’s a useful start for a new year.

Thanks to D.T. for the details on this story.

My friend, let’s call him Thom, was the owner of a retail franchise store for about thirty years. As a previous high school history teacher, he knew next to nothing about managing a retail operation so he had a huge learning curve to climb. And climb it he did, to the very summit. Even though he served a small market, his store was one of the most successful in the franchise. Thom was also an engaged leader in the community and a kick-starter and participant in many community initiatives.

How did Thom achieve his success? Certainly hard work and an ability to learn and adapt were fundamental. However, he had a strong set of values based on three principles:

  1. Do your very best to satisfy every customer’s needs
  2. Help, support, recognize and reward every employee fairly
  3. Be an active and valuable member of the community

He attributes his success to these principles and the values they helped instill in him, his company and his employees.

When my friend was telling me the story that follows, it occurred to me that he was doing business at the same time as Thomas Watson Jr. was running IBM. In 1962, Watson, IBM’s chairman, addressed an audience of future leaders at Columbia University. IBM had just turned 50, and he was invited to offer his thoughts on what half a century of corporate life had taught his company. He focused on IBM’s basic beliefs.

“I firmly believe that any organization, in order to survive and achieve success, must have a sound set of beliefs on which it premises all its policies and actions. Next, I believe that the most important single factor in corporate success is faithful adherence to those beliefs. And finally, I believe that if an organization is to meet the challenges of a changing world, it must be prepared to change everything about itself except those beliefs as it moves through corporate life.”

In 1963 Watson published “A Business and Its Beliefs: The Ideas that Helped Build IBM.” In it, he wrote that IBM’s philosophy could be contained in three beliefs: One, the most important, was respect for the individual employee; the second, a commitment to customer service; and third, achieving excellence.

Wow! Sounds a lot like Thom’s principles. Thom claims he and Thomas Watson never spoke. And now to the story.

Early in his retail management career, Thom had a six week store refurbishing project that required extra temporary staff working the night shift so as not to disrupt the normal daily operations. He advertised for temporary workers, had lots of candidates and began the interviewing process. One of the candidates was a young, unemployed man named Sam. He was short and slight and didn’t appear to be physically suited to the arduous physical effort required in the refurbishing project. He didn’t even have a high school diploma. But for some reason Thom liked him. He was well spoken, personable, very eager and asked a bunch of intelligent questions about the project so Thom offered him a spot on the team. Thom stressed this was a temporary, six week assignment only.

The project went smoothly. Thom monitored the performance of the temporary staff he had hired, recognizing them as a potential pool for future permanent positions. Sam’s performance stood out. He was always early to the job and late to leave. He did quality work. He worked well independently and with his teammates. He was great with his full time staff and the few customers he came into contact with. At the end of the project, Thom offered Sam a permanent position. When Thom retired, Sam was still working at the store and would work there until he too retired. He was never a manager but he was a model employee, worked hard and always pitched in to helped customers and peers.

Recently, Thom received a phone call from a former manager at his old store to say that Sam’s wife, Sheila, was dying from terminal cancer. Of course, Thom knew Sheila from the many company and community functions they attended over the years so he decided to give her a call and offer whatever support he could. When Thom called, Sam answered. They chatted for half an hour about their many shared experiences. They talked about Sheila’s illness and how Sam was doing. Finally, Sam put Sheila on the phone.

Thom and Sheila chatted for another twenty minutes or so about old times, her cancer and how Sam was doing. Then Sheila said “Thom, I want to thank you so much for giving Sam that initial opportunity and helping us experience the wonderful life we’ve had together. Because of your generosity and caring, Sam will have no financial worries after I’m gone. We’ve managed to save all the profit sharing cheques over the years. That will give Sam more than $1 million to fall back on.”

Thom was overwhelmed. He had always believed in profit sharing and had offered a profit sharing program from the first year of his ownership. He believed it was one of the reasons his staff were so productive and so loyal and his turnover so low. But a million dollars in savings? Sam had never had a big salary but the profit sharing proceeds could amount to 20% of salary annually. Sam and Sheila had been frugal with their funds.

When Thom ended the call, he was saddened but gladdened. Saddened by Sheila’s looming death, of course. But his heart soared with the realization that running his business and managing his relationships according to three principles formed and acted on so long ago had had such a positive and appreciated impact on a valued employee and his family. It was a fitting stamp of approval to a long and successful career.

The moral of the story for project managers and staff, change practitioners and stakeholders is perhaps best summed up by this quote from Gandhi:

“Your beliefs become your thoughts,
Your thoughts become your words,
Your words become your actions,
Your actions become your habits,
Your habits become your values,
Your values become your destiny.”

And remember, use Project Pre-Check’s three building blocks covering stakeholder, process and decision area best practices right up front so you don’t overlook these key success factors, including culture and core values.

Finally, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, don’t be shy! Send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

Don’t forget to leave your comments below.

Effective Change Management is Critical When Helping Organizations to Become Agile!

With ever new year comes well intentioned change resolutions so perhaps your company has agile transformation as a key resolution. While agile is no longer a fad, there continue to be organizations which struggle with transitioning from traditional project management approaches. This can unfortunately result in a “been there, done that, never again!” outcome.

I’m neither an agile fanatic nor a Luddite.

I’ve always encouraged using or adapting the most appropriate approach, practices and tools given the context of a project and the culture within the organization and team. Having witnessed the tangible benefits which can be realized when an organization effectively embraces agile approaches, I am an advocate who would like to see fewer failures.

Here are some ideas on how Dr. Kotter’s eight-stage change process can be used to institutionalize sustainable agile practices.

Establishing a Sense of Urgency

Are your leaders, mid-level managers, and team members satisfied with the speed at which business value is being realized from project investments using traditional approaches? If so, how will you overcome this complacency?

You could bring the outside in, by benchmarking your organization’s performance against the best-in-class within your industry. If it turns out that you are already on par with those, research the companies which are the most-likely disruptors in your market and gauge their delivery performance.

You could also create healthy tension by conducting impromptu interviews with business partners to learn if they are content with the speed or quality of current delivery and share their unfiltered, candid feedback with delivery areas.

Creating the Guiding Coalition

It isn’t sufficient to have one or two key executives support the transformation if there isn’t buy-in from business partners and the functional heads of other departments which contribute to project delivery. Eventually, your organization might eliminate the functional structures which have been in place for years to better support the existence of teams which persist from project to project but in the interim, if there isn’t support from key contributing functional managers, they will find a thousand ways to cripple your initiative.

Executives come and go so you need to have a coalition in place which can survive even if one or two of them take on new roles. Engage your key sponsor in identifying and engaging like-minded leaders – the focus should be on those stakeholders who have the greatest influence and visibility within their departments.

Developing a Vision and Strategy

How will stakeholders’ lives be better once the transformation is complete? What does better speed to market mean to them? How is being part of a self-managing team a good thing? Why would I as a business customer WANT to spend more time with project team members?

It does little good to communicate the expected benefits of the transition to agile if you haven’t developed a compelling vision to enable each person involved in the change to understand why it is not only important, but urgent and critical that they support it.

Vision without execution is hallucination.

This is where an agile transformation consultant can help – while they won’t possess the organizational awareness you have, but their experience can help steer you clear of those strategies which are unlikely to succeed. Your consultant has to be an agile pragmatist – while a purist approach may be achievable in the long term, your strategies will fail if they don’t incorporate the hard constraints (e.g. budget limitations or regulatory requirements) which exist within your organization.

Communicating the Change Vision

If you think you are over-communicating the benefits of agile and the need and urgency for change, you are probably still not communicating enough. It is not enough to hold a town hall meeting, present some flashy multimedia content and demand that managers and team members be agile. Staff have grown cynical with such superficial initiative launches and while you may get them cheering during the meeting, there is unlikely to be follow-through afterwards.

Search for opportunities in all interactions which the members of the guiding coalition have with their constituents to draw connections to the vision. Leaders will also need to watch their own behavior – if they are talking agile, but are slaves to process and bureaucracy, it undermines the impact of their messaging.

But this shouldn’t mean that they paint an artificial picture of how easy or quick the transition is going to be. They need to effectively communicate the necessary compromises and constraints which will prevent rapid transition to a purist agile model. By doing this, they will demonstrate that they possess the necessary pragmatism to gain credibility and buy-in from their staff.

The first four stages help to establish the foundation for the transformation, Next month we’ll cover the balance. Till then, remember to be agile and don’t just do agile!

Don’t forget to leave your comments below.