LeadingAgile: How to Talk to Project Managers

Last week, I had had the distinct pleasure, the rare opportunity, to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there were at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.

I was working the VersionOne booth, so while I had a full conference pass, I did not get to go to any of the talks... bummer.

Note: This post was written last week, so I am writing like I am there now. I decided to leave the language that way... hope it is not too distracting!

Talking to Project Managers

It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again, people are interested and want to know more.

After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being "in control".

I've found that a good place to start is with a discussion of the triple constraints.

Managing the Triple Constraints

Most traditional projects start with some assessment of scope; an assessment of what the stakeholders want to be built and what they are willing to invest money to have. From there the team does some analysis, figures out how big the request is, and what will be involved in building it. We do an assessment of the team, understand who is available (and when), and begin to lay our dependencies and calculate the critical path. From there we determine a date.

Ask your PM friend if that sounds much like their personal experience? They will inevitably nod 'yes' because that is what project managers are taught to do. Next ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

Sometimes, if management really does not care about successful delivery, they are just given the date, and the budget, and are made to deliver all the requirements anyway.

Our Real Project Drivers

This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

So, where do we go from here? I will typically explain that agile project management starts with time and cost as the primary constraints and introduces techniques that enable the business, in partnership with the team, to decide what is the best set of requirements to build. After delivering this line, be prepared for the blank stares.

But I Have to Deliver Everything

The blank stares are because project managers are trained that they have to deliver everything. The executives demand it and the stakeholders cannot take the product to market unless they have everything. Now it is time for more questions. Ask them if that approach ever works? The answer is always 'no'. Ask them what happens when projects start this way. They will answer that the project is always late or over budget.

The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

As a quick aside this is the main reason most project managers rely so much on process and documentation. It allows them to cover themselves and be 'successful' in an impossible situation.

Most Project Managers Don't Make the Call

The reality in many businesses is that the project managers are not empowered to make the time, cost, and budget decision; and even if they bring these issues to the attention of senior management, they may be forced to proceed with the project anyway. This is your hook to talk about why agile can be such a valuable addition to their PM toolkit.

Delivering in short cycles and measuring done gives you real data about the health of your project. Managers often assume the team has overinflated the estimates. They assume the team is sandbagging. Agile gives you real empirical data about the status of your project and what the team is capable of delivering. Agile gives the business real data, and real options; options that go beyond just how late and over budget do you want the project to be.

Put the Business Back in Control

Agile gives the business the opportunity to effectively de-scope on the fly, to change their mind, to increase the cost of the project, to lower the cost of the project, to deliver early, to deliver late, or to kill the project all together if the business objectives cannot be met. They get this information early, when there is still time to deal with it and make a rational business decision.

The senior managers I have worked with will make good decisions when presented with good data and real alternatives. Bad decisions are made in low trust environments with poor information.

Now Let's Talk Agile

So, with that groundwork in place, you can start talking about teamwork, collaboration, and empowerment. You can start talking now about pair programming, continuous integration, and test driven development. Those things just don't mean much to the PM community until you help them understand how agile will fundamentally put them in a position to deliver quality projects: on time, on budget, and with the highest value that can possibly be delivered.

Until then, people are just not going to get it. So next time you are talking to someone with a PMP next to their name, make sure you are speaking a language they can really understand. The traditional community is willing to listen, we need to make the most of our opportunity.