By Tony Riches

All organizations must cope with continual change while still delivering the best products and services. This is nothing new and managers have become skilled at juggling changing priorities. What is different is that customer expectations have changed. People expect shops to be open earlier and later, to get answers online 24 hours a day, seven days a week and appointments outside of normal working hours. At the same time there is huge pressure to reduce operating costs, staff numbers and to generally do more with less. Change will happen and needs to happen. Many traditional project management approaches are about attempting to limit change to “keep the project on track.” This is fundamentally the wrong approach. If something needs to change with a project, it should or else risk project failure and dissatisfied stakeholders. There is no simple solution, but the ideas that follow can help deliver change that is sustainable, affordable and valued by customers. This is Part Three of a four-part series. Part One explored what agile project management is and what makes a project agile. Part Two explored self-directing teams and the project manager as coach.

Steps in Delivering an Agile Project

Agile projects should be tailored to meet the needs of stakeholders and can have a number of phases, but they ultimately consist of three steps:

1. Starting up the project.
2. Delivering the project (actually doing the work).
3. Closing or finishing the project correctly.

Step 1 – Starting a Project

Agility is about recognizing that an individual cannot know everything at the start of a project. This does not mean an individual waits for perfect data. Instead get on with the project at hand and fill in gaps over time through data development. Even the things that are known are likely to change as the project moves forward. Because there is so much uncertainty, treat each project as a learning experience, so the sooner an individual answers questions, addresses issues and solves problems, the sooner an individual can adapt to what is learned and start delivering what is needed. Agile projects are not front loaded and one of the central beliefs is that an individual leaves the preparation and decision making to the last possible moment. This is recognizing that little is known about a project when starting out. Lean thinking considers work that is not immediately required as waste. If the scope changes and the project goes in a different direction, any front loaded preparation may become obsolete or wasted. Agile projects have to define the highest level themes and the details are only fleshed out a few iterations ahead of when they are needed.

Understanding the Vision

A reason is needed for doing the project in the first place. It could be a statutory requirement, to introduce a new way of working or to save money, but whatever it is, it needs to be written down. One of the most important things an agile project manager can do is to take this as a starting point and help the team “sign up” to a clearly communicated vision of what the project aims to deliver. This vision should be expressed as positively as possible and become a guiding force that helps the team make consistent choices and difficult decisions about priorities while keeping focused on and inspired by the ultimate goal. A good way to develop a guiding vision is through working with stakeholders to understand the vision for the project, the outcomes it seeks to deliver, the conditions of wellbeing for populations or results the service will deliver. From this, develop a view of appropriate population indicators or performance measures for services that will show how it is expected to support business and service goals and what will be different in the future. Throughout the project, the project manager guides the team to maintain focus on the vision, looking for opportunities to reinforce it through asking the right questions to provoke thinking about what it really means.

Establishing the Project Mandate from the Sponsor

After clarifying the vision, it needs to be agreed by someone (with the necessary authority) who should be the “sponsor” of the project. The project sponsor is not just a title, they really should support the project and help resolve issues. There may be a number of project sponsors, each with different needs and priorities, so it is important to engage with them from the start. This means making a special effort to keep them up to date with developments so that they feel real ownership of the work and can act as an advocate for the project at a senior level. A good way of doing this is to get them to say a few words to the project team at a start up launch so that everyone is clear that the project has really started.

Developing an Outline Business Case

There are a number of advantages to having an outline business case. Sometimes it is a funding requirement and it can provide a good opportunity to think through the options (including do nothing) before starting. It can help secure resources for the project and provide the basis for communication with all important stakeholders.

A common mistake is to focus on solutions before having a clear understanding of the social impact (consequences) and business outcomes needed to achieve. Start with writing down the problem(s) to solve, then the benefits of solving them. There are rarely less than three or four options (including do nothing) so it should be possible to assess any capital and revenue costs, anticipated savings, cost avoidance or income as well as the risks for each option.

Thinking About Stakeholders

The term stakeholder is often used without much thought. It is important to care about who has a real stake in the successful outcomes of the project and why. There are some obvious ones such as staff affected by the change and trade unions, but for bigger or more complex, multi-agency projects it is often worth setting up a short workshop to make sure that the best possible list of people who can represent different interests is obtained. Plus, ensure that the team understands why each requirement is important and to which stakeholder. It is equally important to make sure they have realistic expectations and that stakeholders understand which parts of the project are difficult, time-consuming or risky. The team also needs input from stakeholders to plan priorities and will have questions as they start to do the work, therefore, an agile team asks the stakeholders lots of questions about assumptions and the possible impact of different approaches.

Communication, Engagement and Participation

Individuals used to brief people about projects and rely on newsletters, but wherever possible on an agile project, communications should be face to face, two-way and open. With the agile approach the aim is to find ways to engage people in the work and get them to actively participate so that they do not just feel part of it – they really are involved. Participation is also about involving stakeholders in decision making and preparing to give them autonomy, power and influence over the approach taken and the outcomes. While engaging stakeholders also work out who should be included in the consultation processes. This can start with internal finance, human resources, legal and procurement specialists. It may extend to trade unions and partners that may not be directly involved. It is worth bringing all this together as a simple communications plan, which sets out what will be done for each (different) audience and when it will be done. All projects benefit from branding even if it is just a simple logo or a three-letter acronym as it helps to create a sense of identity at little or no cost and acts as shorthand for the values of the project team.

Agreeing to the Project Scope

It is important to be clear about what needs to be included in the project. The agile approach allows for a significant amount of flexibility and welcomes changes, which may emerge, after the scope has been decided. There should be negotiation around scope with the business owner and other stakeholders as it is up to them to decide how much they want to do and how much of the resources they wish to use (or if resources are constrained) what should be in the project scope. The business owner is expected to change priorities and negotiate scope changes on an iteration by iteration basis, anticipating current business needs and new external demands.

Agile Plans

For agile projects the planning process is high level and iterative in that it keeps going back to make small adjustments based on what is actually possible (rather than blindly following plans prepared before all the information was available). Agile project plans assume that there is some unpredictability, therefore, focus on the detail only in the short-term with just milestones and any known deadlines shown in the later stages.

Agile projects also use a technique called timeboxing as a way of communicating the value of time with a focus on cost. The principle of timeboxing is that the value of an outcome is based on it costing an agreed amount of time. If it costs more time then it does not have the same value. For example, timeboxing can be applied to meetings. A meeting has value if it lasts an hour and decisions are made. If it takes four hours to reach the same decisions then the meeting has a higher cost and it may not be appropriate.

Depending on the scale of the project it may help to develop a simple activity and resource plan to show when the project is starting and ending, any important decision points and events in between and who is doing what and when. A financial plan (usually a simple spreadsheet) will help set out planned and actual capital and revenue for the project and a communications plan is useful for setting out how and when the project will engage with each stakeholder group and different target audiences.

Establishing the Project Team

This starts with appointment of the project manager who builds a flexible team to match the scope of the project. It is really about finding a balance between having enough people in the core team to create a sense of team work with the ability for people to join and leave when contributions are needed. A good thing about the agile approach is that it does not matter if team members have no specific project management experience. The team really needs people who understand the service areas concerned and have empathy with the stakeholders.

Although few people will admit to having any spare capacity, the reality is that anyone should be able to cope with taking part in one project in addition to day jobs, therefore, it is up to the project manager to identify the best candidates and make sure they really understand the personal and professional benefits of participating in a successful project team.

One of the key roles is project support. This is more than someone taking notes at meetings. The agile project support includes making sure that the right people are at the right place at the right time with whatever papers they should have and a good understanding of what is expected of them.

As agile project teams self-direct (or manage themselves) the project manager has to be willing to let them get on with it, however, good project support makes sure that this is still a well-organized way of working. Similarly, the project assurance role is important in making sure that the team keeps on top of risks and issues and that the benefits really are going to be delivered at the end. It is also worth identifying specific individuals that will be the main point of contact for specialist areas such as finance, legal and communications while making sure that they really feel like part of the team by inviting them to team meetings and keeping them in the loop.

Next up: Understanding risks and resolving issues with conclusions on how to deliver and close an agile project.

About the Author:

Tony Riches is a chief officer at Cardiff Council and has over 20 years experience managing a wide range of projects and programs. These have included significant regeneration programs such as the creation of Cardiff Bay and the new retail center for the city to complex social projects such as developing multi-agency approaches to reducing child poverty. A PRINCE2 practitioner, he was involved in the development of the methodology and is a keen advocate of innovative agile project management approaches. Contact Tony Riches at  t.riches (at) cardiff.gov.uk.