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.