In this era of economic insecurity, with talks of recession on every news channel, job security is hard to come by. That is, unless you are a developer at a growing e-commerce company. Job security: solid. Relaxing schedule: non-existent. With a list of projects longer than Paris Hilton’s rap sheet, I’ve got worked lined up from now till Web 3.0 finally comes around. And while it is good to sit on top of the list of PlumberSurplus.com’s most wanted list, wandering around the office like a plate of bacon at a Weight Watcher’s convention, it isn’t all bon-bons and champagne.
A Wanted Man
As the Development Manager at an e-Commerce company where most of the business is run on custom built software, I am constantly inundated with requests for new features, changes, and even completely new systems. These requests come from all departments, and many are very valid requests. Executive management needs a custom tool to track financial adjustments. Marketing needs a new feed for a shopping engine. Customer service needs a way to track order notes. Some are quick, small projects. Some would take months to develop. Prioritizing, scheduling, and developing these solutions in an effective manner is crucial to the success of any growing organization.
Sometimes these requests are just not realistic. They may affect a very small number of users, and their value may be too low to ever move up on the priority list. And while I don’t like to be the bad guy, sometimes I have to say “I’m sorry, this just isn’t important enough”.
The Development Dilemma
However, many times these requests are valid, good ideas. So how do I go about this process of evaluating and prioritizing development requests? In a word: Bribes. For example, when our marketing team leader Vanessa needed something done, she dropped off her request with a gift card to Pick-Up Stix, my favorite lunch joint, and diet destroyer. Her project got done that afternoon.
After all bribes are factored in, I have to make some hard decisions. I really can’t satisfy every need, and this is tough on everyone. Sometimes people are left not getting their pet project done, and I’m left feeling like the bad guy. And the projects that do get worked on sometimes get rushed out so we can move on to the next project, without giving due diligence to the full optimization and enhancements that could have gone into it were time not a factor. It’s the same principal as a mechanic who has more cars than he can service; they all get pushed back and delayed, and the ones that get fixed sometimes get the bare minimum to get it working and out the door, with no time to check the radiator fluid.
The Evaluation Process
When I am prioritizing projects, I look at several key factors:
- Revenue – projects that are going to create sales and generate revenue get top priority.
- Cost Savings – saving the company money is almost as good as bringing in more money
- Efficiency – Does this significantly make an impact on efficiency? Is this something that will automate a process and free up man-hours?
- Enhanced Customer Experience – Is this going to help in customer satisfaction? Will customers be more informed and satisfied with their experience?
- Benefit Scope - How far reaching are the benefits? Will it help many users, or just a few select users?
- Resource to Benefit Ratio – is the end goal worth the development efforts?
- If it takes 4 hours of development to save someone 20 hours a week, it has a good ratio.
- If it takes 20 hours of development to save someone 4 hours a month, well, those are called “government jobs”.
These factors, based on our business needs, are the guidelines I use to evaluate and prioritize development projects. However, they are not firm. Executive requests seem to get higher priority for some reason. So do bug fixes or anything perceived as a barrier to customer satisfaction and conversions.
Often I will work on a larger project, then when I finish I will dive into a bunch of smaller ones that may not be the next on the priority list, but are valuable and can get done quickly. If at all possible, I don’t like to make requests wait for too long if they can be done relatively quickly.
Sometimes projects get whittled down, broken into segments, and those segments get prioritized. For example, when we wanted to start using Google Checkout, our end goal was Level 2 full integration, where we pass information back and forth to Google in an automated fashion. However, we wanted to get in early since Google was running their $10 off $30 program, and that project would have taken longer than we wanted. So we broke it up into stages, where we implemented Level 1 integration and allowed customers to check out with Google Checkout, then later on upgraded to our current Level 2 integration.
As you can see, there is a lot that goes into deciding what projects get worked on and when. So go easy on your development team; we aren’t just playing Second Life all day. And remember – a Starbucks Caramel Macchiato goes a long way, if you catch my drift ;)