Getting people to change

I've been encountering a pretty common situation with some of my clients. While they seem to get what agile is about intellectually, they are still doing things the old way, seemingly unable to break their old (bad) habits.

A colleague of mine, Donna Brighton of the Brighton Leadership Group, introduced me to a new model for change, the ADKAR model, developed by Prosci.

• Awareness
• Desire
• Knowledge
• Ability
• Reinforcement

So the first step is awareness. Are people aware of why they should adapt agile? Are there project failures in the organization? Do projects miss dates, fail to deliver on quality, or run over budget? How can agile solve these problems?

Next, do people have the desire to change? If they've come to accept the status quo, maybe there's no incentive to improve.

The third step is knowledge. This is where training would play a part, so people can understand the desired future state.

However, knowledge doesn't guarantee ability. Can people try the new approach without fear of punishment? Is there support in place to let them succeed?

Finally, when the desired behavior comes about, what is being done to make sure people don't fall back to their old habits?

I have always used the term Organizational Change Management (OCM) when I talk about this type of change, to distinguish it from technical change management such as scope change. I have always approached OCM from the organizational perspective; how do I get the organization to move in the new direction? What I haven't thought about much is that an organization is made of individuals, and each person will make this change journey at their own pace. My effort to change the organization must take individuals into consideration. I'll have my early adopters that can help me. I'll also have those late adopters that I have to account for. I can't assume everyone will change according to my OCM plan.

As for my clients, I think the awareness is there, so it's time to focus on the other steps to get them on the road to agility.

Afraid to Fail

I am reading the book The Art of Possibility and came across an interesting section about failure. There is a story about the composer Stravinsky. When questioned about one particularly difficult section of music, he replied that he didn't expect anyone to play it, but to sound like they were trying to play it. His purpose in writing the passage was to get someone to fail when they attempted it.

Throughout our life, we are told failure is bad. However, it's through failure that we can learn. Thomas Edison didn't think his earlier attempts to invent the light bulb as failures, just steps pointing him in the right direction. Abraham Lincoln had some political setbacks before eventually becoming President of the US.

So when is it ok to fail? If you're trying a new technology, running a pilot project is a good idea. That way, if it does fail, there isn't a lot invested, and you learn something from it. If you're trying to run a 4-hour marathon and come in a few minutes slower, it could be looked at as a failure, but you still accomplished something.

We need to set stretch goals for ourselves. If we don't accomplish these goals, we've still increased our abilities and learned from them. If we always sit in our comfort zone, we never grow.

A stretch goal for me over the past few years has been to develop as a public speaker. I still get nervous anytime I stand in front of a group, but now I am much more composed. There have been presentations I've done in the past that haven't gone as well as I would have liked. I've learned the importance of spending a lot of time practicing before any presentation, even if it's just a project kick-off meeting for a small project team. If I wasn't afraid to fail, I would have never gotten to this point.

So, are you willing to fail?

Photo Credit: Ian Lewis, licensed under Creative Commons

Projects to the Point Conference - Final Wrap-up

I'm home from Cairo. The P2P conference wrapped up on Thursday. I am already looking forward to the 3rd annual conference next year.

The agile track for the conference wrapped up with a panel discussion. In addition to myself, the panel included Jim Cundiff, Jesse Fewell, Dave Prior and Thushara Wijewardena (Dave and Jim pictured here during an earlier session). One of the topics we discussed was when to use agile.

I tend to look at agile as a tool, just like traditional project management tools, ITIL, Six Sigma etc. I think you have to look at your particular project and decide if this is a good project to apply the agile tool. If you're talking software development, chances are that the answer is going to be yes. I pointed out in construction, agile isn't the best approach. If you're building a bridge, you need to have all the requirements before you start construction. However, even here, you could use an agile approach to the design stage.

Dave Prior used the term "enlightened project manager" to describe someone that knows how to apply the right tool at the right time. So do you have all the tools you need in your toolkit?

Day 1 - Project to the Point

I am in Cairo and the first day of the Projects to the Point conference has just wrapped up. Today featured a number of keynote speakers, including the current and immediate past chairs of PMI (Ricardo Vargas and Philip Diab), as well as H.E. Dr Ahmed Darwish, Minister of State of Administrative Development for the Egyptian government.

The Arabian Gulf Chapter of PMI recently conducted a survey into project failure. The leading cause, based on their failure, was project managers without the proper training/experience to run projects. Mr. Diab cited the young workforce in the middle east region as a factor in being able to meet the project management demands.

One of my presentations tomorrow is on knowledge management (KM), very relevant based on today's comments. A part of KM is being able to implement coaching and mentoring to share tacit knowledge among project managers. Tacit knowledge is that stuff that isn't easy to communicate, like how to run a project successfully. It requires more time commitment for experienced project managers as they need to bring their protégées up to speed as a master craftsman trains an apprentice.