Overcoming the Tyranny of Rationality

#tldr if your development project feels a bit like going to therapy, you’re probably doing it right

Building a new model for analyzing your business seems like it should be straightforward:

Identify requirements
Write up Design
Build, iterate, review
Test
Deploy

And these are all parts of any new model deployment, whether it’s a common expense forecasting model, a stock compensation model, a revenue forecast, supply chain, or demand planning. The math is usually straightforward, the variables generally known (Department, Account, Entity.)

So why do so many models fall flat? Have low adoption? Become shelfware? Building a new planning model should make everyone’s lives easier. But it rarely feels that way, especially when a model is new. How can we, as the developers and client-side managers of these models make this process feel better? We have a lot to gain from this: a more relevant model, a happier user base, and a positive foundation to build upon.

In tech, we tend to reduce everything to manageable bits in order to get things done. Sensible. But something generally gets lost when building all the bits. It doesn’t quite all fit together like we thought in the end. I call this the Tyranny of Rationality: by reducing everything into bite sized pieces, we succeed on the task level, but lose site of the big picture.

There are many paths to succeed, I’ve collected a few of the key approaches that help me and my teams (both developers and client-side teammates) have high project success rates (judged by things moving to production, being adopted, and being expanded upon over time):

1. Know what a win looks like

The thing about projects is, it’s hard to tell when they are over. When is something “done”? Defining a clear win can make it easier to push a project over the finish line, which to me, means getting it into production and in use. I lean toward smaller phase 1 projects that address a handful of key pain points, rather than trying to build the whole palace at once.

Classic wins for planning projects include:

Single reference point for Actuals and Forecast
Ability to integrate directly with Actuals data sources
Provide ability for direct participation in planning process for all (no more “processing” spreadsheets in a central location to finish the plan)
Shortening the planning cycle and being able to run forecasts and what-ifs more frequently as a result

Defining these goals at the beginning of your project will not only help you build a model that truly adds value, but it will also help you discern along the way whether change request are needed, or whether certain items can be deferred to a later phase. If a change request is required in order to meet one of the “win” goals, then it may be required. If it is something “extra” then it can go on a list for future enhancements.

Prompt: At the very beginning of the project, ask the group: in 6 months (or applicable time frame), what will make you really glad you did this project?

2. Have reasonable expectations

This applies to both the client and consultant teams. Projects involving multiple areas of a company, multiple databases, and with multiple, sometimes conflicting, goals are not going to go smoothly all the time. Expect some things to pop up. Understand where bottlenecks in your own company infrastructure may slow progress.

Developers: understand that the client has generally a full time job on top of trying to implement a new planning system, they may not always have time for you.

Clients: understand that developers are trying to build something that meets your needs, but it may take a few iterations to get it right—developers are not employees of the client firm, they don’t have all the information an employee has and may interpret your requirements differently than you intended.

3. Show & Tell

Meet weekly with a small team of key people – preferably no more than 2-3 folks from the client team, and the same from the developer team. Yes, this is a classic “let’s go over the task list” type meeting, but w/ a key difference. Every session, spend most of the time showing what was built, and getting feedback on whether the direction is correct. This not only gives the development team early and constant feedback, but also gives the client a chance to get to know the model from the beginning, and understand different design implications or requirement requests.

This meeting should generate some “I don’t think it’s supposed to work like that” type of discussions—that’s OK, that’s part of the purpose of these sessions is to uncover any misunderstandings around deliverables and architecture. Writing a longer design document does not accomplish this goal, it generally separates the client and consultant team further, due to a false sense of security. Shorter design documents and more frequent review sessions have been a much more successful path for me.

4. Hands-on testing

Testing, testing, and more testing. If you want to love your application once its finished, be involved in the testing from early on. Depending on the company and project size, 1-3 developer people should be involved in the weekly review discussed above and involved in directly reviewing and working with the model throughout the development process.

As the project nears completion, the consulting team should run the model through some rigorous tests, and then the client should do the same. Once the model seems to satisfy the internal and external development teams, testing with a select group of end users is strongly advised. Often, issues uncovered during UAT are once that help improve the approachability of the model, such as sequencing of tasks, report parameters, and security/data access.

5. Gentle Rollout

It’s important to plan your rollout, especially if you have a large number of end-users. Even with a robust, tested, simple planning model, hand-holding is required. It’s helpful to keep in mind that most end-users may not interact with systems like your new planning system, and, things that make perfect sense to the development team sometimes need some explanation to the wider audience.