How to Deal With Troublesome Software Development Projects

How to Deal With Troublesome Software Development Projects

I have debated the title for some time.

You can swap out “troublesome” for “bad,” “crappy,” or “complicated.” And I’d say most developers would swap out “software projects” for clients.

But I think both would do one’s company a disservice. As the gatekeepers of online marketing and software projects, it’s our responsibility to “deal with troublesome web projects” to communicate effectively, and (hopefully) provide our clients a great end result (the programming, marketing, etc) AND a great experience along the way.

But this is a way more complicated task than the last sentence you just read.

Today I’ve been struggling with a client situation we’ve been dealing with for some time. I know what would make the client happy. But it’s at odds with our employees, our company/culture, our finances (yuck!), and our responsibilities and commitments to other clients. In a nutshell, we’ve presented something a client doesn’t like or feels isn’t yet up to par with their initial (and ongoing) expectations. As such, they’d like us to continue to work on the project until some magical time in the future where they’re happy – and we’re out of business.

Recently, in a meeting, I was asked this by a client: 

“Typically, when I pay for something, it’s a set fee. I know what I’m getting for a certain amount. I hired a painter to come to my home to paint some walls. He comes, provides an estimate – I pay the entire thing, and I get my walls painted. Why is that not the case here? I’ve paid a lot of money, and I don’t have what I expected… why?”

To which my response was this: 

Unlike conventional services, software development (in particular!) carries a lot of unknowns (known unknowns & unknown unknowns). We live in a world where (mostly) goods or services are priced out (before or after the fact) using knowns (costs of goods sold, materials, labor, etc.). As a software development company grows, adds resources, and more than anything, becomes more experienced, pricing this way becomes more acceptable (even on websites or software). But, on some projects – indeed many projects, that’s just not the case… using the above analogy I expressed:

Building a custom piece of software (database, web application, etc.) in a scenario like the painter example makes sense. But it would be like Atilus (or any development company) comes to your house day-1 to provide a quote – we see 5 walls that need painting, a color is selected, and a price agreed. 

But on day 2, we get to the house, and we notice the doors are locked to the house. Day-2, we cannot even get through the front gates of the community, and the owner hasn’t allowed us a guest pass to enter. And on day-3 we finally get inside, only to find that 3 of the original walls were knocked down and 10 different walls were put up. Finally, once the walls are painted, there’s a debate on whether or not that’s really the color that was selected, as the final color doesn’t look as good live on the walls as it did on the little sample. 

The problem with software and web projects is that there are SO many factors outside of the end-developers’ control. Here’s just a small list of the top problems we see:

• Availability of Key Players – If the correct people aren’t available to help move a project through its stages, a project can’t proceed forward. If key information isn’t provided
• Key information – If the information isn’t provided in a timely manner, the same problem occurs in the scenario above. A great development company will push through this (either by pushing the company, or by pushing past any speed bumps through to next steps if possible), although doing so requires time (analyzing what’s to be done, what can be done – with limited info, and what shouldn’t be done – because it would have to be REDONE) and experience.
• Accurate information – If the information a client provides to us (or any developer) isn’t accurate, this can cause a host of issues, both immediately (say a failed login) or indirectly (when data/requirements are being reviewed many steps down the line)
• Additions/Changes – The bane of all software projects, scope creep (additions, changes, etc.), this happens on every project, and must be reigned in at every turn.
• 3rd party issues – This is a massive bucket. On any given project, we might rely on 10+ outside 3rd parties. These aren’t contractors, but instead are online services, web applications, API’s, etc. that all must work to bring the project together. A kink or fault in any (completely outside of your developers’ control) can cause a cascade of issues. Most recently, a small bug in Constant Contact’s integration with Google Analytics led to the link not working on a client’s email, which meant lost revenue from an email marketing push/campaign.

How to Deal With Troublesome Web Projects

The short answer is, I’m not entirely sure. Part of me would love to pretend like we have a sure-fire action plan for every scenario, but I think we understand the world doesn’t work that way…

Makes me think of the quote: want to make god laugh? Tell him your plans

Atilus tries to handle every scenario like what I’m about to outline, but every scenario is a little different (see the above 4 unknowns). It’s our goal to “do right” in every communication and relationship. Oftentimes, that means knowing when to be lenient, when to go above and beyond, but it also means (and I still struggle with this) learning when to say no.

Here’s how we break down (and how to avoid) troublesome web projects:

Initial Communication

Preventing problems starts the moment you shake someone’s hand. You cannot misrepresent yourself or your company, and it’s absolutely crucial in this business. Communication starts during your initial introductions, and carries through any sales negotiations and through any contract language. Both parties should know and understand what’s about to happen, who they’re getting involved with, the resources of their company, etc.

Communication also means relaying when you’ll be getting back to someone, if you consider their requests reasonable, and in some cases – learning how and when to disagree with a client in order to manage their expectations.

Be Upfront About Pricing

On every project but the smallest ones (where we know all of the unknowns) we structure ourselves hourly. This is both to protect us and to protect our clients. In either case, we make sure to relay our pricing directly to our clients during direct communications and during contract negotiations.

Ongoing Communication

Continually communicate at every turn about EVERYTHING, including unknowns. This includes documenting and relaying what was discussed at meetings (and of course, actually executing), but perhaps more importantly (and uncomfortably) relaying issues at the first sign of any problems.

That’s it – it’s all communication. Sure, this presupposes that you’re working with an honest web development company, has developers on staff, and is technically proficient – but we’re Atilus 🙂 Of course, that’s already taken care of…

Finally, if you’ve done all of the above and there continues to be arguing, disagreement, confusion, or issues, and that has been balanced against what was expressed, discussed, and agreed upon, and for the future business ramifications on both ends, it may be best to cut ties with the client or development company you’ve hired.