How to Deal With Troublesome Software Projects

I have debated the title for sometime.

You can swap out “troublesome” for “bad,” “crappy,” “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 gate keepers 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 sometime. I know what would make the client happy. But, it’s at odds with our employees, our company/culture, our finances (yuck!), and with our responsibility 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 hire 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: 

lifeUnlike 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, 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 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 it’s stages a project can’t proceed forward. If key information isn’t provided
  • Key information – If the information isn’t provided timely, same problem to 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 link not working on a clients’ 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 above 4 unknowns). It’s our goal to “do right” in every communication and relationship. Often times 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 mis-represent 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 sign of any problems.

That’s it – it’s all communication. Sure, this pre-supposes that you’re working with a development company that is honest, 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 best be to cut ties with the client or development company you’ve hired.

Zach Katkin
Zach Katkin
Zach Katkin is the co-founder & CEO of Atilus. He is a Certified Google Professional, author, and lover of technology. He helps Atilus stay out ahead of online marketing trends and loves driving results for Atilus' clients.

Leave a Comment

 

Recent Comments | 0 Comments
Recent Posts

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.