Got 60 seconds to learn the real value of custom software? Check out the video to learn more.

Burned

“I’ve Been Burned Before” My daughter’s first musical theatre gig was at age five, playing a sugar cube alongside talented kids of all ages in…

“I’ve Been Burned Before”

My daughter’s first musical theatre gig was at age five, playing a sugar cube alongside talented kids of all ages in a production of “Beauty and the Beast.” One scene that particularly stood out for me was when the servant-turned-candlestick, Lumière, puts the moves on the maid-turned-feather duster. At first, she is seduced by his charms, but then she jumps up and cries, “I have been burned before!” Poor Lumière, despite his clear affection for her, cannot deny that she has a valid point.

Like Featherduster (yes, that’s the best Disney could do for the character’s name), many clients who come to us have been burned before – they can’t ignore bad experiences they have had with prior developers. The stories vary, but the central theme remains the same: much money spent, inadequate final product. Sometimes the developer has tried to reach a mutually beneficial resolution with the client, but ultimately lacked the skills to deliver. Other times, the developer went missing before the project could even be delivered. Cost overruns or missed deadlines without any explanation, poor communication, software that doesn’t do what it should – all of these are the hallmarks of a consultant who ended up in over his or her head.

Clients who have been “burned before” fall into two types: those burned by the big providers, and those burned by the “lone wolf,” one-person shops.

One-Person Flameout

On even the best days, designing good custom apps is hard. Most consultants recognize this, and feel ready to meet the challenge. But being able to write software does not automatically equip them for the rigors of working with a client, meeting deadlines, staying on budget, providing training, and all of the other myriad details of project management. In fact, these are the things a developer most likely does not relish doing at all. The personality type that is good at writing code all day alone is, unsurprisingly, not always the type that communicates well. Poor communication leads to a host of problems that can compound one another, until trust has eroded beyond the point of no return.

Big Provider Smokescreen

Working with a large, nationwide development shop is a different thing altogether. Presumably, many of the hurdles of the small, lone-wolf shop have been overcome. But new problems might arise, where rapid turnaround time and high production volume start to take precedence over delivering the kind of personalized attention the client needs. Sometimes, the aforementioned problem of the lone wolf compounds this, because the developer is actually an independent contractor charged with delivering the project from start to finish.

I want to point out that neither of the above scenarios holds true for all lone wolf or large shop operations, and I am in no way trying to dissuade you, a potential client looking to invest in custom software, from using them. I was a lone-wolf developer for many years, and I expanded my skill set to include everything I needed to build a larger and very successful consultancy. I’ve seen what good custom software development looks like, and much of it has come from operations such as these, as well as my own.

Fire Insurance

That said, if you are reading this, there is a chance that you are among those unfortunate software clients who are still healing after being burned. If that describes you, I have good news for you: it doesn’t have to be that way. Here are some things you can do to protect yourself from going through the same experience again.

Be upfront: as you shop around for a new developer to provide you with the great custom software you need, describe what you experienced previously. No need to name names, but you should be willing to discuss where things went wrong – what parts were difficult, what bothered you about the experience, where the red flags popped up, what ultimately made you give up on your relationship with the developer. This will not only help you gain understanding yourself, but it will also help the new prospect understand what you need in order to be successful. An experienced consultant can listen carefully and come up with a strategy to meet your particular needs.

Be willing to adjust your expectations: Every consultant works differently. Some will emphasize a traditional “waterfall” approach, where a complete set of requirements are gathered and used to build a subsequent, complete app. Others might propose a more modern, “agile” method where small, incremental phases of the software rolled out almost from the beginning of the project. Our favorite is a hybrid of these… the point is, how you worked before is not necessarily how you will end up doing it on the second go around. You may also be thinking that the new consultant you hire will be able to pick up where the last one left off. Don’t be surprised if this is not the case – sometimes it can actually be less costly to start over from scratch. This may sound counterintuitive, but analyzing unfamiliar code and testing its soundness as a foundation for new work takes a lot of time.

Ask the right questions: This is the most important part, and I saved it for last so it won’t get lost in the shuffle. The reason it is so important is that it speaks to the aforementioned expectations. The number one way that I have seen other peoples’ projects go off the rails is by not having a clear set of expectations to begin with. This goes for the developer and the client both. You should not be shy about asking about at least some of the following:

  • How much time and energy goes into gathering requirements before development starts? (beware anything that feels too minimal!)
  • Who will be building my software?
  • How much oversight can I expect from the CEO and others in charge?
  • How is the cost of the software estimated? (hourly vs. value-based)
  • Is the estimate a “hard” quote or an estimate that is subject to change? (typically estimate only)
  • How will change requests and scope changes be handled? (phone call vs. formal sign-off for each one)
  • What constitute a change request? (ask for sample scenarios)
  • Do you include data migration in your estimate? (not every consultant does)
  • What will be expected of me? (training setup in house? communication? testing of software?)

At Alchemy Consulting, we have “salvaged” many projects, restoring confidence in the process and providing our clients with excellent software that really meets their needs. We pride ourselves on great communication and truly understanding how businesses operate.  If you have been burned before, pick up the phone and give us a call. We will restore your faith in custom software development. No song and dance necessary.

Latest

From the blog

The latest industry news, interviews, technologies, and resources.