Project Momentum – Common Sense Experience

I was recently working with one of the people responsible for a large Guidewire program. Their responsibility included keeping the team on track throughout an implementation project. As part of this work, we (Guidewire) made several recommendations that are intended to maintain momentum and lead to a healthy project assessment. We find that transparent, honest communication in a timely manner helps maintain solid project progress, and I wanted to share some of these general recommendations with you. Even though these comments were made about a specific project, they are applicable to many projects. Keeping a project on track and pointed in the right direction is hard work, and it is part of what we do here at Guidewire on a daily basis.

Success Factor I – Crisp Decision Making

It is crucial for productive teams to assign empowered business representatives to the project. Ideally, these business representatives have the complete trust of the business stakeholders and are aligned with their future state vision. At times, the business representative will need to make decisions that appear to be odd from an external point of view. When the right person is assigned and confident in their responsibility, they will be capable of making decisions and standing behind those decisions. This will limit rework and backtracking when stakeholders review the solution, resulting in a more efficient program and a better experience for all involved.

Success Factor 2 – Clear Communication

Another key area is to make sure that the leaders of the program have constant and clear communication. This goes beyond just sending out frequent updates. The people sending the updates need to have a mindset that each communication is to be concise, consumable, and actionable. Team members tend to receive a lot of information in this “Information Age.” They are constantly bombarded by email on their desktop PCs, when looking at their tablets or at their smartphones. It really helps to keep communications as succinct as possible in order for people to have time to react. I tend to add an “Actions:” section to my email communication as it helps to explicitly state what my expectations are and who I expect to take action, especially when there is more than one recipient on the email. It is also important that key decisions are shared with team members so that everyone can work in the appropriate direction towards successful completion of the project.

Success Factor 3 – Monitor Scope and Prioritize Change Requests

It is very tempting to allow project scope to creep. People don’t add scope because they are trying to create delays in a project. Scope is often added for a variety of reasons including: something was missed and it is needed for the program to succeed, a team member has observed a need within the context of the old process and rather than think through the best answer, they pass it on to the team as ‘needed’ scope, and people observe a change that they want in the future but don’t think through the impact from a prioritization point of view. Basically there has to be a clear triage process for new scope and a prioritization mechanism that ensures that only the most important scope items are allowed to impact the current schedule.

Many teams spend an adequate amount of time planning a project and identifying what is important to the success of the program when they initially organize the project. Team members need to be diligent when changing or veering from the original program. This is not to say that all scope changes are bad. On the contrary, every program will have some scope changes. The key is to ensure that the important and needed scope changes are accepted and that items that can be eliminated or deferred are treated appropriately.

Success Factor 4 - Base Application Adoption

It is essential to make sure that a company that buys a software package maximizes the value of that software package. Many hours of planning and programming go into building the software package, and if you are buying a Guidewire package, it was influenced by our customers located in 16 countries around the world. It’s important to try to understand the underlying reasons for the package design and to get aligned with the context of why the package works the way it does. If a team decides that they have to deviate from the package design, it is crucial that the shift from the package takes into consideration the cost of the shift including the testing cost, the value that the shift will provide, and the longer term package roadmap that may address the scope item being raised. At Guidewire, we are always learning from our customers, and we acknowledge the need to be open to new ways of addressing insurance needs. At the same time, it is important that customers take the time to be informed before deciding that the software package does not meet their business needs.

Success Factor 5 – Measure Project Progress

Guidewire employees recommend an agile project implementation approach to our customers. When we measure progress we are not as interested in measuring hours spent on specific items as we are in measuring story points. We have created hundreds of user stories as part of our methodology. We refine the user story effort points as well as the user story value points when we mobilize a project. This means that both the effort points and value points are applied to specific customer needs for each project. When delivering, we measure completed effort points and completed value points. Our goal is to have more value points than effort points as we progress the release. This means that the items most important to the business case are more likely to be completed and if anything has to be moved out of scope, it will be less important from a value perspective. The discipline to review the value alignment after each sprint helps the steering committee to stay aligned with the delivery team and to influence changes while the delivery team has enough time to adjust and benefit from the adjustment.

I’m pleased to share these success factors that we have learned over the years from the more than 130 successful customer implementations we have worked on. In future posts I’ll go into more detail about our Value Journey approach which outlines how we set value goals, map those goals to specific implementation user stories, and then measure progress as the project moves forward. We also have a framework to measure results after the project goes live. Basically the framework sets a goal, measures progress for achieving that goal, and measures business results once the project is delivering business value. It’s all pretty exciting, so stay tuned.