top of page
Search

Risk vs. Trust

When I was a consultant, I was trained in project risk management. List things that could go wrong. Assign a best guess of the percent likelihood each might happen. Assign a dollar value of the impact to the project if they do happen. Even soft-value impacts like loss of reputation get a dollar value. Likelihood times impact equals risk. Sort the list of risks from high to low. For each risk starting at the top, come up with ways to reduce the likelihood (mitigation) and ways to reduce the impact (contingency). Review your list, their likelihoods, impacts, mitigations, and contingencies weekly.

Being a quantitative kinda guy, I thought this was wonderful. As a project manager, I wallowed in such tools to keep my projects on target for costs and timelines. After a while, I noticed that I was thinking in this way outside my project work--even in my church work on the Christian Education committee (back when I was a Ruling Elder). I realized at some point that always thinking about risks colored my worldview. I might have always had a critical bent, but I was becoming more pessimistic--noticeably more pessimistic. I decided I did not want to live my life that way, always thinking about what could go wrong. In my early days with a software development team, we practiced a process-heavy and documentation-heavy style of software development. Describe the functionality of the desired software in exhausting detail. Write that up in a "Detailed Requirements" document. Have everyone read through it, and don't start work until the stakeholders approved it. Then write an equally heavy Quality Testing plan. Then have a way to track the quality metrics and bug counts and apply version control to the code. Execute a miniature version of this process on the build and deployment plans. Risk manage the whole thing. Only then could the developers get started coding. It would take six to nine months just to get started on a project that might only last a year and a half. Nothing went to production until that three-year window was complete.

Later in the same organization, we adopted more up-to-date processes from Silicon Valley startups. The idea was to deliver something as soon as possible. The dollar metric was no longer dollars of impact if something goes wrong, but dollars of value if something goes right. Don't wait for a heavy plan document. Instead, get started delivering value. Instead of checking with stakeholders to see if we were planning what they want, we would check with stakeholders to see if we delivered what they want. Every week. The contingency plan was "fail fast; fix fast." There was no mitigation plan. We expected to make mistakes, but we also became confident that we could fix mistakes without having to wait three years to deliver something. Some people thought we were doing faster software delivery, but that wasn't the point. Getting the same value out of the project might still take three years, but incremental value would be constantly delivered throughout the project, and the project stayed relevant, with no big "that's not what we wanted" or "the customers don't need that anymore" surprises at the end. One word for all this is "Agile."

This summer the lectionary has been taking us through the Gospel of Matthew. For the past several weeks, we've been reading a part called the "Sending Discourse," or the "Disciple Discourse," (Matthew 9:35-11:1). Indulge me as I line up this discourse with my project management experience. Jesus has compassion on the crowds. This is a very simple vision statement for the project. In an Agile project that might be all the detail you get on requirements. Jesus is the stakeholder and represents the crowd to the development team. Jesus names and assembles his team of apostles. He gives them authority and autonomy to realize the vision. He gives them a little more detail: proclaim the good news, cure the sick, raise the dead, cast out demons. Then he describes the development plan.

How we read this might say more about us and what we want to hear than about Jesus and what Jesus is trying to say. Go with no purse or staff or bag. When people reject you, don't retaliate, but let your peace return to you and move on. If you are brought before gentile courts, testify to the gentile courts. If people persecute you, move on. Expect division. When you read this, do you hear a risk management plan? When I was becoming a pessimist from too much risk management in my life, I would have read it that way.

With a more Agile view on this passage, it might be saying DON'T worry about risk. My commentary on the passage says that some scholars believe not carrying a staff means don't take with you the means to defend yourself while you travel. Don't list "attacked by robbers" on your risk management plan. Not taking a purse means don't list "might get hungry and need to buy some food" on your risk management plan. How can we possibly spread the gospel if we're tossed in jail? Don't put it on your risk management plan; the contingency is simple: testify to your jailers. Someone might call us names, someone might oppose us, someone might want to hurt us. Don't put it on your risk management plan. People called Jesus names (Beelzebub), people opposed Jesus, people hurt Jesus.

Christians have one thing that software developers and project managers don't. Christians can trust in Jesus. Christians can trust in God. Instead of fearing risk, they can trust God to feed them and keep them safe. Instead of fearing the people who might oppose them, they can trust God to keep the project moving along.

Two more points: First, the measure of success is the expansion of the kingdom. That means more people in the kingdom, and it also means more compassion in the kingdom. Remember that this all starts with Jesus having compassion on the crowds. When opposed or persecuted, be agile, pivot, and move on to the next town. When dragged before governors and kings, don't view this as an obstacle, but an opportunity to expand the kingdom in unexpected ways, to show compassion toward more and different people.

Second, Matthew 10:40 and following talks about reward. What is that reward? Expansion of the kingdom is its own reward. Note that I didn't say the work itself is its own reward (it might be, but that's a strictly different idea). As the kingdom is expanded, as more people are participating in the network of loving relationships that is the Kingdom of Heaven, the relationships get more abundant, and each relationship gets richer. Value gets delivered all along the way, not all at once in the end. Take no staff or purse or bag or change of tunic: don't depend on risk planning. Instead, depend on God. The value delivered is all the relationships you make along the way. Your compensation and your provisions and your accomplishments all become the same thing: the beloved community. The beloved community gets bigger and also more beloved. THAT's the reward. THAT's the value delivered by the project.

--Chas

Comments


bottom of page