Author: PM4NGOs

by Peter Marlow

Agile is defined as “relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work [delivering value early and often] and frequent reassessment and adaptation of plans”. Agile concepts can be applied to many projects and can achieve better outcomes than more traditional methods.

In every project the project manager’s challenge is to balance the triple constraints of Time, Cost and Scope (see section 1.3 of the PMD Pro Guide). Each of these constraints is connected to the others. Whenever one of these constraints is restricted or extended, the other constraints will also need to be extended/increased or restricted/reduced.

The project manager needs to understand the relationships and trade-offs that exist between each of the constraints and agree priorities with stakeholders before the project is launched. It’s often hard to change these once the project is in progress.

Generally, donors and stakeholders can be inflexible about the project scope, so time and cost have to be adjusted to balance the triple constraint and build an acceptable plan. The problem is that circumstances often change during projects that impose a change of scope. This forces a difficult rebalancing process, which, if unsuccessful, causes time delays and cost overruns – and unhappy stakeholders.

The Agile approach to Project Management turns this approach upside down:

• Time is fixed by dividing the project into short fixed time iterations;
• Cost of resources is fixed;
• Scope is variable. It focuses on the highest priority requirements, with the expectation that the scope will evolve as the project progresses.

There is a decision gate at the end of each iteration to re-prioritize existing requirements, to consider any new ones as the project moves forward, and to plan the next iteration. It’s a form of rolling-wave planning. The aim is to deliver the most important requirements within the budgeted cost and time, but maybe not all the requirements. For this process to work it has to be highly collaborative. It’s essential that project stakeholders are closely involved, particularly users.

With this approach, donors and stakeholders will be more confident approving the project because costs and schedules are defined up front and the overall risk is lower. Hopefully, donors and stakeholders will accept that they can’t have everything, but what they do get will meet the main objectives of the project. So ultimately, the Agile approach to project management can result in a more successful outcome.

The essential element of the Agile process is to be able to prioritize the project’s requirements into four categories of importance:

• Must have – these requirements are guaranteed to be delivered;
• Should have;
• Could have;
• Won’t have at this time.

This is known as the MoSCoW priorization (the term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories). This process can be difficult as stakeholders often prioritize all their requirements as Must Have! A rule of thumb is that typically the ‘Must have’ requirements should take 60% of the project effort whereas the ‘Could have’ requirements will take no more than 20% of effort in each iteration.

Agile focuses on small incremental changes. The challenge can be that the bigger picture can become lost and create uncertainty amongst stakeholders. Building consensus takes time and challenges many norms and expectations. Resource costs can be higher; for example, co-locating teams or investing in infrastructure for them to work together remotely. The onus can be perceived to shift from the empowered end-user to the empowered project team with a risk that benefits are lost because the project team is focussed on the wrong things.

Another criticism of Agile is that it can encourage project teams to cut corners, resulting in a poorly supported outcome. It’s important to remember that Agile projects need to be managed carefully just like any other even if they are “light touch”. For example, the necessity for heavy project documents should always be questioned with stakeholders. Things should not be done just because “we’ve always done it that way”.

The critical governance decision is to select the appropriate approach as part of the project strategy and keep this under review. Level of certainty versus time to deliver is the balance that needs to be considered when selecting suitable projects to go Agile.

Agile integrates well with PMD Pro phase model as part of the tailoring process. But before using Agile you should discuss what you are trying to do with your line management, donors and stakeholders, and seek buy-in from them. It may require a change of organizational culture to make it work!

NGOs need to be Agile to survive and thrive – Agile is for everyone, it just needs to be applied with a big dash of common sense.

So, in summary:

• Agile is a way of working which initially seems to be counter-intuitive;
• It’s a mind-set that follows a philosophy and a series of principles;
• It’s flexible and adaptable to changing environments;
• It works in increments or iterations;
• You need to ruthlessly prioritize to make it work;
• Deliver little and often, test frequently to ensure greater quality;
• Needs focused, collaborative, empowered, transparent;
• With the right projects it can produce better outcomes.

With acknowledgement and thanks to the Agile Business Consortium at http://agilebusiness.org and the Association for Project Management (APM) at http://apm.org.uk