Succeeding with Change

 

After my last post, I had a "doh" moment regarding free PDUs.  I could be mistaken, but I'm pretty sure that PMI members have access to free 1 PDU webinars here on ProjectManagement.com.  Okay, so it's not exactly free if you have to pay to be a member of PMI, but if you're already a member, why not take advantage of the resources available to you?

I had an "aha" moment, earlier this week, while contemplating why some companies succeed at certain project management methodologies, while others don't. The answer started to form while reading Kevin Coleman's article, "The Best of Both Worlds."  In his article, he discusses two different teams who had to work together, one using waterfall and the other agile, and how both were very resistant to the other.  He concluded that the main reason for resistance was due to both being unfamiliar with the other's approach to projects, and seeing little value in it.

I had to think about this for a little bit, and I realized that Kevin was right.  One of the main reasons that companies succeed with agile, after struggling with waterfall, is training.  When a company adopts agile, both IT and the business (should) receive training on how the process works and how to do what is expected of them.  When was the last time one of your business sponsors or stakeholders was trained on their role and how to interact with the project team on a waterfall project?  (I see a conversation with my PMO Director in the near future…)  It rarely happens.  We (including me) often make the assumption that people know how to be part of a project, even though we know it involves more than just identifying tasks and getting work done.

Sure, you might create and distribute communication plans, document roles and responsibilities, conduct stakeholder analysis, and publish RACI charts, but experience demonstrates that these artifacts do not adequately train your business partners on how to effectively participate in a project.  It's more likely that they have their own expectations regarding how the project should be run, and you are not meeting them.

I gained additional insight into the success of agile at some companies during the PMI luncheon on Thursday.  Julie Jacob, Director of Agile Implementation with AgileDad, spoke on her experiences transitioning the mortgage company, where she worked, to agile practices.

As I listened to her speak about inefficient processes, knowledge hoarding, and people focusing on increasing their personal value at the expense of others, it was obvious that change was needed.  The approach they chose was agile, and it worked, but it wasn't the only approach they could have chosen.  They could have addressed their problems individually, but without an overall vision, they would have only solved individual problems and not seen as great an impact.  Agile provided the wrapper that they needed to give context to the solutions they needed to implement.

Just to add a little reality to the conversation, I need to point out that transitioning to agile won't solve all of your problems.  The thing to keep in mind, in Julie's case, is that they made successful organizational change.  Transitioning to  agile is just one form of organizational change.  When you tackle organizational change, problems with your processes and (possibly) people will make themselves known.  If you don't deal with them effectively, they may sabotage the change(s) you are trying to make.  Agile or otherwise, effectively managing change is one of the key elements needed for any endeavor to be successful.

One last thought.  I've started reading "The Agility Shift" by Pamela Myer.  I may write more about it in a future post.  One topic that it has sparked that I will likely post about next week is the role of uncertainty in project management.