Good/Cheap/Fast — pick two (and how NGOs can play the triangle like a pro)
Bad news: if you’re planning a tech project then there are some hard choices you need to make.
Good news: there’s a smart and simple system you can use to think about the main constraints that will shape what you build. It’s called the Project Management Triangle.
Understanding this triangle and how to manage it will mean you can create better plans, communicate your priorities more clearly to developers, and ultimately get better results whatever you’re working on.
The triangle works like this. There are three key points: good, fast, and cheap. Your project can be any two of these but never all three.
That means there’s always a trade off:
Cheap + fast = lower quality work
Fast + good = expensive
Good + cheap = not happening anytime soon
What are your priorities?
Hacking the Project Management Triangle for NGOs and charities
So that all makes sense, right? It’s a closed system and you have to make choices about what’s most important to you. Seems fair except you work for an NGO and that just isn’t good enough. You have to respond to tight deadlines — usually ones you can’t move, you’re working to razor thin budgets and are accountable to donors and supporters, and it has to be great because you’re working to change the world. That makes it all a bit more interesting. Sounds like you need some help on how to hack the triangle and get more out of your project:
How to deal with needing it to be faster
- Be clear on what you want and try to avoid changes to your plans. Have you given it all enough thought before kicking off?
- Know your absolute deadlines and work to those not artificial ones that create a false need to rush. Can the delivery move back?
- Fail quickly. Doing a little and learning from that step saves time compared to doing a lot, making bigger mistakes and having to redo more.
- What is the minimal viable product (MVP) you can build? What functionality do you absolutely have to have and what could be lost? Be ruthless.
How to deal with needing it to be cheaper
Note: this still applies even if you have an inhouse tech team because there are costs with any project whether that’s opportunities passed up or just simple internal social capital.
- Plan as far ahead as you can and schedule work with a long lead time. Try to use this as bargaining chip.
- Look at making a long term financial arrangement with your supplier (essentially economies of scale should make everything cheaper for you)
- Try to find external funding from grant making bodies, funders you have a relationship with or crowdfunding with supporters to increase the project budget.
- Have an honest conversation with your tech partner about the cheapest route to your goals (rather than just delivering your brief word for word, find out how they’d tackle this problem).
How to deal with needing it to be better
- Invest heavily in planning. Get completely clear on why you’re working on this project in the first place and then break it down from there (the GSOT framework is a favourite of mine). Small uncertainties at the concept stage will make your project very messy during delivery and reduce the quality.
- Be really clear with your developers why you’re doing this project so they know your aims too…
- …then ask their advice. There can often be an easier way to do what you’ve outlined using systems you’re not familiar with. If you’re working with experts, then use them for their knowledge not just skills in delivery.
This changes everything: agile methodologies
The big gap in the Project Management Triangle that you’ve probably noticed is that it’s built on the assumption that you can have a completely clear idea upfront of what your finished project needs to look like. In most cases this simply isn’t true and if it is, then it can often be the indication of a poorly planned project as it doesn’t leave any scope for user testing or other feedback loops to improve the work.
It can be difficult for NGOs and charities to move away from this fixed model of outlining an exhaustive list of requirements at the start of the project (what is known as ‘waterfall’ delivery). This approach has least risk upfront because it guarantees certain things and this is often a requirement in large orgs that have risk averse structures. However with an agile process you’re not choosing a fixed end point, you’re choosing a process to solve a problem. It means you work together closely with your developers to build, test and learn (then repeat!) over a set amount of time and do as much work as can be done on the problem in a set timeframe. You don’t know what the outcome is going to be but it nearly always gets you closer to actually addressing the ‘why?’ of a project by removing the set ‘how?’.
A perfectly executed waterwall gives a perfect project outcome, but we don’t live in a perfect world and starting a waterfall project thinking that it will work out exactly as you’re imagining is a recipe for disaster 99% of the time. An agile process works because it’s fundamentally an honest process. Agile acknowledges that we’re all human and we know we might misunderstand things or change our minds or discover new information as a project develops. Rather than waiting for the surprise at the end when the budget is spent and your tech partner can’t do anything to help, isn’t it better to plan around that?
If your project can take what is often perceived as more of a risk by going with an agile process then it’s really worth considering. What you build might end up being very different from what you imagined on day one but you can be confident that it will nearly always be better, cheaper, and delivered faster than a traditional waterfall project when all things are considered.
There you have it. That’s the Project Management Triangle and how you can play it like a pro (or throw it out the window altogether and get working agile).
John Dunford is the CEO at The Developer Society, a not-for-profit digital agency, working with NGOs and groups with a progressive mission to help make the world we live in a better place.
And of course if you liked this article, please add a clap below and share the piece — it means the world to us at DEV.