…for non-software people by Mark W. Schumann, Critical Results
I’ve been making software projects not suck for something like two decades, and it finally occurred to me that it might be helpful to show people how to make their projects not suck before they have to come to me to have them unsuckified. Because that would totally be a public service and all.
I’m working on a book deal, and there will be a feature film, and my people are talking to Jodie Foster’s people about it, but for right now… let me share with you, for absolutely free, the three top things you really need to know for your software project to not suck… even if you aren’t a software person. Especially if that.
This is for you if your business is something like marketing, coaching, consulting, healing, delivery, manufacturing, distribution, retail, operations, whatever. And if you have some kind of tech thing in mind that’s supposed to make your business awesome: like a planning tool, an ordering system, some kind of customer support interface, something to control machines and make operations go smoother.
If you’re in I.T. or software development yourself, this is probably not so much for you. I hope you already know all this stuff.
So basically I’m saying you need to know these things if software isn’t your bag, but you still think you need some kind of software thing done. My Startup Booster series walks you through this process, without inundating you with unnecessary detail, but let me share with you right now three really basic principles.
First Thing: Know what problem you’re trying to solve.
The most software projects go wrong, in my experience, when you’re not clear–really really clear–on why the project even exists. If you don’t know where you’re going, you could end up all kinds of places, but most of them are a waste of time and money. One of the first things I ask in my Buy or Build Workbook is (slightly condensed): “Imagine your ideal customer–what does that person need from you, and what can you deliver?” But right after that I ask you to “Figure out how your software project helps to solve the customer’s problem.”
Bluntly, here’s what I’m suggesting. If you can’t summarize how the project helps you make sales or deliver value to your customers, it’s probably not important enough to take up your resources, at least not while you still consider yourself to be a small business.
A new software application to increase the number of orders you can process on your website? Definitely. One that pings your couriers so those legal documents you get paid to deliver are trackable by the customer in real time? Sure. A big new program to optimize your cubicle layout? No. Being in small business means you have to cut out the extras.
Key: If the project doesn’t make a difference to your business, there is actually no way to succeed.
Second Thing: The ends kind of do justify the means.
Gosh, doesn’t that sound awful? I don’t think so. What if your ends didn’t justify your means? In other words, what if the objectives of your software project aren’t important enough to be worth the effort and inputs?
Sometimes it’s difficult to get a handle on your Return On Investment (ROI) figure. When doing a software project, you can probably pin down about how much it costs–at least in retrospect!–but putting the benefits or returns in dollar terms may not be obvious. Try to do it anyway.
For example, you might mess around with Excel and get a spreadsheet like this:
|
A. Current sale count per day |
1000 |
|
B. Number of sales during peak hours, per day |
100 |
|
C. Estimated sales lost per day due to undercapacity (customer abandons order) |
20 |
|
D. Average lost sale, assuming similar to average of all |
$98.17 |
|
E. Average expenses and cost of goods per sale, ditto |
$74.07 |
|
F. Average profit per lost sale (D – E) |
$24.10 |
|
G. Estimated profit per day lost due to undercapacity in order processing (F x C) |
$482.00 |
|
H. Order days in two-year payback period (52 x 5 x 2) |
520 |
|
I. Payback over two years (G x H) |
$250,640.00 |
The spreadsheet is full of assumptions here but that’s fine. You’re making your best effort to work out what this software project, assuming it goes well, will deliver for you. In money.
If the software project (or in fact any project) is going to cost more than Line I, or even close to it, just skip it. Or cut back on the costs somehow. This is where sharp application of the 80/20 Rule comes in very handy.
Key: Resize the project if it’s not cost-effective as you first visualized it.
Third Thing: Don’t be an idiot about it.
Another pitfall I see a lot is sticking with a technical approach that sounded good at the beginning but turns out to be a lot more complicated than it seemed. If you find that cool new ordering system has taken 50% longer than expected, and you still can’t see much more than a couple of menus and some pretty icons, start asking questions. Maybe your programmers are getting sucked into an overly complex design that slows them down, and a different approach–perhaps a less technically elegant one–might serve your purposes just as well.
Managing contractors, wow, that’s a whole nother subject in itself, if that’s what you’re working with. But in short, you want to encourage the Agile principle of Doing The Simplest Thing That Could Possibly Work without pushing them to do slipshod work. The bad news is that it’s really hard for a non-software person to spot the difference!
Before you even start, strongly consider looking for a development firm that really gets the “Agile” software development concept. Among other things, a true Agile shop prioritizes code that responds to change rather than doggedly following a prearranged plan… if that’s what it takes to make good software. Again, it’s hard for a layperson to pick out the faux Agile shops, and if you’re not a specialist it’s probably best to look for good references that emphasize a flexible approach to reaching business goals.
Key: If you hear wheels spinning, pay attention.
It’s not easy.
Oh dear no, it’s not easy. If you can accomplish your most vital business goals without taking on a software development project, you probably should. But in the alternative, if you follow these three principles you at least stand a fighting chance of getting the right project done at a proportionate cost and in a realistic time.
About the Author: Mark W. Schumann is the creative force at Critical Results, where among other things he guides you through your software project with the Startup Booster series at http://startups.criticalresults.com. You can (and should!) join his easy, fun, and tasty keep-in-touch eZine list at http://criticalresults.com/freestuff.html for information, special offers, and outstanding vegetarian recipes. And check out his blog about making software projects not suck at http://blog.criticalresults.com!
I did it, and it’s great. You can 
