Minimizing Total Cost of Ownership

In the world of Contract Lifecycle Management (CLM) platform (or any platform) development there are few occasions as momentous as the "Go-Live". A "Go-Live" is when a project team releases the system they've been building and it "goes live" with the end users of that system. It is the culmination of weeks or months or even years of workshopping, requirements gathering, designing, documenting, building, demoing, testing, training, deploying, communicating and more. All of the work is DONE!

Or is it?

Even though the system is now live, the work to keep it up and running and actually used has just begun. Someone has to support users, fix bugs, add new users, decommission old users, perform general administrative activities, build enhancements, and keep the system relevant within a constantly changing organization. There is a lot of work to do, and the decisions made before go-live greatly impact the amount, difficulty, and cost of that work.

The work that occurs after go-live contributes to a system's Total Cost of Ownership (TCO), and organizations seek to minimize this cost across all of the systems they use. There are five pillars of system design one can keep in mind before go-live that will result in low TCO. They are:

• User Experience
• Simplicity
• Robustness
• Maintainability
• Extensibility

Read on for how to use these pillars to minimize TCO.

User Experience

Make sure users have a pleasurable and fulfilling experience.

One of the reasons TCO of a system can skyrocket is because it is so hard to use. Users frequently get stuck because the system is complicated or hard to understand. With no other options available, users open support tickets or call a support center to get unstuck. Tickets and calls to support are expensive and kill not only the TCO of the system but also its Return on Investment (ROI) -- users may stop using the system altogether and any benefit it was supposed to have is negated.

Poor user experience also leads to development efforts needed to improve that user experience. The project team (or their successors) may need to revisit design and build decisions that were supposedly finalized, all costly steps ideally avoided.

When designing and building a system, keep the Seven Principles of Excellent User Experience in mind. These are:

• User Centricity: Put the user first in everything you do.
• Clarity: Minimize the effort and knowledge it takes to learn how to use your system properly.
• Consistency: Keep designs consistent in how they look and function across different parts of the system.
• Familiarity: Use your user’s past experiences and expectations to your advantage.
• User Control: Make sure that your users always feel a sense of control over their experience.
• Organization: Implement a highly organized system that is easy to navigate and intuitive to use.
• Flexibility: Do not punish your users for going off the beaten path or pigeonhole them into a restrictive process.

Keep the pillar of User Experience top of mind to reduce support costs, reduce development costs, and increase user adoption.

Simplicity

Choose the simpler design wherever possible.

Anyone familiar with Lotus Cars knows that they focus on building cars that are simple and light. This design philosophy is a result of Lotus Cars founder Colin Chapman and his unofficial mantra: "Simplify then add lightness". Simple and light cars are nimble, handle well, accelerate quickly, stop quickly, and are relatively inexpensive to make. Chapman abhorred complexity.

Complexity is expensive, so keep it simple whenever possible. Complex systems are difficult to build, difficult to understand, difficult to maintain, difficult to grow, difficult to extend, and just plain difficult. All of this difficulty leads to ballooning development and support costs for as long as the system is in use.

To follow the pillar of simplicity, ask and answer the following questions:

• Is this feature required or nice to have? Try to cut as many nice-to-haves as possible and focus on high quality required features.
• Is there anything else to cut out? Take the approach that system design is complete not when there is nothing left to add, but rather when there is nothing left to remove.
• Is there a simpler way of achieving this? Often, any single piece of functionality can be achieved in various ways. Try to find the simplest way wherever possible.
• Is this a phase 2 item? Software systems can be very complex, and it is often prudent to deliver systems in phases so as not to overcomplicate any one phase.

Keep simplicity in mind to reduce TCO for a system with lower development and support costs.

Robustness

Design the system so that it can handle a variety of situations and stressors.

Robustness can be best understood by its opposite -- fragility. Fragile systems are brittle, inflexible, and break easily. Even when they "work" they usually don't work very well. Robust systems can stand up to a lot of abuse from users and even from administrators and developers; mistakes, errors, and unexpected behavior from any of those groups don't bring the whole system down.

To follow the pillar of Robustness, ask and answer the following questions:

• What bizarre or unexpected behavior might occur? Ensure the system responds to such behavior gracefully and without causing massive issues, failures, or shut downs.
• Where are the extreme limits of the system and how will it respond? Putting the weekend groceries into the bed of a pickup truck is very different from putting 3,000 lb (1,360 kg) of sandbags into the bed. How will the system handle the software equivalent of a ton of sandbags?
• Is this the most performant approach? Software systems that take a lot of time and perform a lot of unnecessary calculations are generally not very robust.
• What could break the system? The answers to this catch-all question helps identify areas where system robustness is most important.

Think about how to create a robust system to keep TCO low; the system operates well without a lot of fuss.

Maintainability

Design and build with future system maintenance in mind.

No matter how simple and how robust a system is, it will always need maintenance. Always. Like a car, things break, things need fixing, and things simply need routine maintenance. Keep this fact in mind and that maintenance can be simple, easy, and low cost.

To follow the pillar of Maintainability, ask and answer the following questions:

• What are the most common routine maintenance tasks? Identify areas of routine maintenance and focus on improving and simplifying the maintenance processes.
• How can maintenance be simplified? Adding and removing users, updates to underlying data, and other similar tasks that happen frequently should be simple and easy to do.
• How can repairs be simplified? Design and build the system so that it is easy to diagnose and repair issues without major effort required.
• How easy or difficult would it be to learn how to maintain the system? Training someone to administer and maintain the system should be as simple and easy as possible.

Focus on maintainability to keep long term TCO low.

Extensibility

Focus not just on today's problems but tomorrow's, allowing for a system to grow and improve with minimal additional development effort.

The only thing that never changes in software (and in life) is the need for change. No matter how functional and feature-rich it starts, all software systems will need improvements and extensions -- they will need functionality changed and added. If a system is very rigid and built with a narrow understanding of today's problems it will have a hard time extending to tomorrow's problems. Adjusting it in the future will be costly.

To follow the pillar of Extensibility, ask and answer the following questions:

• Where is the use of the software going? Identify any upcoming or possible strategic initiatives related to the use of the software; while the software might not address those initiatives in its current form, it should be as simple as possible to accommodate them.
• Where are areas for growth? Identify areas where the system may need to grow. In a CLM system, new reviews and approvals may be needed and building those should be easy.
• Where are the likely areas for improvement? Build the system so that improvements don't require complete redesigns and tear downs. Making the system better and more capable should be akin to building a pyramid, not a Jenga tower.

Design and build with extensibility in mind to reduce TCO and ensure the system stays relevant for a long time.

Conclusion

Software go-lives are exciting. After a lot of hard work, a project team can finally see the fruit of the labors. They can finally see users getting value from what they built. But while go-lives are exciting and certainly cost a lot in their own right, the work that follows contributes much to the Total Cost of Ownership (TCO) of a software system.

There are many design and build choices that affect long term TCO, and adhering to the five pillars of system design that result in lower TCO. They are:

• User Experience
• Simplicity
• Robustness
• Maintainability
• Extensibility

Keep these five pillars in mind before, during, and after go-live to minimize TCO and maximize the benefits of any software system.