Models of a Project Manager role in an agile project

The roles a project manager can play in an agile project are endless and a lot depends on where one’s interest lies and also the type of project one is working on. Again not all of these roles are applicable to all agile projects.

Here are a few possible options

The Iteration Manager

This is the most hands on delivery role one can do as a project manager on a team. The work largely involves planning iterations, resolving blockers from the daily stand-up, ensuring a smooth passage of stories across the story wall.

It requires working closely with all roles within the team and understanding the core practices of writing a user story to the essence of continuous integration

Program/Project Manager working with Iteration Manager(s)

If a project demands a larger team, with multiple parallel work streams, one might need an Iteration Manager for every decent sized (3-4 developer pairs) work stream and an overall project manager looking at work across teams. Depending on how large the project is the role is often termed as a “program” manager.

The work involves managing functional and technical dependencies across work streams during upfront release planning also during regular iterations . It also means providing an overall program status to senior stakeholders with the necessary abstraction of details.

Release Manager 

If it is a large enough project which is making multiple releases into production, there could be a need for a full time release manager role. Work here would involve planning upcoming releases and tracking stories and defect fixes are merged across different branches. It also requires a decent understanding of the techniques and tools such as continuous integration, version control systems, branching strategies etc.… to engage in an effective dialogue with senior developers on the team.

Project Manager working with a vendor PM counter part

If a lot of work is done by vendors either outsourced or co-sourced, there could be a need for a client project manager who can work across with all the vendor PM counterparts. Typical work of a client project manager involves resolving issues in the project dependent on decisions from stakeholders within the client organization. This could mean things as trivial as getting environments setup by the client IT team, to as complex as escalating critical issues about the product delivery to senior stakeholders from the business

The vendor PM(s) here acts as a project/iteration manager working closely with the client project manager every iteration.

Client Account Manager

A client account manager can become a full time role for a vendor executing a big project for a client. Major part of the work involves managing the ongoing client relationship by being part of key conversations with the senior client stakeholders, project sponsors etc.…  Work also includes billing and invoicing the client for the services offered.

A client account manager with a strong de livery background can assist a lot in having difficult conversations with a client when there are delivery issues within the project.

The challenging setup of an offshore project

After managing a few agile projects from India and learning the tricks of the trade, I have been wondering why life is much easier when you are working closely with the client as compared to working offshore. What worried me more was that I had to learn and use a lot more of project management techniques (making trade offs , managing risks etc..) from offshore, but what mattered while at a local client was building relationships and managing client expectations.

The answer to that is partly the challenging setup of an offshore project. Here are some of the odds one needs to battle with up front while delivering from offshore.

Budget is a critical constraint

There are no 2 ways about this. Clients try offshore when they are constrained by the cost of the project. And with that, among all the variables a project manager can play with, cost becomes a constant.

This means that if you made a release plan with certain velocity assumptions initially which do not come good in the first few iterations, you cannot increase your team size easily (given enough work could be done in parallel) as the client will not be happy with the increase in cost.

A burning business backlog to be delivered

It is quite natural for client to have their own IT teams build the necessary software required to run their business. The in house IT team guarantees close collaboration with the business. All is well until the in house team cannot deliver which is when the business backlog of features starts growing, and the business slowly starts losing trust of their IT team. This is typically when an offshore vendor is called for to help the IT team climb the mountain of business backlog they have built up by not delivering consistently.

When you look at this from offshore, you are looking at a scope full of must have features which if not delivered in the next few months, will almost kill the business. Negotiating on such a backlog is never an easy conversation with the business people.

Negotiating is difficult from miles away

What makes negotiation worse is the fact that the offshore team is sitting thousands of miles away from where the actual business is. Building rapport with senior client stakeholders can no more be done via hall way conversations or over a water cooler. If you even needed 5 minutes from a client to talk about the priority of a single defect, you cannot just walk over to his desk. All these become formal conference calls over phone or video conference.

Client IT teams end up micromanaging offshore vendors

There is nothing worse for a project than a backlog full of must haves, very minimal budget, lack of trust from the business and an IT vendor half way down the globe trying to deliver. Given such a scenario, it is natural for a client IT team to be more risk averse and to micro manage their IT vendors.

A slip in velocity is treated as a red alert with the need for a full time vendor project manager to provide explanations to their client IT counterpart.