The Enlightened Project Manager

I just finished teaching a 3 day class on agile project management to a group if PMs in Cairo, Egypt. The class was one of the outcomes of an agreement signed between the Egyptian Government and the PMI IT & Telecom SIG last year. I’m approaching 10 years of volunteer service with the SIG.

One of the points we spent a lot of time discussing is when to apply agile. I spent some time talking about the sweet spot for agile…projects that don’t have clear requirements, are not huge, have strong user involvement, and have higher risk. New technology projects are good examples.

The idea of the Enlightened PM is one that knows the right tool to use for the project they have in front of them. While there are some that would disagree, I don’t think agile is the right approach to every project. I still think there’s a place for waterfall. I also know there are projects that will work well using more radical approaches such as Kanban.

One of the discussions revolved around an SAP implementation. Our conclusion was that you could do the initial implementation of SAP using their ASAP methodology (disclosure: I helped SAP develop the project management practices that go with ASAP). However, when you start working on enhancements, you can use agile, or even Kanban to manage those changes.

One of the participants in my class was in the construction industry. While I wouldn’t recommend agile for building a house, it can be used for designing a house.

Occam's Razor

I'm reading the book Plato and a Platypus Walk Into a Bar. As I was reading last night, I came across a reference to Occam's Razor. I liked their interpretation; "Theories should not be any more complex than necessary." Ockham was a 14th century Franciscan Friar and logician, razor refers to shaving away unnecessary assumptions.

I was putting some slides together this week for a workshop I'm conducting next week on Agile. One slide is an overview of Extreme Programming (XP). I'm not going to claim to be an expert on XP, but I have run projects following principles of XP. One of those principles is to use as simple of a design as you can and don't design for features you may not ever develop.

Are you making things more complicated than you need to? I was talking with one of my clients today on keeping things simple...get a basic release of the software completed and in the hands of your users and once they have a chance to use it, they'll have a much better idea of what else they need. Don't try to deliver everything at once. Or as my Dad used to say - KISS - keep it simple stupid!

Are you in debt?

I read an interesting article by a colleague of mine, Scott Francis, on technical debt in BPM projects (read it here). His article got me thinking about technical debt introduced through our project management practices.

Here's an example of what I'm talking about. Let's say you're working on capturing your user stories. You've gathered a group together and had a workshop set up for the afternoon to capture as many stories as possible. Tomorrow you plan on working with your product owner to prioritize the stories. During the afternoon session, someone mentions another user that isn't present that may have some user stories to contribute.

So here's where you decide if you're going to take on some debt. You could delay your prioritization meeting and go talk to this person tomorrow or you could decide to move forward according to your plan. If you move forward, you've just accumulated the debt of having other user stories added somewhere down the road that you will have to deal with.

Now you might be thinking this is agile, change is no problem. But do you know how big that debt is? It might be something insignificant or it might require some major refactoring in order to accommodate the new story.

That's the thing about technical debt. You're making a decision now in order to move things along that will have some consequence later. Do you know how big that consequence is going to be? Just like when you're taking out a mortgage on a new house, you want to make sure you know what you're getting yourself into.

Proof that Agile Works

I came across a very interesting article yesterday from Cutter Consortium (read it here). The article provided evidence about how offshoring doesn't really save you any money, but it also showed how agile does save you money.

The conclusions were based on 20 years of research across 8000 projects. It compared projects of similar size in terms of lines of code. The average project cost $3.5 million. Offshoring it reduced the cost to $3.2 million. The agile project cost $2.2 million.

From a time perspective, the on shore project took 12.6 months, 9.6 for the offshore, and 7.8 months for the agile project.

From a quality perspective, the onshore project had on average 2702 defects, an astounding 7565 defects for the offshore, and only 1372 for the agile project. So even though the offshore project cost less, you made up for it in fixing defects.

This was a pretty comprehensive study and the conclusions are pretty clear. I have been involved with offshore work, and to me that large physical gap between the user and the developer proved very challenging. Organizations I saw struggled to communicate requirements across the gap. I've always been a strong believer in close interaction between developers and users.

Not Waiting for Great

Wired Magazine had an interesting article in the September issue titled The Good Enough Revolution. The article discussed how people are no longer demanding the best, but things that are good, portable, cheap options. Music was one example they used; most people prefer the low quality of MP3s over the higher quality a record can deliver because MP3s are more portable.

This is actually a theme I try to push with my clients. We could spend 9 months building an application with all the bells and whistles or 3 months delivering just the important stuff. It's much cheaper, and if you deliver faster, you realize the benefits sooner. I'll admit I don't have a 100% success rate at getting clients to see my perspective, but I'll keep trying.

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