Chat with us, powered by LiveChat
';

Agile project managers deliver projects - Not products!

Project managers plan projects, not products. I sat and listened – for a short while – during a discussion forum in which an Agilist took the floor to explain that the number one enemy of Agile was the project manager. It became clear that this person’s understanding of what a project manager was and did was uninformed.

Having been a project manager for 40 years, working on many occasions with software developers, as well as with individuals with a more rounded experience of projects, I am familiar with the tunnel vision of coders. However, I was momentarily disoriented by the wanton confusing of the creation of products with the execution of a project

When is it a project?

Of course there are pieces of work, which some individuals like to categorise as projects, which involve developing, usually enhancements to, well-understood products, such as improving a widget or writing a bit of code. These are just packets of work, or work packages. They don’t require project management or even much management and can safely be left to technically-trained people to produce.

A project, however, is a combination of needs that must be satisfied within constraints and conditions of success. Some of the needs can be addressed by the delivery of product, some cannot. The objective of a project is NEVER the delivery of a thing. It’s the achievement of a changed state that can only ever be partially described in terms of physical objects.

As a project manager, you weave together a number of disciplines. This includes the three product disciplines of quality management, configuration control, and testing. The content of these is often largely determined by the choice of development life cycle. That decision should normally be left to the technicians. All the project manager needs to know is whether to trust the judgement of the technical leader: that the choice made fits the capabilities or the individuals doing the tasks and can deliver the capabilities required of the product within the constraints and success factors of the project. 

The trouble with the choice of Agile is nothing theological. It’s just that it technically is inappropriate in a number of circumstances. This includes where the conditions of success demand completion within a set time or cost, where the inclusion of specific requirements – safety, security, specific business rules is more important than team morale, team satisfaction, or delivery of early value at the expense of long delays paying off technical debt.

Project plans are there to manage uncertainty

Project planning is part of the way to manage uncertainty. A plan is a view of the future, created from the state of knowledge at that time, and supported and extended by the inferences that experience and the underpinning models provide. As knowledge increases that view may change, and the new route to the future must be captured in the plan.

A good project plan describes how to achieve the project goal in the context of the project’s ‘territory.’ It shows how the parent organisation, the local project environment, and any competing projects affect it. The plan helps to determine where you are and how to get to your goal. This is true even when you have been driven off course. In many ways, a project plan acts much like a map. A map is also a model of the world. While plans have assumptions, constraints, risks, et cetera; maps make use of rivers, roads, towns, and so on, as their constituent parts.

Whatever else a plan is and does, it is always a communication vehicle. It conveys information, sets expectations, and allows decisions to be made. A project plan is unique among the set of governance documents used to run a project – it has two audiences. This does make the writing of it a little harder. One audience is the governance group–and sometimes more widely the key stakeholder. The other is the project team. However, the communication purpose is singular. That is to provide these audiences with enough ‘big picture’ context and information so that they know how they can best be involved in supporting and achieving the project’s objective.

With no planning there is no forum to gain agreement from the differing audiences, there is no clarity about the outcomes. Without planning, sources of uncertainty cannot be articulated into usable estimates. And without planning there is no vehicle to compare and contrast solutions regarding desirability and degree of risk. But, and most importantly of all, without planning the best opportunity to engage, and to engage with stakeholders, is lost.

Project plans define the agreement between the team and client

Planning, as essential in projects that use Agile as in every other type of project, is about the need to contain uncertainty and set out an agreement between the sponsor and the doers. Projects are only successful when the conditions of success are met, whether that be constraints, such as its end-date, a fixed price or some other hard boundary condition, because these set out precisely what the project has to deliver, and in many circumstances this not just a functionally capable product. Who and how it impacts the key stakeholders is often much more important.

Projects are uncertain endeavors, and the project plan sets expectations by describing a possible and accepted route to delivery. So is it an agreement? Does it set out what the project has to do? A plan sets the baseline expectations while capturing the uncertainty and risks that must be addressed as the project progresses. A good plan will give sufficient confidence to stakeholders that they feel able to make decisions and engage resources. So it is an agreement, but it is not a contract.

The function of the plan is to identify how to run the project in the right way. There is nothing that implies that the plan must come–and can only come–before the project effectively starts. Traditionally it was considered so, but this was never true. Planning is an activity that takes place when the project needs to manage uncertainty, and that can occur throughout its life. In point of fact, perhaps the most valuable contribution Agile has made to project management is to break the planning mindset of first and foremost as a timing concept and changed it to mean planning is the first and foremost in importance throughout the life of the project.

Purposeful planning connects desires with reality

Appropriate planning is the hallmark of professional project management. Good planning is what sets apart well-run projects from accidents. Purposeful planning is what ensures that the executive actions undertaken in a project remain connected to the goals and outcomes expected by the stakeholders. Let’s not lose this by being seduced by ‘agile’ talk by Agile advocates who confuse delivery of products (outputs) with the delivery of project outcomes.

logo