During my time working as an internal auditor in development aid, one of the key challenges of the organisation I was working for was the management of a lot of projects … about 200 concurrent ones. And one of the key discussions about those projects, which were quite often – remember, development aid – implemented in very instable, unpredictable environments, was what a feasible, manageable commitment of the team could reasonably be.
The question of course is in essence about what you ask of your team. Because teams and team members are important: we are often talking about subject matter experts that look to give as much as possible to their field. And given the complexity of development aid, quite probably the most complex sector I’ve ever worked in, it is very important to be very clear upfront, not only to your team, but also to the beneficiaries, what is considered to be a successful project. What is the actual commitment you want the project team to take?
Now, before diving into what is possible, let’s first explore the two extremes on the axis of types of commitment a team could take in any type of project, not just in development aid. After that I’ll return to development aid and explain why I believe an optimal middle way exists and makes a lot of sense.
Commitment types on a commitment continuum
If we imagine that types of commitments can be situated on a continuum, we can identify two extremes: time commitments and outcome commitments. There is no explicit preference for either type of commitment. I actually believe that while either makes sense in certain circumstances, none are optimal in situations with high degrees of uncertainty.
Extreme A – time commitments
A typical commitment of a team is time: each of the team members dedicates a specific amount of time to a project, depending on what is available to her or him. The possible time commitment will vary depending on the profile of the collaborator, the scope of the project as well as its priority. The team has to ensure that each team member puts in the time.
We often find this type of commitment in a project that consist of a run-scenario, where the team needs to “run” a certain activity for a specific period of time. This makes sense if the relevance of the run is never questioned, but in uncertain environments this is often more indicative of an unwillingness to consider its relevance rather than a well considered decision taken at regular intervals.
Extreme B – outcome commitments
Another typical commitment of a team is a specific outcome: in the conception phase of the project, a specific wanted outcome is defined which the team is required to realise. Clearly, this puts us at the other extreme of the scale of types of commitments. Independent of time, availability, capacity, the team is committed to a specific outcome which it should realise in order to be considered successful.
We often find this type of commitment in a project where we want to achieve a specific result. In development aid, such an outcome is often the result of a negotiated agreement between two parties, often one the funding partner and the other the beneficiary partner. Such an agreement often leaves little place for adaptation if the context and/or the circumstances change. Projects are often still ongoing even if the context no longer warrants them because the parties committed to them.
Effect of commitments on projects
When an outcome commitment is in place, collaborators will aim to achieve the intended outcome. However, as an outcome is influenced by a myriad of factors other than the active engagement of the team, teams could quite quickly be confronted with situations in which the intended and the probable outcome start to diverge. In such a situation, it is often very difficult for the project leader to keep the team motivated throughout the project. As a result, the actual outcome will drift off course quicker and quicker … often resulting in a project failure.
When a time commitment is in place, collaborators will spend the allotted time on the project. In an ideal world, they do this in an effective and efficient manner. They aim to achieve the desired objectives of the project, but their commitment is a best effort commitment. There is not necessarily a direct link between their effort and the intended outcome of the project. If the project was designed well, the available time should, in the most optimal of cases, allow for the outcome to be reached, but there is no direct link between outcome and effort. In a run situation this is less of an issue, but if the run is no longer relevant, we are just wasting good resources.
In most cases, neither of these commitments will actually lead to an optimal outcome, and this even more so the case in an unpredictable and unstable environment like development aid. So the question then becomes the following: is there anywhere on the continuum a type of commitment that leads to a relevant result? I believe there is, and I believe there are methods that allow us to get the optimal result from such a commitment.
Or, from a book on Agile Development I recently read:
“Even if a plan-driven process repeatedly produces disappointing results, many organizations continue to apply the same approach, sure that if they just do it better, their results will improve. The problem, however, is not with the execution. It’s that plan-driven approaches are based on a set of beliefs that do not match the uncertainty inherent in most product development efforts.”
The middle way – commitment to optimal added value
Now imagine the following situation: in a project, the beneficiary describes what she or he would like to see the project achieve as results. These beneficiaries or users each have very specific needs and wants they would like to see fulfilled. The project team captures these needs at the beginning of the project and is very aware these needs will evolve over the duration of the project. Part of the engagement of the team is therefore to monitor the needs and wants of the project beneficiaries, capturing evolutions and adapting them as they evolve.
Now imagine these wants and needs, even implicit ones are captured and consequently ranked in order of the added value they would bring to the intended audience. This ranked list is the project backlog. And here we start applying key principles of Agile and one of its more popular implementation methodologies, SCRUM. I invite you to read up on SCRUM because it’s a fascinating way to manage projects.
The team assesses effort required and commits to delivering a finished, usable part of the project – in essence a selected set of backlog elements – within a specific time frame, a sprint. They gather these fleshed out elements in a so-called sprint backlog. During this sprint, the team works only on these elements, and commits to delivering these elements in a usable form at the end of the sprint. Now, and this is the key of the approach, they continue repeating this cycle according to SCRUM principles up until that point that the cost outweighs the added value.
“A goal is not always meant to be reached; it often serves simply as something to aim at.” — Bruce Lee
Cost may be actual cost, but opportunity cost should also be considered: can this specific team work on another project which will bring a higher degree of added value than the current project? If this is the case, the project should be halted, the functioning components transferred to the beneficiaries in as far as this was not already the case, and the team should move on to the next project.
Beyond minimal viable product
This approach pushes the team beyond the principle of minimal viable product to the point of the optimal added value product. It is an approach which is feasible, relevant and realistic and optimises the usage of scarce team resources. Hence, I propose to move not to time commitments nor to outcome commitments but to optimal added value commitments. Agile methodologies such as SCRUM are absolutely applicable in this context and could well aid in making development aid a lot more relevant.
In effect, this approach requires you to ask yourself for any project: does the next step, the next deliverable of this project solve a problem that is worth solving?
Exploring The Black Box 