Why Projects Succeed: Customer Involvement

Why Projects Succeed: Customer Involvement
By Roger Kastner

Note: This article is part of a series, the previous article in this series can be found here.

“Meet the new boss, same as the old boss!“ – from The Who’s “Won’t Get Fooled Again”

You can’t have project success unless your customers adopt and use the product of the project. Seems simple right? Even if you achieve all the other project objectives, a project cannot be deemed a success if no one uses the end product of the project. By developing products without involving customers to articulate the need and the value a product can produce, you run a significant risk of developing a product that fails to deliver something of value to the customer.

This time, let’s discuss some ideas on how to get customers involved that will improve your odds of project success.

Involvement

So how should we get customers involved, and at which parts of the project?

End users and customers are great at articulating the issues and problems with current tools and processes, and at identifying the value of having the problems solved. The stated needs of end users can be used to prioritize which features of a product get developed first. And end users are perfect for validating acceptance of the product prior to release, because you know they will validate acceptance once it’s released by either using the product or not.

However, before we jump into the deep end of the Customer Pool of Love, there are some limitations to consider. Customers are usually not great at identifying the most feasible or reasonable solutions, because they might identify solutions that address symptoms and not root causes of their problems.

Let me tell you two stories from my past that help speak to proper and improper use of end user involvement, and then we’ll talk about some specific steps to put end customer involvement to work on your project.

Inadequate Involvement

Several years ago I was assigned to a project which was already over a year old. The objective of the project was to develop a significant upgrade to a popular online application with millions of users. The team had done well in soliciting feedback from users about new features. However, the team was also attempting to develop a new platform codebase that could be repurposed for multiple other products within the company. When originally conceived, the team had a “build it and they will come” mentality for the platform, meaning that the team had not solicited the interests of potential internal company customers for the platform. Additionally, the team had not set expectations with Senior Management about the platform, its benefits, or the amount of time necessary to build the features and the platform.

Senior Management, who were very interested in the new features but was growing impatient with the lengthy development timeframe, had assigned me to determine how to get the next version launched by a specific date. In working with the team, we determined the only possible way to hit the mandated launch date was to delay further development on the platform to post-release and focus on finishing the key features that Senior Management wanted.

Here’s where we made matters worse. Due to the time-pressures, we underestimated the amount of time necessary to fully test the stability of the new platform, resulting in a big and very public mistake.

We did hit the launch date and the application was “technically” feature complete, but it had significant performance issues related to the half-baked platform, resulting in many users uninstalling and reinstalling the previous version. Additionally, the new version was panned by the critics, largely because it lacked a stable codebase that would allow users to fully experience the “coolness” and utility of the new features.

If the team had worked with internal customers at the beginning of the project to determine if there was demand for an extensible platform, the team could have set expectations with Senior Management on a reasonable timeframe for developing the platform, enabling an informed decision on feature vs. codebase timelines. Instead, a lot of time and money was wasted, and the reputation of the product and the project team suffered greatly.

Effective Involvement

More recently I was working on an internal reporting tool project where the project team had extensively interviewed end users to understand current limitations of their reporting systems. End users went through a painful and time-consuming process every month to manually compile and reconcile performance metrics.

The project team started to focus on addressing the biggest pain points for the end users by creating tools that automatically performed the monthly compilation and generated a report on reconciliation numbers. End users reviewed prototypes and their feedback was incorporated before the tools were coded, saving rework. Lastly, key opinion-makers within the user community were involved in the testing phase of the project, which gave them a behind the scenes view of the product. This preview acted not only as a measure to ensure correctness, but it gave key influencers the opportunity to get excited about the product and begin to act as evangelists for the new product with their peers.

The outcome of the project was a huge success and the user adoption rate exceeded expectations.

Key Steps to Benefiting from Customer Involvement

Articulating Project Objectives – End users can help you articulate the issues and problems with current tools and processes, and the value of having the problems solved. This information should be collected via interviewing. These interviews can also capture Use Cases, which are documents that outline the key user steps in performing processes with the product. Use Cases can be used as the basis for product requirements, test cases, and acceptance testing.

Prioritization of Product Features – Customers can help prioritize which issues to solve first. Prioritization is something Product Managers and project stakeholders frequently have difficulty performing well. In 2002, The Standish Group published a survey of thousands of software products and found that 64% of the features were “rarely” or “never used.” Wow! Two-thirds of the features that product managers required and project teams toiled over (and most likely were late delivering on and ran over budget on) did not add value. In fact, they took away from value. If we cannot prioritize the features, let’s get our customers to do this for us. Please!

Prototype Reviews – End users can help inform the design phase of the project by reviewing prototypes of the finished product, enabling the incorporation of feedback prior to development, saving time, money, and morale.

User Acceptance Testing – UAT means a group of end users performs specific, predetermined tests that prove the product works as designed prior to the product’s release. Having end users test the product prior to release can save the product from poor adoption if errors are found prior to release, and in the case of one of the above projects, it can create product evangelists who “sell” your product for you.

Limitations of Customer Involvement

Problems, not Solutions – While end users are great at identifying problems and needs, they are rarely good at identifying the most feasible and sensible solutions. Problems are easy, solutions are not.

Problems, not Symptoms – Customers can easily identify problems, however, sometimes those problems are actually symptoms of larger, root cause issues. If the project team doesn’t follow the right steps to ensure they are addressing root causes, their end-products may fall short of solving the right problem.

Doesn’t Solve All My Problems – Upon release, some end users will remark that while the product meets some of their needs, it doesn’t solve all of their problems. That’s OK as long as the product does solve key issues as promised. The issue here might be failing to appropriately set customer expectations. However, if you’ve solved important issues with your product, your customers will allow you the opportunity to solve their other problems afterwards.

Summary

The Customer has the ability to hire and fire you, just like your boss, so why not go directly to the source to determine the right problems to fix? Every project has the goal of (1) delivering solutions to customer problems, and (2) deriving value for your sponsors. There’s not a better way of ensuring these two goals are met than to ask your customers to tell you about their problems.

I would love to hear about your project experience with utilizing end user involvement on your projects and any best practices that you want to share.

Reprinted with permission from Slalom Consulting – © 2011 Slalom Consulting

Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.