Key Practices for Lowering Total Cost of Ownership

In this Guidewire Smart Approach blog article, I am going to talk to you about two key practices that I feel are paramount in lowering your overall total cost of ownership (TCO). Lowering implementation timelines, and thus a customer’s TCO, is a topic we take very seriously in Guidewire Professional Services, and we are committed to working with our customers to achieve this together in our software implementations.

There are many things a project team can attempt to do to lower TCO during the course of an implementation. Many of them are rather arduous in nature and can pose a significant risk to your business and the implementation project team. They also can be incredibly expensive. However, my experience has shown that the two I will discuss today are often very easy to implement, and even better, they are not expensive to do. Of course, nothing in the implementation world is free and there are considerations and effort that goes into putting these two practices into effect, so as with any best practices, it is best to fully evaluate any strategy before putting it in place.

Two key practices I have found that do an excellent job of lowering TCO are:

1. Using the Guidewire base product(s) as the foundation of your requirement-gathering procedure; and

2. Controlling requirement meetings to critical personnel and limiting attendance to these sessions.

First, let me talk a bit about using the Guidewire base product(s) as the foundation of your requirement-gathering strategy. As many of you know, Guidewire Professional Services prefers to use an Agile-based delivery methodology. A fundamental tenet of this methodology is conducting requirement-gathering sessions in an iterative manner with business and technical representation from the customer team. I’ve often seen these requirement sessions turn into detailed discussions about how things are today and that the new system(s) needs to replicate that specific functionality. The outcome of such a session is a laundry list of requirements that often are not fully evaluated against what the new Guidewire software does out-of-the-box (OOTB).

While it is certainly true that the new system will inherit functionality and processes from the legacy system, a better approach would be to elicit these requirements by using the Guidewire base product(s) as the foundation and center-point of the discussion. That is, the requirement session should focus on learning and comprehending what the Guidewire product(s) does inherently out of the box. Once that is accomplished, a discussion can follow, focusing on requirements and where things might need to be configured in Guidewire.

I know many project leaders are under the impression that this happens on their projects, but in my experience, only a minority of sessions are done this way. I would encourage project leaders to study this approach and work with Guidewire Professional Services and/or their chosen System Implementation Partner in formulating a strategy to make sure your requirement sessions are run with this product focus. Doing this can significantly reduce the number of configuration requirements that come out of the sessions, and as a result, can lower the customer’s TCO by having a faster implementation and less complex configuration code base that will be easier to maintain once in production.

The second practice I mentioned above to lower your TCO is to control attendance in requirement and design meetings. I certainly understand people’s desires to be involved in the Guidewire implementation, and as we know, it takes a plethora of customer resources to do these implementations successfully. However, I have noted a trend with many customers that they are sending over resources to meetings. In fact, I was recently in a meeting that had over 60 people in attendance! It doesn’t take an organizational guru to know that nothing is going to be accomplished in a meeting with so many people. The challenge to customer program leadership is this: You simply must identify, empower, and trust your key people to own the requirement and design process, and ensure these people are in the meetings that focus on requirements and/or design. Simply put, if the person isn’t empowered and trusted enough to make key decisions, they don’t need to be there. There are several other ways we can involve other non-essential personnel and keep them involved in the implementation program (possibly a topic for another blog post).

A best practice is to keep requirement and design meetings to a maximum of eight participants, including Guidewire and/or System Implementation Partner resources. I find that meetings that have more than eight participants often go off track and end up eating valuable time, often at the expense of not being able to gather important requirement or design information that is critical to the Agile process. Having a disciplined approach to meetings is hugely impactful to TCO. Not only does the customer save money by having less resources tied up in meetings they may not need to be in, but we can establish a clear and delineated process for requirement facilitation that lead to definitive customer ownership. This can cut down on ancillary requirements and give the project team a clear understanding of the requirement lifecycle.

These two practices are not expensive to implement. The challenge is preparation and going into the project with the right frame of mind and making the executive commitment that the Guidewire project will be done in a way that better leverages your software investment. Guidewire Professional Services is very experienced in having these discussions with our customers, and for those of you about to embark on an implementation, or are struggling in these areas in your current implementation, I encourage you to work with your Services Director to discuss how we can help. I am very confident that we can lower the overall cost of ownership on your implementation together.