Agile Project Manifesto

The agile project manifesto was created by Jordan Shlosberg,  and applies agile software development principles to non-software projects.

The goal is to make project delivery faster, higher quality and most importantly, give ownership to others.

Any piece of work must improve a KPI and that KPI must be measured

If you are undertaking a project, it must provide a benefit to the business and that benefit must matter to the business’s strategy. There’re always a hundred projects to do and little time to do them which means that intense focus is required to understand which projects move the right needles. Any piece of work undertaken for the business must be for a reason and that reason must be expressly defined. Moreover, that reason must have a definable KPI and that KPI must be measured both before the project begins and after it is concluded.

It’s an added bonus if the outcome of the project can be directly tied to clear business goals. Focus often means that we have to give up some things for the benefit of others.

All large projects should be broken down into smaller deliverables

Large projects are unwieldy. During the course of a project, new things are discovered, and scopes change. If a project takes too long, there is an increasing risk that the final product will no longer satisfy rapidly changing market demands and consumer needs.

Agile aims to deliver KPI improvements in increasing increments.

Embrace change

Most businesses don’t like risk, but what is even less desirable is wasting time and resources on a project that’s no longer relevant by the time it’s finally completed. By welcoming change and actively seeking to make improvements through consumer feedback, businesses can gain a competitive edge - their projects will satisfy the immediate needs of consumers and their products will be guaranteed to provide business value.

People change, times change, and markets change. Trying to fight it is pointless. Traditional project management usually sees change as a problem to be solved, but agile embraces change and uses it to the customer’s advantage.

Bring autonomy via delegation (not abdication)

Successful projects are successful because those running them are motivated to make them successful. As a leader, you need to create an environment which allows your team to feel ownership of what they are doing.

The first step is delegating, which means agreeing on the outcome and allowing your team to get to the outcome in the way that they know best. Regularly offer to help and make yourself open if the team needs you but if they do not, trust you have the right team.

It’s very common to assume delegating a piece of work means delegating the responsibility for that piece of work. Accountability flows upwards and therefore your teams work is a reflection of your ability to lead. Agree on the project parameters, check in regularly and ensure that the team are hitting the goals that they have set.

Managers have to trust their teams to get the work done without constant micro-management. This means that a project team is left to deliver but provides the manager with clear timelines (updated regularly), as well as impacting KPIs

Too often, business owners forget that their employees are professionals who take pride in their work (this is especially true in any creative role). If you build your projects around people who aren't motivated to succeed, they're very likely to fail. That’s the fault of management.

Owners and managers need to create an environment that rewards success, fosters healthy working relationships and help improve employees’ work/life balance. This means that the demands of the project focus on the output (ie what will be delivered and when), as opposed to the input (ie how do you get to the output)

Don’t compromise on quality

Although shorter time frames may lead to more simplistic project outcomes, quality can remain high. Teams should take pride in their work and basic errors should be absent. This means spelling, grammar and design.

Reflection and adjustment

Every project should be measured against a pre-defined set of KPIS to understand if it was a success or not. Reflection on past successes or failures allows the team to create space to learn from the mistakes that inevitably happen.

No team acts perfectly but a mature, informed, and responsible team can improve itself by taking both proactive and reactive measures to improve development.

Create timelines, not deadlines

A project is a piece of work that is designed to move a KPI and comprises a number of workstreams that are of uncertain length. Deadlines as a concept can lead to a pressure cooker environment, especially if the ‘deadline’ is totally unrealistic.

An unrealistic deadline can lead to stress, unhappiness and, ultimately, a poor deliverable.

Delay early

Project estimates are estimates. Teams must get into the habit that things subject to change. However, when it becomes likely that the project will take longer than initially envisaged, it is best to communicate early.

The closer you get to your first promised delivery; the more others will expect that delivery to occur. It may be the case that communication is occurring around the business and so the timeline for the project begins to impact timelines on other projects.

By adjusting early, you ensure that other projects don’t get impacted.

Whoever has ultimate accountability for the project has the ultimate decision on its direction

Democracy doesn’t work in business. Someone must always take accountability. That person should take responsibility for everything that occurs in that project.

In the same vein, while spirited debates and disagreements are good when planning a project, the debate must lead to a resolution. Every project must have one person who is ultimately accountable. It is this one person that should listen to all the opinions, and then decide upon a full and final direction.