The Agile Project Manager (part I)

Imagine this: You are a project manager with a lot of experience managing projects. You really love your job and consider it as a profession. You got your PMP® more than 10 years ago. Your boss and clients are used to congratulating you at project closures. You are a regular speaker on congresses about risk management, Microsoft Project, etc. You volunteer from time to time for PMI® projects and events. Everything seems to show that you are a highly rewarded professional: When you talk about project management, everybody listen. Many colleagues appreciate your expert judgment.

Now you have just closed your last project, but you are not happy at all. It was a consulting project for a big company, aimed to beat the competition through a new technology. Client representatives knew for sure that they could not remain as-is, but they did not know how to change what. Dissapointed by the poor progress of an internal SME team, they decided this was a case for procurement. Your company won the bid thanks to a project plan based on flexibility, adaptation and collaboration with the customer team throughout the project. Your company also included some experienced agile CVs.

From the very beginning, you were aware it was going to be easy to complete the requirements baseline. Very soon you realized that the client team would never sign off a document like that, not to mention the scope statement, WBS, cost baseline, detailed schedule, etc. How on earth could you avoid scope creep? The only planning information you had was about some given milestones and the final project deadline in nine months!

Regarding costs, the contract specified person-days by category, that's all. Having so much uncertainty, how would you develop the project plan? The customer wanted biweekly follow-up meetings. How would you report progress? Comparing to what baselines? Your boss told you not to worry because the team members had succeded on analogous projects before. You could trust them. They should do a great job...

However, you wonder: So, what am I supposed to do?

Of course you already knew what your role was. You were the project manager for one reason, as usual: just to blame you if project failed. Having this in mind, you had to choices: option 1) the traditional way (investing effort on planning, taking assumptions on what you did not know yet, compelling the client to sign off the requirements baseline, schedule, costs, executing as planned afterwards, etc.); option 2) the agile way. 

Option 3) “just wait and see” has never been an option for you.

Your colleages warned you: This was a project prone to change by nature. For them it was not sensible to manage it the traditional way. Ignoring them, you decided to elaborate project documentation, to analyze contract terms and conditions, to plan deliverables, to control scope through a detailed WBS, to track variances on a Gantt chart, to control changes through an integrated change management system, etc. You wanted to assess team performance, but you couln't follow what they were doing. They talked about the project early in the morning each day by the coffee machine, but you was always late...

Precisely, you got lost on terminology. What did they mean with those jargon like sprint, product backlog, release burndown, impediment, retrospective, user stories, etc.? What language was that?

They measured requirements on story points, they did not used real effort units. They had a wall full of sticky cards, but they didn't write real requirement details as you required. When you asked for a forecast, they only provided information on the next two weeks timeframe. How could they work without a real project plan? By the way, one day you catched them playing pocker and they pretended to be working. This was enough, for God sake!

Surprisingly, customer stakeholders were happy. One of them had a register of continuously changing requirements. This person attended the biweekly review, among other stakeholders. The team explained the results, and the stakeholders accepted or rejected each of them. When stakeholders rejected a result, there was no drama: the team only labeled it as “to-do”. On the other hand, when they said “ok” to a feature, this was labelead as “completed”. You recall the PMBOK Guide process in section 5.4 Validate Scope. Was this a kind of online validation? You liked that!

After this meeting, they had another one, only for the team. They talked about lessons learned to improve processes on the go. And then, there was another meeting to get the plan for the next two weeks. You were quite lost in these meetings, unable to answer or suggest anything. One day you decided not to go any more.

Surprisingly, the project ended up on budget and on schedule! One day the customer called you praising for the good job: there were still things to do, but not very important. It was not worthy going on. You could close the project. Team members were satisfied and proud, as well, as you noticed at the celebration dinner. They were a synergic team, for sure, ready to go to the next project and get managed by themselves. That was a good return for your company on the human resources side. You said a toast on this. 

To be continued... read next post

Click here to read the Spanish version for this article

Click the label English to read other English written articles