As an organization, we have moved from programmes designed to address specific issues affecting children with very detailed upfront planning and precise execution to ones that are more complex in terms of social, political and environmental impacts. While this kind of planning methodologies work well in some scenarios, they often don’t work well for many of our complex service delivery programmes today. Agile project management, a different approach to how projects are planned and executed, is designed to deal with complexity and to adapt to realities on the ground that arise as a project is implemented.
As established in Part 1 and Part 2 of the series, having project teams, especially those on the ground, closely involved in the planning process helps embed an understanding of local context into the plans devised. In reality, however, project teams are usually put together after proposals are approved and funding allocated. They are tasked to execute the detailed requirements outlined in the project plan. How do we reconcile the desire for early project team involvement and adaptability with the organizational reality?
Project teams, without having to partake in the initial planning, can still steer effective implementation and take ownership. Without getting too technical, we want to briefly discuss two methods that we’re trying to incorporate into our project management processes, based on our learning from QOWA.
Agile project management is an iterative and incremental method of managing the project lifecycle of a new product or service (Wikipedia). To put it more plainly, it means the project team delivers pieces of the product throughout the course of implementation, receives feedback on the work in progress, closely engages the project owner/user in modifying technical requirements, and updates the ensuing plan of attack accordingly. It allows projects to change course dramatically and re-prioritize what is seen as important based on how well aspects of the project are functioning.
It’s particularly applicable and helpful for UNICEF’s complex, large-scale projects because
- It’s adaptive to changes in environment and thus become more resilient.
- It breaks humongous projects down into smaller tasks and deliverables (modular) that are of value even when stand-alone.
- It decreases failure rates by continuously delivering pieces of final product, rather than delivering a whole package (monolithic) at the deadline.
Iterative design (see graph below) is a cyclical process of designing, prototyping, testing and evaluating with the purpose of improving the quality of a product or service. The key is being able to test the product/service with end users (see part 1), and improve the design with the next prototype/iteration based on that feedback. Each prototype/iteration is a step closer to the satisfactory “ideal” product. The ideal scenario is when Rapid Prototyping can be used within in this design process, which basically means making prototypes/iterations quickly and efficiently. Where physical products are concerned, rapid prototyping can involve the use of 3D printing or 3D modeling, though in the field simple paper or wooden models may be more appropriate. In a broader context, it can also just mean quickly producing a model of the product that doesn’t necessarily have a high degree of resemblance to the final product.
“Agile” was originally and prevalently used in software development and “Iterative design” in industrial design. Both methodologies have overtime become less sector-specific, and are being utilized in non-technology projects. They are closely aligned with two of our innovation principles:
What simple useful lessons from the above methodologies could have been applied to QOWA to make it more successful ? In light of the two processes briefly summarized above, we would do things modularly, iteratively, and closely engaged with all stakeholders.
- Break down big projects into modules: QOWA was complex and ambitious. It has components such as software development, curricula development, young people’s empowerment, teacher training, capacity building, community engagement, advocacy, etc and each of these components affect the others. Viewing everything as one entity and attempting to do everything at once resulted in confused priorities, unsustainable financial planning and hazardous implementation. Instead, if each component is viewed as a modular deliverable – functional on its own and of individual value – the complex project becomes easier to tackle. For example, QOWA could be five smaller activities- curriculum development or teacher training etc.- executed under the overarching programme of providing access to quality education in post-conflict situations. Each component would proceed collaboratively and produce functions or deliverables, but within a framework, allowing different paces of implementation and adaptations as necessary. Each component would need to take the others into consideration but as interacting separate systems as opposed to one monolithic system.
- Update implementation plans regularly: each time a deliverable is presented and evaluated, the next steps and expectations – timeline, technical specifications, budget – should be updated and clarified. This allows the team to adapt plans handed-over to them with adequate understanding of the production/implementation status and environment.
- Test with users for multiple rounds: Don’t expect to deliver the satisfactory product at first attempt, or the fifth. Test prototypes and processes with users and obtain feedback, improve the product or service and test again, until it is well received by users and stakeholders and providing demonstrated value. In order to do this, prototypes need to be designed quickly and cheaply where no elaborate finishing is needed. This prevents us from going too far along the road (and paying dear prices by solving problems that don’t need to be solved) before it’s too late to get a project back on track. It also allows for users to identify better approaches to delivering against the project objectives that might not have been anticipated or obvious in the planning phase. For example, when a workshop is being planned, quickly develop a syllabus or concept map as a rough outline and try to get feedback. Do not wait till handouts are already color-printed to get feedback when changes are costly.
What are some of the biggest challenges to get “agile”?
- The shift of mindset from planning to delivering results: After all, is the goal of our work executing the plan exactly as is or achieving results for target beneficiaries? The answer to this question is easy, but the mindset shift required is not. We are constantly asking ourselves: “are we really doing the things that we set out to do?” When the mindset is shifted towards achieving results, we may find ourselves more open to observing realities on the ground, addressing issues and challenges, and receiving feedback from stakeholders, rather than being “knowledgeable” about “planning things out.” This approach requires an aspect of humility and introspectiveness and the need to abandon theories and plans when the evidence and users show something is not working.
- Discipline, discipline, discipline: None of the processes actually points out what we should do, rather, how we do things (processes). Agile project management and iterative design are rigorous processes that require discipline to practice and in essence you replacing a reliance on planning with a reliance on processIt’s easy to get sloppy about them and then the project can easily get off track. The good news is that they are also acquired skills that anybody can practice and become skilled at.
In Part 4 of the series, we’ll take a closer look at the budgetary side of the project.
Special thanks to Merrick Schaefer, who is currently the Lead for Mobile Data in the Global Development Lab at USAID. He was one of the founding members of UNICEF’s Innovation Team and led Project Mwana for UNICEF.
Innovation Unit, UNICEF NYHQ