Friday, August 7, 2015

Some Projects Deserve to Die

A vendor on one of the Salesforce projects I was designing said to me: "Some projects deserve to die."  He wasn't talking about our project, which deployed on time with great features, but I was still shocked.   Why would a project deserve to die?  And how do you know when you are working on one of those so you can help ease it out of existence?  If you think of your in-house projects in terms of investments, you can categorize them:  cash cow, rising star, mouse trap, and dog.

In-house tech projects can be seen as cows too.
The best categories for a project are cash cow and rising star.  Cash cow provides great user experience at low expense with regard to time, and expertise. They offer high return on investment, or ROI, for that reason.  The cow represents everyone's favorite technology, users love that it does what they need and you love it because it doesn't require a lot of upkeep.

The rising star is in-house tech in-the-works and has high needs for time and expertise with low ROI during early design, configuration, and implementation stages because users aren't getting much benefit yet. Even with low or no ROI during this development cycle, the rising star is expected to become a cash cow when it is closer to completion and once users are trained.

The two project categories that need reconsideration are the dog and the mouse trap.

The Mouse Trap 

Then there are the mouse traps.  These projects have a high ROI, but the maintenance costs are also high -- they are like Rube Goldberg inventions in complexity and while they may have gotten the job done as conceived, users are outgrowing them and finding flaws.  These projects deserve to die.  These in-house projects are integral to users, yet too costly to maintain.  And having a project that lives in the high maintenance, high expense side of the quadrant can't be a good thing.

cash cow, mouse trap, rising star, dogOne company asked me for help with their mouse trap.  They had so many custom objects making up a customer survey that they required custom Visualforce pages for reporting and couldn't leverage the flexibility of Salesforce standard reports.  What they could have accomplished with clicks-not-code if a Salesforce administrator had been involved in designing the original solution got bogged down in complexity and code making it completely inflexible -- not a good trait for business solutions.  Code edits were required for any meaningful changes to the reports.

At some point, the money poured into this project had been made good through ROI because the Visualforce reports are so integral to their business, but user needs have changed and the solution doesn't work as well as it should now.  As complaints and change requests rise, so do maintenance costs in time and expertise.  Rather than spend to maintain, in this case, it makes more sense to spend on a redesign to reduce maintenance costs long term.  These mouse traps seem useful, but these are the projects that deserve to die.  Users wish they could do more with the integral tech, but the complexity of it makes expanding functionality just too costly considering time and effort.

The Dog

Your dog may need updating.

For in-house tech, a dog is a product with low maintenance costs that has low ROI. It's the infrequently accessed tech or is used by a small audience, it might even be a quick fix you created to help a single user.  The dog, with its low maintenance and low ROI seems like it has nothing going for it, but in fact these projects can lead to easy wins.  Do they just need to be promoted in house to make the use and value better understood?  Can they be nurtured to grow into a rising star by interviewing users regarding ways to improve what the tool does without a lot of expense?  Some in-house tech just seems to get stuck in phase I, minimum viable product, and needs a nudge to get going in the right direction again.

These dog projects, with low cost and low impact, offer opportunities to explore easy solutions.  I did a creative side project for the Little Bits Olympics recently that didn't make it out of the dog stage.  The project description suggested two hours for the project, so that's what I spent. This time budget limited my choice between using a rare earth magnet attached to a servo to alter its polarity versus an electromagnet that required more effort to hack into my Little Bits electronic circuit.  Because of the time budgeted (like any expense), I chose to test the quick approach and was not completely satisfied with the result.  The ROI was low, the cost was low, it was every bit a dog.  But it did work and gave me great preliminary knowledge for planning phase II which will have an electromagnetic bell type design once I budget the additional time to hack the circuit.

Consider the dogs in your org and look for ways you might be able to teach them new tricks or make them more relevant to users.  And as for the mouse traps, don't get caught by them, a lot of people want to continue to throw resources at outdated solutions to try to convert them to cash cows, but the best approach might to be to let these projects die and start something new to take their place that will offer easy maintenance at low cost relative to time and expertise.

1 comment: