Eight Arguments for a More Flexible Project Management Approach

 

Wednesday, before the Thanksgiving Holiday, I was reading Elizabeth Harrin's blog post, The 8 Dangers of Implementing Agile. Elizabeth cites the reasons Keith Richards thinks Agile is a bad idea and I found myself disagreeing with every point. Although I don't want to talk about Agile specifically, I think we generally need to take a more flexible approach to project management. Without getting bogged down in the specifics of any particular dogma, I had the biggest disagreement with Richards' arguments in relation to any project management methodology that was different from a top-down, command-and-control approach in favor of a more flexible approach.

I believe what he identifies as big negatives for implementing Agile methodologies are actually wonderful reasons to implement a more flexible approach to managing projects:

1. It arrives bottom up: "This bottom up stuff is a bit dangerous," says Richards. I couldn't disagree more. The people closest to the work understand it the best. Who better to provide input into processes than those who work with it every day? I don't think that a successful methodology that grows throughout the organization is necessarily a bad thing.
2. It looks simple: "If it was simple we wouldn't need to be trained up in PRINCE2," says Richards. Whether it's PRINCE2, the PMP, Certified SCRUM Master, or any other certification, if the only argument to making the process complicated is so that those certifications have meaning, then the certifications have lost all meaning. I think Einstein said, "Any intelligent fool can make things bigger and more complex... It takes a touch of genius—and a lot of courage to move in the opposite direction." We should not be afraid of simplicity. In fact, I've found that the simplest solution for any situation is often the best.
3. It's mixing oil with water: According to Richards, Agile has a particular approach to governance that doesn't sit well with some heavy corporate governance structures. Although that is probably true, not every project-based organization has a heavy corporate governance structure. I agree that there are times when a hard-core waterfall approach to managing projects is appropriate. However, that doesn't mean that every project should be managed that way; and what's more, I believe there is a problem with a one-size-fits-all approach to managing all projects. As project managers, I wonder if it's time for us to step away from a rigid adherence to any particular dogma and embrace the simplest solution to solving the particular needs of every project. We should be thinking in terms of project value, not a dogmatic faith in any particular method.
4. You start with timeboxing: I look at timeboxing as a simple way to actually do some real resource planning. I also think that most projects would benefit from taking projects and putting them into smaller, achievable chunks. I'm a firm believer in demonstrating value regularly and often. If timeboxing does that, I see it as a benefit. Richards suggests an education campaign and really understanding what you are setting out to do. I agree 100 percent with defining objectives and really understanding what you are setting out to do, however, making the determination that projects will be within a certain timebox, doesn't stop you from doing so.
5. Teams self-manage: "Who's going to pull things together?" Keith asks. A command-and-control management style is not an effective way to manage anyone. It hasn't been for the 30 plus years I've been in the workforce, and it is even less so now. That doesn't mean that there isn't a single point of contact. Whether you are a scrumaster or project manager, your role is to facilitate collaboration, remove impediments, and lead the team. We should focus more on being a project leader, rather than a drill sergeant.
6. It grows virally: "Don't let Agile spread virally," Keith warned. I wonder if the fear of a lack of control is really the issue here. The viral spread of Agile, it could be argued, is an indication that in many circumstances, it must be working. Of course that doesn't imply that caution should be thrown to the wind or that a willy-nilly approach to how we manage projects is appropriate. However, as project leaders, we should be thinking in terms of what methods will work the best for the team to help facilitate a productive project environment. Viral isn't necessarily bad.
7. The people upstairs don't get it: Elizabeth suggests that this is a danger for any methodology, and she is right. That being said, at the end of the day if your project management approach is delivering value, a positive ROI, and successful projects, does it really matter if the people upstairs get it? They aren't working on the project team. They want projects to demonstrate value and return. Don't believe me? Try going through a Gantt chart and resource grid with the executive team and time how long it is before they are fumbling with their iPhones, looking at emails, or worse—have you excused from the meeting.
8. The tools drive the transition: I agree that tools should support any new process, not the other way around. I also agree with Elizabeth when she points out that this is a potential problem for any project management methodology.

I guess the long and short of it all is that Mr. Richards' arguments appear to be a throwback to a command-and-control philosophy that doesn't fit with the needs of today's organizations or the way project teams work. There is a place for Agile and more traditional project management approaches. Which approach you use and when should be determined by the needs of the project and not by the bias of the project manager.

Have I missed the boat?