L O A D I N G

One of the things that Phalanx has prided itself on the past 3 years has been our ability to make ice cream out of garbage.  Yes folks,  we have at times referred to it as “we do magic”.  If you’re an agency digital veteran or creative, you have probably crossed over a project here or there that was written by a partner with less than stellar or unmanageable code.  You know the ones,  where the customer calls you on the phone about a new feature and you cringe and your response is, “We’ll look into it and get back to you”.  Projects where the best course of action when a new feature is considered, may just be to scrap all the old code and start over.  Phalanx has had the opportunity in several cases to be the “Fixer” for epically damaged projects.  In this short article we’re going to share some of the process by which we are able to assess a project’s current state and evolve a solution for where it needs to be.

First up,  Discovery. 

To many in the small agency world this is a dirty word.  The customer usually won’t pay for it, the AE doesn’t even want to bring it up, but it’s the path to successfully reviving a damaged project.  It’s like the defibrillator for a dying heart patient,  hurts like hell but they live.  Consider it the price you pay for poor process, bad partners or just lack of knowledge when it comes to how the project was built.  Discovery in many cases is a block of hours where developers from the new team get under the hood with full server and source access and kick the tires.  These hours are by no means a money pit.  They help gain a full understanding of the underpinnings for what’s been built.  What logic is there?  How was the UI built? What’s the backoffice look like? Performance testing and where can improvement be made?  Paying for Discovery will often confirm if the future features in question can even be accomplished and how heavy a lift that will be.  Better to do it and inform the customer something they want to do can’t be accomplished, then say it can and throw hours at it only to find out later it can’t.  Any partner that feels comfortable just floating a number out to you without discovery isn’t being a good partner and is setting you up for additional hours potential down the road and missed deliverable dates.

Whats next… feature specification. 

Now that we know what the foundation of the application looks like, we can define the spec for the new features or functionality to be delivered based on it.  Can it be done? What’s the roadmap for building out this new feature?  Here we define how the feature will be managed, if it will be managed, what backoffice needs there might be, and what UX/UI requirements there are.  So if we’re adding a location search to a website for instance,  that allows users to do a search with a map view and find all of the businesses locations within “X” miles,  we define that specification based on the system in place.  This is where we will also indicate what changes may need to be made to the current system to accommodate the feature as well as performance improvements if any needed.  So we may need to use a mapping API in the example like Google Maps, and tie it into a admin interface in the CMS to allow the customer to add in new locations as they come online.  We’ll need to define the filters in the system for the data based on how the customer wants to query the data.  By miles away from current location, by zip code, by landmarks etc.  This phase lays the groundwork for the estimate and timeline for the project.

Finally…what’s the cost and time needed? 

Now that we have a specification for the work to be done, based on the system in place, it’s time to tell the customer the price and timeline it.  This price will take into account all necessary modifications to the system’s current state to accommodate the new feature,  all new code to be written to deliver the new architecture, any integration points and new UI.  So in our example,  if we need to rewrite how the current site search works to implement search with the various filters required, and cache data to improve performance and then implement Google Maps API with custom markers and controls we lay that all out. All necessary time for the project cleanup and build are factored and a cost is applied.  If “Discovery” was skipped at this point the project is padded significantly to assure we have enough time in the event that we find a complete mess of spaghetti code when we get started.  Again a good reason to allocate hours to Discovery, so that you don’t wind up paying for more hours than you need honestly.  So in this final step we provide the deliverable timeline and costs to the partner to then sell through to their client which can be the hardest step of them all.

So how do you sell through a feature build with discovery and fixes for a project your team originally conceived and built that is flawed? 

This is the big one.  Many times it involves transparency and “biting the bullet”, owning the mistakes of the past in hopes of delivering a much better solution in the future.  Keeping the customer.  Maybe it involves sharing some of the process issues with the previous partners with the client.  Maybe there were communications failures,  timelines getting truncated and the project getting band aided together in less time than it should have had.  Maybe it was a level of trust you should not have had with your previous developer or partner.  You let them drive the technology choices and they shouldn’t have had the keys.  Regardless this is the toughest pill to swallow.  Usually we suggest to the agency partner to own some of the cost on their end to blunt the blow in addition to transparency.  Showing the client you are as invested in the final outcome as they are can go miles to approval.  But in the end it all hinges on the client relationship, how contentious it may have gotten and gut feeling by the account team on what the client will get behind.

Phalanx has built entire customer relationships on cleaning up other developers damaged efforts.  Whether it was an offshore development team who are notorious for bad code and even worse process,  or freelancers who were brought in and got in way over their head.  We step in, right the ship and get it to a place where future success and even more business opportunities present themselves to both the agency partner and client. So don’t ever consider a project or client dead before you find a partner who can perform CPR.

  • 545
  • Tuesday December 20, 2016