Today I’m talking about two different kinds of Process. On the surface they’re very different, but both kinds exist to support you and protect you. They’re also similar because some people regard them as threats or compromises.
Wow. I haven’t been this grumpy about business in years.
It all started a few weeks ago when a mutual friend introduced me (virtually) to this fellow I’ll call Ben. Ben had a Project That Sucked. As you know, Projects can Suck in infinite different ways, and this one was considerably less sucky than most. Mainly, Ben’s client had been expecting a new commercial website that was a bit late already, and Ben’s PHP guy had just left for a cool new job out of town. And there wasn’t really that much to do to finish the site.
Ben got in touch with me about this just about a week ago.
It was one of those classic “90% done” issues. Seen it a thousand times. Shouldn’t be that hard. read more…
Last night I had the pleasure of hearing Jon Stahl’s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.
It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.
I’ve been thinking a lot about Victoria Brouhard’s recent blog post on “no-brainer” decisions. It’s a clever idea. When you’re trying to decide about accepting something like a job offer, ask yourself, “What would it take for me to say hell yeah?”
In other words, how would you change the offer–if you had the power–so it becomes something you couldn’t imagine rejecting?
read more…
I was quite interested in Peter DeYoe’s recent blog post comparing Agile development to the P90X fitness program he just started. Riffing off the slogan “Decide, Commit, and Succeed,” DeYoe winds up with
Decide if Agile is right for your organization. Commit to the principles of Agile and deny your urge to fall back on old habits. And if you make it to the third or fourth sprint, a new, healthier paradigm for software development fitness will emerge and lead you to Success.
I like it! But I have a different model for Agile adoption, which is highly influenced by the life example of my darling Drsweetie.
Melinda Emerson asked a good–albeit fairly obvious–question on Twitter just now.
I am working on an article about the 100 Biggest mistakes in smallbiz and how to avoid them. Does anyone have advice to share?
Jason Cohen guest-posted in December 2009 on the great blog On Startups, disputing the startup cliche that it’s always good to release your product early. He makes a good case to the contrary, although like some commenters I don’t think the iPod is a fantastic counterexample. (I mean come on. It’s Apple. They can get away with wild new design ideas, it’s what they do.)
My attention was grabbed by one of the comments in particular, from Trevor Lohrbeer. He says, in part:
Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at).
Which, it should not surprise you to know, reminds me of a story.
It’s Friday, which is usually my day for the big-picture, deep-thinking, philosophically confusing kind of blog post. This time, however, I’m going totally commercial.
I’m excited about this!
A couple of very different items that I’ve been working on for a long time have finally reached a state of substantial completion. I’m ready to get them into a market-friendly state that will enable me to help more people, in a very sustainable way that everyone can afford.
The first thing
The first thing is a Windows application that was custom-made for a local nonprofit organization. They’ve implemented a very successful environmental health program (one of many) that works with families to identify home health and safety hazards, remediate those hazards in a cost-effective manner, and educate the family on ways to maintain the healthy state of the home. There’s a lot of “workflow” involved, and the reporting issues are fairly intense because of federal grant requirements, and it’s further complicated by the need to support an offline distributed database because the inspector with his Tablet PC doesn’t have remote access in the field.
The new application has been in a solidly usable beta state for about six months. Now we’re calling 1.0 done!
![[main dialog for Healthy Homes application]](http://criticalresults.files.wordpress.com/2010/01/main00.png?w=300 "HHDBMain")
The main screen looks kind of like this.
The next step
So consider this a pre-release announcement. If you’re working with HUD Healthy Homes or any similar program, and manual recordkeeping is making your quarterly reports a nightmare, or if you just want a better way to schedule all those inspections and followups… we should totally talk. Get in touch with me now and we can arrange a preview.
The other thing
The other thing, which I’ve been talking about on Twitter a lot recently, is my new Startup Booster series for entrepreneurs whose software projects do not yet suck, but might! If you’re starting a company, and particularly if it’s not a software company, the last thing you want is a software project that costs too much, takes forever, and doesn’t solve the problem you had in the first place.
Isn’t it hard enough to get your idea off the ground? The software part of your strategic plan has to help, not get in the way. That’s why I’m building the Startup Booster. It’s a series of super-accessible information products that show you a really clear path to making stuff work even if you aren’t a software person yourself.
Right now, I’m putting the finishing touches on the first module, Buy or Build? It addresses the first and most important question that a lot of entrepreneurs miss: “Do I need to do a software project at all?” In it, I show you a really simple and thorough eight-step process (with a flowchart!) to help you decide whether to buy an existing package, get set to develop something custom, or skip the whole thing.
That’s the perfect implementation of my favorite rule of thumb: the only bug-free program is the one you don’t have to create to begin with.
Here’s what you get
The first module, Buy or Build? delivers a PDF and an MP3. The PDF includes an overview of the whole process, the aforementioned flowchart, and a super-simple workbook that you can write in as you go along. The MP3 is half an hour of my soothing voice, giving you background on the buy/build decision and explaining all the steps with real examples and a few bigger insights.
Here’s when you get it
At this moment, Buy or Build? is in preview. You can buy it at a special discount price of $17 if you’re on my free keep-in-touch eZine list. Otherwise, you have to wait until next Wednesday to join in the fun.
Of course if you now buy the preview, which is honestly kind of rough around the edges, you’ll get the tidied-up finished version for free next Wednesday. Like duh.
The rest of the series
But wait! There’s more! Future Startup Booster installments will help with topics like these. (Not all will be separate modules though.)
- Can you do the software project yourself? Is that so crazy?
- Figuring out what kind of help you need… how to get it… how to manage it… and when to fire people.
- Is Open Source or Free Software right for you?
- Deciding on a platform (e.g. Mac OS X, Windows, Web) and tool set.
- How to know when your contractor is snowing you.
- Protocols for problem-solving.
- Measuring return on investment.
- Can you turn your project investment into a profitable product of its own?
- When to upgrade.
I haven’t worked out all the pricing, but each module will be pretty similar to the first in terms of content and bulk: a half hour of audio, a workbook, an overview, and a visual aid. There will be a really good no-regrets bundle price if you decide to get the whole series. (By “no regrets” I mean the bundle price is discounted by what you’ve already paid for individual modules, so you won’t have to go “Dang! I should have waited for the bundle!”)
Next up:
I’ve already started on the installment that addresses getting help with your custom software project. I’m hoping to get that preview out to friends as early as next Monday and releasing it to the public in mid-February. This is an ongoing process, with new content at least every month or so.
So there you go.
You can get on the keep-in-touch list right now and order the preview of Buy or Build? at a pretty cheap price with the free update, or you can hang around until Wednesday and pay a bit more for the flowered-up product.
Up to you though. I really hope you decide to check this stuff out, because if you’re trying to get a startup going this stuff can really cut out a lot of the cost, hassle, and stress of software projects gone bad–and so much more affordably than figuring it out with a consultant!
I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.
Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)
On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.
