Technology vs. Best Choice – Who Wins the Project Solution Decision?

New technology is very enticing and sometimes your customer really wants it … bad.  Their desire can even push the entire project to center around it. And it’s hard to go a different route because it can draw you in too – new technology is exciting and fun to play with. Sometimes the customer even has the money to back up their passion for acquiring the new technology. But… I’m telling you – resist at all costs!

Hmm... Shall I choose Technology with my Heart or my Brain? (FastTrack Schedule)

We all know deep down that new, fresh bleeding-edge technology should not drive the solution. Never ever, ever. It may be a solution, but there’s work to be done first to get there. Follow the process, push back on the persistent customer who knows exactly what he wants and how he wants it done. Take a deep breath and simply, yet politely, tell the customer … no.

Why? You would think that a customer who has money, has a need, and knows the solution is an easy customer. All we have to do is do as he says, cash the check, and move on to the next project – everybody’s happy, right? Not always … and not likely.

The problem with this scenario is that the customer often doesn’t really know what they want. What they know is that they have a need. The customer needs help cultivating the information from that need into a solution that will fit or solve that need. That’s where you – and your team – come in. Being a ‘yes’ man for the customer won’t do them any favors and will more often than not leaving them with a final solution that doesn’t meet their needs. If the customer’s end users are frustrated, the customer will be frustrated. And customer frustration = customer dissatisfaction.

The Process for Finding the Best Choice Solution

In order to best ensure that you’re going to be providing the customer with the actual solution that their need requires, you’ll need to follow a process similar to the following:

1. Have the customer map out business processes.

Mapping out their own business processes is something that is very helpful for the customer to do, but they’ll often overlook this activity unless you specifically require it. It’s really a good idea to require that they go through this activity before you ever even sit down with them. If the customer goes to their end users and subject matter experts (SMEs) and gets business processes mapped out with them, then there’s a real good chance that they’ll have the best possible view of their real need going into requirements definition on their own or with you.

2. Review or create high-level requirements with the customer.

Ideally, the customer would do this on their own, but what’s ideal and what the customer actually does aren’t the same thing. So, assuming that you and your team have to at least ‘help’ the customer map out their high-level requirements, at least you’ll have their business processes in place from the previous step to really help you understand what their need is.

3. Create detailed requirements with the customer.

Next, drill down with the customer further into the requirements. It’s best at this time to also categorize and prioritize requirements. The key is to capture more requirements detail at this point.

It’s inevitable that there will be three general categories of requirements: must-haves (the #1s), should-haves (the #2s), and nice-to-haves (the #3s). Prioritizing now will help you later if and when the scope or schedule changes affect the project and you have to get functionality up and running by a specific date leaving the rest for a later phase of the implementation. Then, you’ll be able to focus on first getting all the #1 requirements met, if necessary, and push 2’s and 3’s to a later phase, rather than watching the entire project crash, or go over budget and time.

4. Propose a solution.

Unless it’s already obvious, now is the more likely time to actually propose the technology for the solution. Up to this point we’ve been examining the current processes and need and detailing the requirements. Now, based on all of that information we can propose or confirm the right solution to meet those needs. Now is when the real work of utilizing the proposed solution to meet the requirements of the project can start to happen.

Summary / Call for Input

Many times the customer comes into the engagement “knowing” what they want for the technology solution. However, don’t be tricked into going down that path with them. Remember, you have the team of experts that they came to for the solution. You’re the leader – lead them down the path to the right solution. Don’t let the customer dictate the solution to you and your team.

Readers – Have you found yourself in this scenario? What did you do to modify the client’s expectations? Please share and discuss.

Brad Egeland
Brad Egeland

Noteworthy accomplishments:
*20 year provider of successful technical project management leadership for clients across nearly every industry imaginable
*Author of more than 4,000 expert professional project management and business strategy articles, eBooks and videos over the past decade
*Articles/professional content receives over 40,000 page views monthly
*Named #1 in the 100 Most Inspiring People in Project Management
*Named a Top 10 Project Management Influencer to Follow in 2016
*The most read author of expert project management content on Project Times/BA Times for 2015
*Named most prolific provider of project management content over the past 5 years
*Noted for successful project management and financial oversight for $50 million Dept. of Education financial contract/program
*Chosen by the Dept of Defense as a subject matter expert (SME) to help select IWMS software provider for the largest IWMS implementation ever awarded

Articles: 179