.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Friday, October 28, 2005

If you get 1 thing right in your application, make it the User Interface

Here's a train of thought that further proves to me that a good User Interface can make or break an application.

The thinking goes like this... To be really successful, a great strategy is to do a smaller number of things, but do them noticeably better than the next guy. In other words, don't spread yourself too thin. Nobody ever became fabulously successful by doing a long list of things in a mediocre way. If you want to get noticed, you've got to do something worthy of notice, something that most other people stop short of doing (because it's too hard, or takes too much investment for them to do). You need to take something to the next level. That's what gets you noticed and gets people talking. That buzz creates momentum and can bring all sorts of good things (reputation included) your way.

If you want to do something really well, a good place to start is figuring out what "well" means. By what factors will your task be measured? And exactly who will do the measuring? Knowing what buttons you need to push, and who owns those buttons is a tremendous advantage. It helps you plan your game - how you're going to go get that high score in the right people's eyes. It's worth a few minutes, days even, to make these things explicit. Think about them. Write them down. Once you've got a handle on those things, choices about how you're going to spend your time, what pieces of the overall puzzle you're going to invest your energy in become a lot easier to make. You can make wiser decisions. For example, the Dot-com bust taught a bunch of people that there's no point in investing heavily in getting "clicks" or "eyeballs" if you're ultimately going to be measured only by actual sales. Oops, a bunch of people were measuring themselves on the wrong scale.

Now to apply this to software products... What buttons do you need to push to make a software product successful? When you hear high-flying CEO's being asked about what made their companies successful, I've never heard, "Well we have 47 features and the competition only has 40, so we're more value for the money." Rather, you'll hear things like, "We're the ones who made it really simple to do X." Making a software product simple is all about the User Interface.

In software, who's going to score the product? Not your boss. Maybe not even the person that "purchased" the software (on behalf of an organization full of end-users), but the actual end-users themselves. They are the ones that are going to love or hate your product and determine the level of repeat business and referrals you get - or don't get.

That being the case, it's a shame that most User Interface work is tacked onto the end of a project like a necessary evil. (And we all know that things left to the end of a software project are the first ones to get cut.) Seems to me that people have it backwards. Do the most important things first. Make them absolutely shine before you spend your time doing anything else. Because if you haven't got those things right, nothing else matters. If that means you had to cut some features, but shipped the features you did finish in a product with a User Interface that is really strong, you'll be far better off - in the eyes of the people who matter most: the people holding those buttons you've got to push - the users.

I don't know a single software company or team that wants to deliver a piece of software to their customer and never get repeat business. What that means is that the end-goal isn't just getting the contract signed off or getting paid "this time". It's about creating fans of your work, so that they keep coming back and actually refer their colleagues to you.

The importance of User Interface investment is sometimes a controversial topic. I've seen people argue very passionately on both sides. I'm a gear-head by trade. I came up through the ranks of development organizations and am certainly not a graphic designer. But I'm often the minority in the development organization when it comes to my strong beliefs in putting User Interface first. Developers pride themselves on not being influenced by shiny, glitzy User Interface baubles. But baubles are not what I'm talking about, of course.

If the scale your success is going to be measured on, is how often you get repeat business, and referrals - how many fans of your work you create; and the people doing the scoring are your users, then it's clear that User Interface design has to be your priority. Nothing is worth doing if it isn't worth doing well.

Here's a bit of irony: I'm currently developing a software product aimed specifically at development teams (Devshop.com). These are the very folks who claim to be immune to the hypnotic effects of a great User Interface, and argue regularly that it's not important, compared to all of the very technically challenging things (and interesting things to them) that happen on the back-end. I've demo'd the tool to close to 50 of these people in the last 6 months. More often than not, one of the first things out of their mouth is, "Wow. That UI is incredible." Their eyes light up when they say it too. It's like a little spark of desire was created inside them. Now I know that as long as my feature set is comparable to others in my category, they will desire mine more than the other guy's, because I took the time to do one thing better than the next guy: focused on User Interface design, to make my end-user's experience actually desirable. I put the user first, brochure second.

Monday, October 24, 2005

More General Purpose Project Management Theology Isn't Helping Matters!

I spent the bulk of yesterday searching the 'Net for focused, practical project management for software development. What I found was not very inspiring. I have to admit, I've been preaching for a while that overly generalized project management theology doesn't work - at least for software projects. How can I say that? Statistics. 70% of software projects fail. I didn't do the research personally, but it's fairly well known. One particular company (The Standish Group) produced quite a famous report (CHAOS) on the subject if you don't believe me. You can't say things are working when 70% of the projects fail. Something's fundamentally broken.

A couple times this past year, I've gone out in search of the kind of specific nuggets of wisdom and experience that can help dramatically improve the chances of success for software projects. So far however, the project management discipline at large seems to creep along, abstracting ideas further and further out to make them equally applicable to every kind of project, and none.

Here's some of the so-called "wisdom" I've found in my journeys:

[Good Planning] Take the time to plan your project properly. K. Thanks.

[Agreed-Upon Objectives] ...that can be reviewed throughout and at the end of the project to ensure they have been met. Come on now, we all know that no set of product requirements ever look the same at the end of the project as they did at the beginning of the project. How about some help dealing with that?

[Milestones in your Schedule] ...will assist you to measure real progress. Oh we have the milestones alright, trouble is they're never reached on-time.

[Resolve Project Issues in a Timely Manner] Don't slack off. Gotcha.

[Assess Your Risks throughout] ...meeting with your team... We keep telling the project sponsors that changing their mind's every week keeps delaying the delivery of the project, but they don't listen or think we're just whining. Give me something real to go to them with.

The trouble with all of the advice out there that I've seen is that it's ineffectual. It's definitely hard to argue with because on some ultra high-level, it's all true. But that doesn't make it useful. It's like saying, "You need to work hard to be successful." Gee, thanks. Give me something tangible please. Something I can do tomorrow that will have a real impact.

There's another related process called "The Demming Wheel". Plan, Do, Check, Act. (PDCA) [Every good process or methodology needs at least a 3 letter acronym, afterall]. There's a whole lot of fluff behind each phase of course, but it's all so utterly abstract that it's just a vehicle for false hope, unless you can make it tangible. SDLC's (Software Development Life Cycles) are a dime a dozen. Everyone's got one they think is magic. And still, 70% of software projects fail.

I honestly don't understand why more people aren't focusing in on certain types of projects more, when developing methodology. Maybe because the more specific you get, the more you can actually be held accountable. Application development is more than a $10 billion dollar industry. Surely it's big enough now to stop folding it in with the project management mother ship and create a specialty around just managing software projects, with all of their unique challenges, risks and techniques?

This is what I'm currently working on in the shadows right now, with Devshop.com. I plan to blow your minds in the new year. My big bold claim is that I've boiled down the essential elements of success for software projects, and am building a product around it to capture and share it all with you. It may not be applicable to any other kind of project, but for software projects, there's nothing else that can touch it.

ProjectSteps: Keep IT Simple

Stephen makes a point illustrating the 80/20 rule, including 80% of the beer being consumed by 20% of the drinkers!

He's commenting on a survey that asked successful business leaders about their success. They said they focussed on simplicity in everything they did. The study concluded that focused companies were more profitable.

It's so easy to make things complicated for ourselves. In so many cases, the things you only spend 20% of your time on will account for 80% of your success. Doing a "lot" of things makes us feel productive, but doesn't necessarily increase our chance of success.

This is also true in managing software projects. There are only a handful of factors that throw most software projects off the rails - not hundreds. Manage these, and you'll do just fine.

Here are the ones I focus on:

1. Time Estimation Error - If you can't trust the estimates coming from the team, the project plan will never be accurate. There are ways to manage this.

2. Team Distraction Rates - If your plan doesn't account for the times the team is going to inevitably be pulled off the project, your plan will never be accurate.

3. Requirements - If you can't keep a handle on the requirements for the product you're building, or can't express the true impact of changing requirements while you're making those decisions to approve the change, your plan will never be right.

These ones are the secret to delivering software on time. Forget about critical path analysis, Pert charts and automated workload balancing. Projects don't fail because you didn't spend enough time looking at the critical path. They fail because the time estimates were wrong, people got pulled off the team, or requirements changed too much. Manage those.

Wednesday, October 19, 2005

A Really Cool Way to Watch Your Web-site Traffic.

Very cool. I just stumbled across this site/product: www.visitorville.com. It's a hosted service, that's free for less than 50 unique visitors per day, and becomes a paid subscription with higher volumes. Anyway, the really neat thing is that it comes with a desktop reporting tool - only it's not so much reports, as a Sim-City view of your web-site, with little folks taking taxi's and buses to your various pages (represented by office towers).

If you want, you can click to follow a particular visitor around your site, start a chat with them, see their passport, and a surprising amount of other tid-bits. This is one of the most creative products I've seen in an otherwise mundane product category.

I installed it on my home PC, behind a firewall, and had it monitoring this blog. No firewall issues. I was up and running in 5 mins, watching my little visitors go about their business.

Very cool.

Monday, October 17, 2005

Managing Distraction

Just a quickie today. In software land, people get pulled off their primary projects regularly. Happens all the time. What's interesting, is that even though experienced project managers know this and pad for it to some degree, even they can still drastically underestimate just how often people get pulled.

I've heard numbers like 20 or 30% being passed around as the rule of thumb for padding a schedule for unforseen difficulties. In my experience, if things only deviate from plan by 20 to 30%, it's a dream project. In reality, Time Estimation Error alone can account for as much as 25% of the entire schedule, not including Distraction Rate (can be another 20%), changing requirements (another 30%), or truly unforseen technical difficulties like wasting an entire day trying to figure out why you can't cast the result of a SQL Server SCOPE_IDENTITY() call to an Integer (because it returns a Variant, which needs to be parsed rather than casted). It's no coincidence that many software projects take cleanly twice as long as expected. It's because if you add up the impacts of the top 3 software project killer factors, it's near 100% of the original schedule.

Here's one you should track if you're not already: Distraction Rates. Just keep a spreadsheet of each time someone on the team gets pulled off the project to go do some other work, not related to the project. I'm not talking about counting half-hours. You can even just do a proxy estimation at the end of each week. By the time 2 months has passed, you should see a pretty good chunk of time that's slipped away. If you've kept your spreadsheet up to date, you should be able to calculate on average, what % of each person's time is spent doing work not related to the project, and also for the team as a whole.

Now that you've got the Distraction Rate for each person, you can take the remaining portion of the project (say, another 5 months), and multiply the remaining duration by the Distraction Rate. So if you've got 5 months to go, and your team's distraction rate is 20%, then you're going to be 1 month late due to distractions, if you haven't already included an extra month in the schedule just to account for this one factor.

This kind of trending let's you know what's going to happen, before it actually does. While on any given day, one individual distraction might seem like an anomaly, if you look over a larger window of time (monthly, for example), these kinds of things typically repeat themselves. If it's not one thing taking you away from the project, it's another.

Tuesday, October 04, 2005

Think like the customer. You are not the customer.

I'm reading this great book called, "The Art of the Start", by Guy Kawasaki. It's a no fluff guide to getting a startup company off the ground. There's several great lines in this book, but one that particularly got me was this:

Apparently, DELL has a sign in their office that says, "Think like the customer" in big bold letters. Not too far from it is another sign that says, "You are not the customer". Brilliant.

I think that it's a mistake to let customers design products. Anyone see the Simpsons episode about the car that Homer built? Customers aren't usually designers. BUT... You can't be a good designer without understanding them...

Monday, October 03, 2005

The Cost of Late Software

Whatever you may think the cost of late software is, it's at least an order of magnitude more.

Since software development isn't a capital intensive business, requiring lots of up-front investment in materials or equipment, most people would think the cost of a late software project is simply the extra cost of carrying the dev team's salaries for the extra time. Not even including the intangibles like credibility, reputation, missed opportunites, etc., the REAL cost of late software is much higher.

The example I always use comes from a small company I worked with a couple years ago. This company was about 20 people, with 1 flagship product on the market, and another one still being developed in the basement. So all of the company's $4 million/yr revenue came from this one product. It was a piece of enterprise software, that sold for about $50k for several thousand seats. The sales cycle was 6 months - from first introduction, to educating the customer, jumping through all the hoops, and finally closing the sale. The development team was 5 people, and they were working on the next version of the flagship product - a development cycle of 6 to 9 months.

For any company like this, a slip of 30% to the schedule is a BIG deal. Let's say it was a 9 month project. 30% is almost 3 full months. While the cost of carrying the 5 person dev team for another 3 months isn't a heck of a lot of money, the real costs are indirect, and not so obvious. But they are still quantifiable.

To figure out the real cost of the late software in a case like this requires a little modelling, and talking about it with each of the project stakeholders. With a sales cycle of 6 months, Sales teams often end up selling the 'next' version of the product, because by the time they close a deal, the current version has been replaced by the next version anyway. With a 3 month delay (one full Quarter), most of the leads the Sales team is trying to close will also hold their purchase until the software is done. No point in rolling something out, only to have to patch or upgrade it 2 to 3 months later. A whole Quarter's worth of revenue can evaporate in a snap. While it's technically not disappearing (it's merely being delayed), it might as well be for this fiscal year because while the revenue was put on hold, the expenses weren't. So the company loses money during that period. With a longer sales cycle, the Sales team doesn't have the time to quickly react, find new leads, run them through the whole sales process and close new deals to account for the ones delayed. For a company like I described above, that's a $1 million price tag on that 3 month slip in product schedule.

Even if you're not producing enterprise software with really big price tags and long sales cycles, your business has beened planned around so much money coming in during the year (revenue), and so much going out (expenses). Delayed revenue is lost revenue in the context of your current year. It means during the period when the product was supposed to ship and when it actually does, the company is losing money. It doesn't matter how much your product costs or how quickly you can sell it. Even more scary, since revenue for new versions or new products is typically on a slope, don't look at the first 3 months of revenue being lost (delayed), look at the last 3 months of the year - those numbers will be significaly higher. (Think of a product that is planned to earn $50k per month in the first few months, but climb to $100k per month by the end of the year).

Then there's the mis-coordination costs. Marketing dollars get pre-committed, often with non-refundable advertising spots. Or if not non-refundable, there's at least a cancellation penalty. In a company of any size, or with a customer of any size, there are people often booked to rollout these products around their ship date. When the ship date slips, it can cost both organizations for the time that those folks could have been doing other things.

Even if the organization producing the software doesn't sell it for profit - in cases where it's only used internally: The software project was undertaken to improve some facet of operations - to bring new capabilities, or likely to reduce costs. When the software slips, the economic potential of that application (even if it was just to save costs) is not realized.

Every day the software is late, the organization loses money.

The factors may differ from company to company, but the cost of just carrying the dev team's salaries for a couple extra months is usually only a small fraction of the indirect costs. If you sit down with a spreadsheet and run a quick model, the bottom line will often surprise you.

No wonder people get so upset with the software is late!