Building with Anaplan while avoiding perfectionism
Author: Dave Edwards, Certified Master Anaplanner and Principal at Columbus Consulting.
Inevitably we will all encounter projects that drift too far into the realm of perfectionism. As companies transition to more agile software solutions, the lingering perspective from older system design that a tool must be perfect to accomplish its intended purpose can unnecessarily hinder successful implementations.
For example, with point solutions, modifications to underlying performance or architecture are generally outside of (or heavily limited within) the available feature set that a product can offer. As a result, it is imperative that project teams be as specific as possible when seeking out one of these tools to purchase for a business need. Otherwise, the software could fall short of fixing the company’s problem and costs may not be recoupable.
Similarly, with heavy code-reliant software or homegrown solutions, minor changes requested by an end-user often require major changes for the developer. Rewriting entire sections of code can be time-consuming and potentially result in negative impacts on other parts of the design.
In short, these situations and alternate software solutions routinely result in:
- Extending the timeline and budget by focusing on the fine-tuning of low-impact features.
- Missing the basic functionality that end users need to do their jobs (i.e., not seeing the forest through the trees).
- Potentially deeming the solution a failure because it doesn’t meet unnecessarily high standards.
Is Anaplan different?
Since the very nature of the Anaplan platform allows model building to be a fluid process, perfectionism is especially unnecessary. Module structure and end-user experience reconfigurations are relatively fast to accomplish. Staging out new features as proofs of concept can be done in isolation from the underlying architecture. Should a major change need to be rolled out, data can be quickly audited in test models before updating the live production environment.
On a small scale, companies are more frequently adopting an MVP or pilot approach to Anaplan implementations. The understanding is that a short-duration project allows new users to quickly see the benefits of the Anaplan platform’s flexible design capabilities while refraining from committing a large budget outlay from the start. The design does not need to be perfect to convey a message of efficiency and scalability for new Anaplan customers.
On larger projects, Anaplan’s usability allows developers to hit a metaphorical sweet spot in their designs:
|
What does the sweet spot do? |
What does the sweet spot not do? |
|
|
No one wants to spend excessive effort creating a solution that is too specifically designed that it fails to achieve its basic business purpose. A project budget is not worth a model that perfectly accomplishes very little, instead of one that solves many problems with room to grow and improve.
With the right project team mindset that avoids perfectionism, Anaplan’s agility and usability will quickly become a centerpiece of continued success and problem-solving at any company.
Do you agree with this philosophy? Leave a comment!