Financial Models – Another Form of Visibility

I recently had an eye-opening experience with one of my coaching clients. We were trying to find a way to reasonably have a single team work with several important stakeholders throughout an organization, each of whom had a different project for the team. Up to this point, the team has been time-slicing between these stakeholders. It is stressful work, constantly switching gears. The last time we were there, we started to look at the value the team was delivering to each group. This is where the surprise came.

I was hoping that by building a simple financial model for each stakeholder’s project we might be able to find a way to build a proportional schedule for the various stakeholders. Each project would get some proportion of the team’s time based on relative value. I was also hoping to eventually roll these values down to the level of individual items on the backlog. I didn’t get that far.

What did happen? Well, we did a rough guestimate of the various values of the projects based on the team’s understanding. There wasn’t anything too surprising that came out of that. We used that now-prioritized list and spoke to the stakeholder (let’s call him John) for the highest value project on the list. We sat down with John for about two hours to build a simple spreadsheet financial model.

His project was about adding automation to a fairly long manual process that was used to build stuff for paying clients. We started out by doing a value stream analysis. We wrote out all the steps in the process and it turned out to be about 20 steps. I’m going to keep the numbers simple but representational. Those twenty steps took, on average, 8 weeks to complete. There was very little wait time in the process. But there were lots of opportunities to turn manual operations into automated operations (mostly through the use of computer models rather than physical models).

We also looked at the value for each client request (say $25000) and the number of jobs finishing each month (about 20). This leads to the very nice big number of $500,000/month revenue for the current process.

For each step in the process, we also assigned a time cost in days. This was the average amount of time each step took. By doing this, we were able to assign a dollar value to time reductions in each step. My client had plenty of business and would easily be able to take on more jobs from its clients if only it could do the jobs faster. So by reducing the overall cycle time and completing 21 jobs each month, the company could gain another $25000/month in revenue.

We then looked at all the opportunities for automation in the process and came up with a new time cost for each step. When we did this (and we tried to be conservative), we discovered that we could reduce the cycle time to half.

Doing the math was easy, but it made a huge impact on me. This particular project would lead to a doubling of revenue from $500k/month to $1M/month. The ROI (not counting time value of money) was enough so that the six months of development time that would be needed to buld the automation would be paid for in less than a month!!!

When we looked at the other projects in the team’s queue, we saw that none of them would come even close to one tenth the value of this one project.

This huge difference in value makes it clear that the organization has a responsibility to get this one project done asap and likely to the exclusion of any progress on the other projects. The team does have operational responsibilities as well that must be done to keep the business moving, but the priority of new project work was blindingly clear.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.