Uncommon Sense (for Software)

New Feed URL for Uncommon Sense (for Software)

2006-11-30T16:03:00.000-05:00

I've hopped over to Typepad for my blogging needs. The Web URL is still the same:

www.UncommonSenseForSoftware.com

... because I've remapped the domain to point to Typepad. However, the RSS feed URL has changed to:

www.UncommonSenseForSoftware.com/index.rdf

Please update your feed readers with the new feed!

Happy trails,

Craig.

Last reminder that the blog has moved...

2006-04-24T11:32:00.000-05:00

Hi there,

Last call to let you know that this blog as moved to:
www.UncommonSenseForSoftware.com

Please update your bookmarks and feed reader.

Thanks!

Craig.

Outsourcing Development = Giving Away Your Success

2006-04-10T10:15:00.000-05:00

There's a new article over at the new location for this blog:

www.UncommonSenseForSoftware.com

If you haven't already, please update your feeds and bookmarks!

It's the details that separate us from the apes.

2006-04-03T22:05:00.000-05:00

There's a new article over at the new location for this blog:

www.UncommonSenseForSoftware.com

If you haven't already, please update your feeds and bookmarks!

Uncommon Sense (for Software) is moving...

2006-03-29T09:28:00.000-05:00

I've been double posting for a while now, here and at my new domain: www.UncommonSenseForSoftware.com.

I'll only be posting over there from this point forward. Please update your feeds and bookmarks!

My dreamPod

2006-03-28T09:17:00.000-05:00

My dreamPod
Originally uploaded by craig_in_ottawa.

So, I saw this funny video about DRM (Digital Rights Management; video by David Berlind at ZDNet). Damn, he makes a good point. I was really getting the itch to pick up a video iPod too. Guess I'll wait a bit. Afterall, unless consumers put pressure on vendors to open up, they'll stay proprietary - it's in their best interests.

Then, I got to thinking... The other problem with picking up a device like this is that 4 months later, I'm gonna wish I had waited for that one extra feature that the "next" version has.

What would I want in my dreamPod? Here it is (photo). Let me give you a tour...

1. Camera - facing away from the user. This is the one that let's you snap a quick photo while you're watching the LCD screen to make sure you've got everything "in frame".

2. Camera - facing the user. This one's used for the inevitable two-way video phone functionality, or for you to annotate a picture you just snapped, or to film you and your buddy/girlfriend standing in front of Niagra Falls.

3. Speaker - just enough for you to hear it with your ear pressed to it - because of course, this device is also a phone now.

4. KEYS button - one of my pet peeves with the otherwise brilliantly simple input design of the iPod is that you can't input the Contacts, Calendar or other typical PDA data that it's now starting to support. If you had a quick key for KEYBOARD, then you could just use the touch pad to zoom around the on-screen keyboard and press the center button to "press" a key. This I think would actually be better than a physical keyboard for text-messaging, and also better than a stylus and hand-writing recognition that doesn't work anyway.

5. MIC - Most phone mics are pretty good now. They don't need to be "exactly" where you put your mouth, just in the general area.

6. PIC button - 'cause for candid pics, you've gotta be quick!

7. Center button mod - let's make the touch sensitive surface include the whole circle (button included), not just the donut shape around the perimeter. This opens up a lot more input possibilities than just a "dial" experience.

Dare to dream. I think Apple could do it if they put their minds to it. Maybe they already are...

Tembria - Server monitoring for the rest of us.

2006-03-27T09:14:00.000-05:00

After finally moving the Devshop web-site to a real server in a real hosting facility (SAVVIS via LayeredTech), it was time to get some server monitoring software up and running. I want to know that my site is always up and for something to tap me on the shoulder immediately if it goes down.

My pet peeve about monitoring software is that it typically looks like it's been run over repeatedly by a mac truck. I mean it's so ugly I wouldn't kiss it with your lips. Difficult to use, far too much use of command lines and console output, the list goes on. There are a select group of real network admin experts out there who don't seem to mind these kinds of products. After all, form follows function, they would say.

Unfortunately for a lot of folks like me, we inherit the responsibility of making sure servers are up and running even though we are not as knowledgeable about this sort of thing as our network admin friends are.

So thankfully, there's Tembria. Tembria's server monitor not only has so many of the bells and whistles that our network admin friends would expect, but it's actually usable by non-experts like me.

Check out the screen shots.

More on the upcoming Ottawa BarCamp

2006-03-22T09:11:00.000-05:00

A location for the upcoming BarCamp Ottawa has been chosen: BitHeads at Carling and Merivale (Ottawa). Apparently the space is very swank. It used to be an old movie theatre, converted by the BitHead folks for just these kinds of events.

We've reached our sponsorship goal. Many local companies have pitched in to make this event happen. The list of attendees and sponsors can be found on the BarCamp Ottawa wiki.

We're still looking for more participants! If you're interested in leading a session on a cool topic, or just in coming along to participate, sign up on the wiki.

Hope to see you there!

Review of Devshop site

2006-03-17T21:20:00.000-05:00

Geof Harries over at YukonBiz has reviewed the new site and material we put up about the product.

He even throws in a Batman/Robin reference... Can I use that in my Marketing materials?

New Devshop site is up...

2006-03-17T13:31:00.000-05:00

The new Devshop site was put up at 2am this morning. Take a look!

Devshop

Death by a thousand cuts

2006-03-15T19:56:00.000-05:00

One of the biggest software project killer factors is requirements management - or more accurately, lack of requirements management. You've seen it: requirements that either keep growing, long after development has begun, or change more regularly than you could possibly keep track.

(I once worked for a company where the leadership team was still arguing about what the product was supposed to be, a month before it was supposed to be done.)

Everyone knows that requirements management is a problem. So if knowing is half the battle, then what's the other half? Why isn't there a well known, clear solution? What does it actually mean to "manage" requirements?

The trouble with most cases of changing requirements is two fold:

Each individual change is small enough to slide under the radar: If it only takes a developer 4 hours to knock off a new feature, where's the harm? So it's not tracked...

Since the changes aren't tracked (and tallied), the sum of the changes quietly adds up, but is never addressed in the schedule.

Before you know it, you're now 2 months behind schedule, and sliding fast. This is like death by a thousand cuts. A single paper-cut may be little more than a nuisance, but a thousand at once can make you bleed to death. I saw a movie once (can't remember what it was) where the bad guy was stealing money from a bank by hacking into their computers and collecting all of the fractions of a cent that resulted from certain bank transactions. Since it was fractions of a cent, it was virtually untraceable, except that over billions of transactions, it eventually added up.

Most people intuitively know that changing requirements mid-cycle is bad, but they don't realize how often it happens, or what the impact is, so they're powerless to adapt for it and schedule around it. Since they don't see the impact, they have no incentive or reason to knock it off. And in the end, it's not the changing requirements that kill us (adaptability = good), but the fact that we didn't plan for them or that we let them get out of control that does. It's the unwelcome surprise.

Managing requirements doesn't necessarily mean determining them all up front, before development begins, then freezing them through a development cycle, and saying no to every request until the thing ships. That's just not realistic. Adaptability afterall, is a key strength in business.

Well, if not that, then what? The first part of the solution is quantification. It's no use trying to use anecdotes to show people how "requirements keep changing and it's going to make us late." Chances are, the only examples you'll have at your finger tips are those "4 hour" requests that don't have the shock factor you're going to need illustrate your point. Remember, no single change request is the problem, it's the cumulative effect where dealing with. So if you can't demonstrate the cumulative effect, the message just comes off as complaining and falls on deaf ears. To show the cumulative effect, you need to have tracked them - all of them. That's the only way you'll have a shot at credibly demonstrating the impact. Each one may only be 4 hours, but x3 per week is a minimum of a 30% reduction in some poor developer's productivity, not even including the context switch (arguably another 20%). Then there's the fact that every seemingly 4 hour request actually balloons to a full day when all's said and done.

Suppose you've quantified the impact early on. Let's say, in the first 2 months of a 6 month project, you've calculated that requirements changes have added up to 2 weeks worth of extra effort. Not only are you now 2 weeks behind schedule, but if the trend continues, you're likely to add another 4 weeks of requirements change in the remaining 4 months of the schedule, for a total impact of 1.5 months of your original 6 month schedule. All for seemingly little requests here and there.

So managing requirements doesn't mean Big Up Front Design and no changes mid-cycle, it means:

Tracking and trending the changes

Using the trend to assess impact

Making good decisions around how much of this change you should plan for in your schedule

Only by tracking the seemingly harmless change requests can you see their cumulative effect before it's too late. Not letting them surprise you and catch you flat-footed is key. Only by using real data instead of anecdotes can you have productive conversations about requirements change with those that need to know.

BarCamp Ottawa Coming Soon

2006-03-09T08:43:00.000-05:00

I've offered to pitch in and help organize BarCamp Ottawa with Peter Childs, Alec Saunders and David Keys.

BarCamp is called an "unconference", which makes it very much cooler than just a conference, you know, without the un. Seriously, it's a way for us folks down in the trenches of Ottawa's high-tech to get together, meet eachother, swap stories and experiences, and discuss some topics that are near and dear to our own hearts.

Yesterday we had a meeting and the following theme suggestions came up:

Web 2.0 (obviously!)

Voice 2.0 (over IP)

Wi-fi

Extreme Programming

As BarCamps go though, it's not the organizers speaking and the attendees listening. It's very much the attendees as participants and speakers. If you've got a topic area you'd like to huddle on with some folks, head over to the Wiki and post it! Add yourself to the list of attendees if you can make it.

The date is Saturday, April 22nd, location TBD. It's totally casual, and free, but you have to participate! Spread the word!

Also check out:

The rules of BarCamp

Project Management Quotes

2006-03-08T07:20:00.000-05:00

Stephen Seay over at Project Steps posted a long list of project management quotes. Some of them are kind of funny and just a little cynical.

These are my favorites:

The sooner you begin coding the later you finish.

Good time estimators aren't modest: if it's huge they say so.

Everyone asks for a strong project manager - when they get him they don't want him.

The first 90% of a project takes 90% of the time the last 10% takes the other 90%.

If it wasn't for the 'last minute', nothing would get done.

If project content is allowed to change freely the rate of change will exceed the rate of progress.

The Power of the Suite

2006-03-02T23:15:00.000-05:00

A week or so ago, I was chatting with someone about what I often bash as the "one kind fits all" approach to project management. The idea being that different kinds of projects have different risks and challenges, and therefore, require different techniques to really nail them. Anyway, this person mentioned another "one fits all" phenomenon where he worked... The customer (internal users) and the development team of this organization kept wrestling with this "one application that does everything." Over time, it seemed that this one in-house application had become responsible for nearly every aspect of operations. In other words, they had tried to automate every aspect of their business, and as if that wasn't bad enough, they were trying to do it inside a single application. This is enterprise software at its worst.

This "one app that does it all" approach is dangerous for a couple reasons, both having to do with complexity. First, there's the complexity for the user - good luck training someone on something that has a zillion whirly-dos, what's-its and gizmos, and has completely lost any resemblance to the original metaphor that was supposed to intuitively convey how to use the thing in the first place - or worse, is nothing but 45 tabs across the top of your page, each with another 20 tabs below them (you know who you are!) Second, there's the complexity for the developers. The more business rules and features crammed into a single code-base, the harder it is to maintain, the slower it is to innovate with and long story short, the more expensive it becomes (serious diminishing returns with each added bell or whistle, or whirly-do or gizmo).

And then the pendulum started swinging back the other way... Over the last year in particular (ok, maybe starting 2 years ago) there has been a significant movement back towards simple, single purpose apps. For anyone claiming to have nearly invented this, they're just too young to remember that before applications got so big and complex, they were in fact much smaller and more simple (ahhhhh, the good ol' days). I really hope nobody labels themselves the "Grandfather" of simple, single purpose apps. I've read there's a Grandfather of AJAX, but, really? Did he invent or write the XMLHTTPRequest objects that have existed in browsers from different vendors for years? People love to have a hero. But that's another story. We just got carried away with ourselves for about a decade, us and our big ol' enterprise apps, that's all.

So here's the paradox: (or maybe conundrum, I’m not sure which): Bigger, more sophisticated enterprise apps will always win the feature battle. Some functions just require a lot more flexibility and programmability than small, lightweight tools can offer. These monsters will always be expensive and time consuming, but they serve some purpose - assuming they're not taken overboard with the "one app for all needs" approach.

On the other hand, I've never been a big believer that businesses in particular have needs that are soooooooo unique that they can't possibly find an off-the-shelf tool to do about 80% of what they're looking for and then get all those really smart employees to use their brains, arms and hands to do the other 20% - thus avoiding the pitfalls of never-ending-software altogether. But, that's just me. It's a good practice to always look around for the commercial tool that does most of what you want and be realistic that it may not be cost-effective to try and build something from scratch just to get the other 20%. If you're building your own timesheet software, stop it right now! Shame on you! Never mind the fact that delegating every single aspect of your operations to a computer program tends to tie the hands of your employees, especially in situations of customer service. How many times have you heard, "I'm sorry, the computer won't let me do that. I can't help you." Gee thanks. Hooray for progress.

So I guess you could say, I'm warm to the "simple, single purpose app" movement - with one caveat: At some point, when people max out their potential with a simple app, they inevitably want more. So how do you give them more, and still keep the app simple and follow a single design metaphor? This is the product life cycle challenge that forces so many companies who at one point early in their lives sang the virtues of simplicity, to change their tune to one of feature richness and customizability. In short, they grew up. And so they traded one set of challenges (not having as many features as the big guys) for a different set of challenges (not being as nimble and easy as the little guys). It’s kind of like a 16 year old complaining he’s not being given enough responsibility and then turning 35 and wishing he was 16 again without a care in the world.

Truth is, there's a happy, blissful middle ground: the product suite. See, with the suite, you get a handful of related, compatible, yet independent "simple, single purpose apps" that talk to each other. The benefits, they are a plenty:

Users get to dip their toe in the water by adopting one of the products in the suite without adopting everything at once and possibly being overwhelmed. They can grow with you and adopt other related tools as they need. Better still, they are motivated to use YOUR other tools instead of the competition’s, because yours are all integrated and that provides added value.

Individual products can stick to a single metaphor and be super easy to use, but gain some of the benefits of "big" software by relying on and exchanging with their brother and sister products.

Because the overall functionality of the suite has been split up among distinct products (something us techies call partitioning), complexity is reduced for the user and the development team, so everybody wins.

The only thing you're left with is the odd user saying, "I don't want 4 apps, I just want one." (lazy ;)), but with a good talking-to and maybe quoting a couple paragraphs from this blog entry, you can turn them around so they see the light. The one legitimate complaint I hear about having to use multiple apps, is having to log-in all over the place. Single sign-on is probably THE killer feature for a suite of products - don't forget it.

So, hooray for the movement back to simplicity in design - let's just not forget that sometimes people need more than one app can give, and let's get these apps talking to each other in meaningful ways instead of cramming everything into one box.

Happy trails.

Contact info...

2006-03-01T09:22:00.000-05:00

I've had a couple comments recently asking for contact info. You can reach me by email here.

Now you can send me all kinds of secret messages.

Presentation to Ottawa developer group

2006-02-23T08:49:00.000-05:00

Last night I had the opportunity to present my company (Devshop) to a group of local Ottawa developers. Devshop is currently developing a radical new web-based project management tool specifically designed for software teams to address the common challenges associated with software projects. More on that coming soon. The forum was a monthly OGRE meeting (Ottawa Group of Ruby Enthusiasts), hosted by the team at JadedPixel.

I know at least a few of the folks at the meeting last night will be checking out this blog, so to you, thanks for the opportunity to present and the brews shared at the pub afterwards. Good times.

Devshop has been in stealth mode for some time now. In the next couple of months, I'll be free to start letting the cat out of the bag (at least up to its ears & eyebrows). The first real web-site explaining the goals and the product (and most importantly, what it means to software developers of the world) is in progress and will be up in the next few weeks. Hope you'll come back for a visit to check it out.

Many thanks to everyone that attended last night. 'Be seeing you.

Design a couple versions at a time

2006-02-16T08:13:00.000-05:00

Every day in the software world, you run into people that rather neatly fall into 2 camps:

Design snobs

Those that think design is icing on the cake

I personally am in the design snob category. I believe that design (or lack of) makes or breaks a product. A lot of times, I'm talking just about user interface design, but the truth is, anything said about user interface design can typically be applied equally well to technical design. The technical equivalent of user interface design, for a coder, is the design of their public interfaces - the methods and properties you can call on their class library.

In both cases, there is always a tension for designer between "what would make it easier to implement" and "what would make it easier for the end-user". This is equally true whether the end user is someone clicking a button on the user interface, or another developer trying to use your API. Either way, the designer's #1 job is to empathise with the end-user. The biggest danger a designer faces (interface or technical) is to start thinking too much about implementation too early. Design is an expression of the end-goal. Start with "here's what we want to get to". Even if you aren't able to get there in a single release, or have to make some tradeoffs along the way, start with the best design you can come up with, and work backwards to what is feasible given your constraints. That way, with your user interface or your technical architecture, you'll be able to come back later to fit things in that didn't make it in the first go-round.

If you design only what you think you can accomplish right now, you're going to have to bend and twist your design in unnatural ways in the next iteration, to account for things that you didn't account for in the original design. In short, over-design up front - do a couple versions at once. This thinking might throw a few folks into a panic because we've all heard from our ancestors that back-in-the-day large software systems experienced "paralysis by analysis", meaning, they never got off the drawing-board. That was before the 'Net. Given how easy it is to publish and distribute an application nowadays, people are slapping them together and shoveling them out the door with comparably little design (not to mention testing). Don't worry about over-designing.

If you spend about twice as much time designing as the next guy, you're probably spending just the right amount of time and your product will show it.

Plan for a couple of iterations, so you know where you're headed. Then you can break up the implementation of that design over a couple of iterations or releases. Since ripping up a design document is way easier than ripping out a chunk of code, it's better to design a few iterations at a time, so that if in iteration #2 you realize something in iteration #1 was going to create a conflict, you've caught it before it was actually implemented. The more we design a couple iterations at a time, the less products come out looking like Frankenstein later.

And just for the heck of it, here's a link to some great "importance of design" quotes I stumbled across, at LUKEW Interface Designs.

A couple of my favorites:

[Users] make their credibility-based decisions about the people or organization behind the site based upon the site's overall visual appeal.
- Stanford Persuasive Technology Lab, 2002

Design is not just what it looks like and feels like. Design is how it works.
- Steve Jobs, 2003

Visual appearance is one of the most effective variables for quickly differentiating one application from another.
- Bob Baxley, 2003

If a site is perfectly usable but it lacks an elegant and appropriate design style, it will fail.
- Curt Cloninger, 2001

The details are not the details. They make the design.
- Charles Eames

Problems with visual design can turn users off so quickly that they never discover all the smart choices you made with navigation or interaction design.
- Jesse James Garrett, 2002

Good design is the most important way to differentiate ourselves from our competitors.
- Samsung CEO Yun Jong Yong, 2004

Design is the easiest way to reenergize a product.
- Fast Company, 2005

Your products run for election every day and good design is critical to winning the campaign.
- Procter & Gamble CEO A.G. Lafley, 2005

You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.
- Steve Jobs, 2005

In Software Project Management, Size Doesn't Matter

2006-02-10T08:48:00.000-05:00

A few months ago, I was discussing project management with someone from the financial sector. This person, who is rather good at his own line of work, admitted he didn't know much about project management (but had some clients that did). We were talking about some new ways of looking at project management, particularly, the domain specific approach that I often advocate. Wanting to test my theories, he picked up the phone and proceeded to call one of his clients, whom he knew to be a real top-notch expert in project management. What is interesting is that this project manager client of his was perceived to be an expert not because of any particularly extraordinary skills he had displayed, or even a long list of stellar accomplishments but rather, because he managed really BIG projects - like 4 years, 200 people, $50 million projects. Big ones.

At first, I didn't even think twice. Of course, I thought, I suppose you would have to be really good to handle those kinds of projects. I mean, if co-ordinating 10 people is tough, 200 must be about 20 times tougher. A lot of people would certainly reason this way. After meeting this manager, which was a rather familiar experience (nothing much new), it triggered a line of thinking:

It is often far more difficult to manage a 10 person project than a 200 person project.

Let me explain. It's not that I'm saying that the person managing the 10 person team is more important that the person managing 200 people on a $50 million project. I'm not equating difficulty with importance - and by difficulty, I'm talking about the project management responsibilities, not other duties they may have to perform.

Speaking with this project manager in particular gave me deja vu. It was more like speaking with a CEO than a project manager.

In chatting with any "project manager" with a team size of 100 or so people, what you quickly realize is that they're not project managing anymore at all. They're more like a CEO, involved at the capital allocation level, for multi-year operations. They are running an organization. They're tuned in to major technological shifts and trends, like "If we bet the farm on Lotus Notes, will it still be the platform of choice when we finish in 4 years?" Heh heh. Oops. When you're talking about a project that big, the head honcho is managing managers, who possibly manage other managers, who have team leads, who lead the people actually producing the work. They are more like mentors to the managers who are actually managing. The organization is large enough then, that it becomes really difficult to see the direct impact that the top decision maker is having on the success or failure of the project. I liken it to riding (or steering) the wave, rather than causing it directly. How many debates have you heard after some political or fortune 500 scandal where hoards of people say things like, "Well, you can't blame the top dog for something that some underling in another office did. It's not his fault." There you have it, by popular opinion, less direct accountability for large teams. If you can't blame the top dog for failures, then how can you attribute success to him?

Life in a small team however (say 10 people), is much more likely to give you a heart attack. There's nowhere to hide. The pace is way faster. It's very easy to see the direct impact (good or bad) that each person is having on a daily basis. When you're managing a software team of less than 10 people, chances are, you're not just the manager, but one of the developers as well (or at least a designer or architect). The dynamic of a 10 person software team is much more clear - one person managing, and 9 people producing. I think it's at about 10 to 15 people, where it is no longer practical for a manager to even touch the source code - in fact, it can be down right dangerous. Coding is not something you should dabble in. Either let it consume you and be really good at it, or don't touch it. After 15 or more team members, it's quite likely that there will be a lot more delegation. At 15, you may have 1 manager and 1 technical team lead. At 35, you probably have a Director or a couple managers and a couple technical team leads. At 100, well, you get the picture. With each round of delegation (which IS necessary by the way), some amount of pressure, and direct accountability is taken away from the top dog. I'm not just theorizing here, I've actually experienced it. While I haven't managed a 100 person team yet, I can already see the difference between 10 and 35 developers, team sizes I have managed. To manage 35 developers you really need to break them up into teams of 5 to 7, with technical team leads, and a manager or two. So even at 35, there's a couple degrees of separation between the top policy maker, and the folks actually producing code.

In that awkward team size of about 10 developers, you're likely to be as much a producer as a manager. It's really tough to be great at both. Just like you shouldn't dabble at coding, dabbling at managing just makes you a manager with a disadvantage. It's at the point in time where it is clear to everyone around you that it is no longer practical for you do be doing any producing, but that you should be managing full time, that your project management life actually starts to get a bit easier. At that point in time where you have managers reporting to you, your project management worries get lighter still (though you probably have new responsibilities keeping you up nights).

All this to say, over that last 13 years of managing software teams, I haven't seen convincing evidence that project management difficulty increases linearly with team size. There's a breaking point at which the project management (only) difficulty actually decreases when the team sizes breaks a certain point. Project management worries then get replaced by other worries (like what the heck should we be betting the farm on... 'cause if I'm wrong, we go out of business - easy stuff like that).

Am I right?

Software Ideals.

2006-01-17T09:02:00.000-05:00

How many times in your life have you ever thought to yourself, "I'll just slap this together now, and fix it later." I'm not sure what it is about the brain's wiring that makes us think that somehow tomorrow we'll be much less busy, have much more money and more energy to do the things that we either don't have the energy for today, don't have the money for, or just don't want to do. Only in hind-sight, and apparently after quite a bit of experience do you learn it's just not true. Every day I wake up, there seems to be even more to do, with less money, and it's needed faster than ever - not the other way around. So in reality, that "tomorrow" we’re thinking about (the one with all the extra time, energy and money) never comes. So things never get fixed/patched/improved like we thought they would. After a long while, you look back at your work and realize all you've done was produce half-assed work always thinking you'd fix it "tomorrow". And here we were thinking we were just making those tough decisions, the compromises, to live to fight another day.

This realization begs a change in behavior. If in fact tomorrow isn't going to be any easier than today (and you're actually going to realize there are 5 more things you need to do on top of your current to-do list), then there's no time like the present to patch that hole, fix that bug, or do those sit-ups that you aren't going to feel like doing tomorrow any more than you feel like doing today.

"There's no time like the present." "Do it right the first time." "Anything worth doing is worth doing right." "Good enough, isn't." "Relentless improvement." "Whatever you're doing, do it better than the next guy." "Do a smaller number of things, but do them better."

These are phrases that have been rolling around in my brain for a while now. Over the last year I've been building a software project management application that will be released this year (not a small endeavor). My company's mission (Devshop.com) is to help teams produce better software. During this time, I've had a chance to re-evaluate many of the patterns and habits I've developed (and witnessed) over the years, in producing software for the companies I've worked for. One of the great things about striking out on your own is that you get to chose how you're going to "follow" the good patterns, and how you're going to break the mold and do things differently ("lead the pack").

We all know that no matter what we're doing, there's always going to be some kind of time pressure on us. I personally have always placed extra emphasis on not only getting a job done, but hitting your target date as well. In truth, looking back I've made some of those common decisions (mistakes) like cutting testing, cutting documentation, cutting user interface design all to hit what seems like a fairly arbitrary deadline, so that we can say we made the release date.

It just doesn't make good business sense. Not that you should keep your application in development forever until it's perfect – we've all heard the stories about applications that never got off the drawing board. But I'm assuming you have a set of reasonably fixed requirements. Those stories about applications that never saw the light of day got that way because of never-ending requirements change – not because some perfectionist didn’t want to release their code because it wasn't perfect yet. So that's really a different issue.

I think that the moral of that old story, "We need to ship at some point otherwise the software will never get off the drawing board" is out-dated. For the last 10 years at least, the trend has been to release software far too early (with not enough testing, refinement and design) rather than after too much fine tuning. Look at the state of software today. It's buggy. Slapped together. Rushed. Do not fear taking the extra time to get it right – fear shipping sloppy products. There's enough evidence out there that the "first mover" advantage is a myth. Too many times a "fast follower" has come along with a better implementation and kicked the inventor's butt with his own invention. All you accomplish by shipping a pre-mature product with a great idea is give the idea away to your competition at a time when you have a poor implementation of it - a bad idea. Getting the customer "first" is really important when it's nearly impossible to get them to switch later - but switching software is easy. Focus on keeping them once you get them, rather than just getting them first.

I've heard it said that the development phase of a product's life cycle is a small one-time cost (say, for one particular release), whereas support and maintenance is a large recurring cost. It's true. If you look at established software companies, their product development expenses are often far less than any other department – marketing, sales, support, operations... That's one of the great things about the software biz. If done right, you can spend (relatively) a little to build a great product, then sell it a billion times and make a pile of money. At least that's what everyone is aiming for. But notice I said "great" product. That's the hard part.

"Great" products aren't rushed, slapped together, ill-designed or buggy. They are the result of a steadfast belief that quality comes first. Not just quality only in the quantitative bug-count sort of way, but in terms of design, user experience and ability to solve the original problem. Great products aren't just a bag of features or a brochure as long as your arm. They are an "elegant" solution to a problem.

I think that we as software producers need to stop deluding ourselves that we'll fix it tomorrow, or that hitting a release date is the #1 goal of a software team. Tomorrow will never come (at least the tomorrow we're thinking about) and a timeline-over-quality approach leads to weak products.

I was recently faced with a business decision about when to launch my own product, and with what feature set. The choice was to launch sooner (a Quarter at least) with a much reduced feature set (that solved the problem "less well" than the original design) or to stay the course and deliver on the original mission. Giving up short-term revenue is not an easy choice to make for anyone. But ultimately I believe that it's the substantially better product that is going to win, not hitting the market 3 to 5 months sooner.

This decision has caused me adopt different habits. Like, when you find a bug, stop what you're doing and fix it now. It won't be easier or cheaper to fix later – it'll be harder and more expensive (time and money), when you've lopped another 20% of code on top of your application – or after it hits the street and starts affecting customers. My personal commitment, is to ship with "zero known bugs". Not that I and my customers won't find some after release, like with any software product, but I'm not going to use a "known issues" list as a crutch to ship early.

The need to stick to your ideals and put quality first is even more important for small companies. Maybe if you have a monopoly you can get away with bad customer service and poor quality products, because customers have nowhere else to go. But if you're an up-and-comer looking for an angle to compete on, make it quality. It's something that people sacrifice far too often and can give you a leg-up.

A Quick Recap

2005-12-13T09:11:00.000-05:00

My brain will soon be in holiday mode so rather than a whole article this week, we get a "flashback episode" of sorts.

I started this Blog in September 2005 just to give it a whirl. So far, over 2,000 unique visitors have stopped by and the list is growing. A few of you even keep coming back, so thank-you for that.

I believe very strongly that the way we all produce software needs some work. I believe that we as an industry need to get better at predicting when we'll ship our products and without falling back on sacrificing quality to hit some arbitrary date just so that we can say we hit the date.

I also believe very strongly that the general purpose project management approach doesn't cut it for software projects, which are by nature extremely complex. We need to focus on the things that are tripping us up specifically in software projects if we're going to crack this nut.

Here are some past articles in case you haven't seen them yet. Also, check out Devshop.com and put your e-mail address on file if you'd like to be notified when my product ships in the new year.

See you in 2006!

Craig.

Past articles:

Trick Question: Could You Manage a Space Shuttle Launch? This one is about how we intuitively know that domain specific experience counts, but haven't quite built that into project management methodology yet.

Customers don't buy "solutions", they buy products and services. May the best products and services win. Some thoughts contradicting the "solution selling" style. It's not for everyone.

If you get 1 thing right in your application, make it the User Interface. The importance of "look and feel" to your customers and your revenue.

More General Purpose Project Management Theology Isn't Helping Matters! A mild rant.

Keeping it simple. A point about focusing on the right things and forgetting the noise.

The Cost of Late Software. Do you know how much this costs your company? It's big.

Building Front-to-Back The benefits you can achieve by building your User Interface and getting approval on it before building out the back-end.

How to Explain Good Architecture to the Non-techie. It's more about operational effectiveness than anything.

A Trend Can Kill You. Hiccups aren't usually one-offs. They can often indicate trends you should be watching.

The Software Wasn't Late, It Was Supposed to Take That Long. The difference between really "late" software, and software that was estimated wrong.

The Power of Suggestion. A word about the denial that many of us live in with respect to software development.

Raising your Credibility

2005-11-23T16:34:00.000-05:00

As a project manager of a software project, one of your biggest responsibilities and greatest challenges will be to make people understand things they don't want to understand and believe things they don't want to believe. You will be fighting a kind of self-hypnosis, where people believe what they want to believe because it's just easier that way. (See also: The Power of Suggestion) This is the hardest kind of convincing. In order to pull it off, you're going to need to have a lot of credibility saved up. Credibility is like money - you earn it today so you can spend it tomorrow. Like with money, you can do things to invest in your credibility that will have bigger credibility payoffs later (a kind of Return on Investment). And of course, nothing builds credibility like a solid track record of delivery. It’s hard to argue with results.

Here are the kinds of beliefs you will have to dispel before you can get your various messages through:

"Other Co. is pumping out products at twice this rate, why can't we?"

"The development department has a pool table, so they aren't working hard enough."

"The developers all wear jeans and rock T-shirts so they don't take their work as seriously as the rest of us."

"Nothing else the company does takes as long as the software does, so something must be wrong with the way we develop."

"If we ship it now, we can fix the architecture later."

“We can’t just freeze all of the requirements for the next 8 months while we build the software. We need to be responsive to the market.”

Here's the strangest factor you’ll be battling: The very people that claim development takes way too long and is always late are the very people that will try to beat you up to lower your time estimates and cut any buffer time you put into the schedule (and thus jeopardize the project’s chance of success). Some of your stakeholders will be Sales people – professional negotiators. When they convince you to strip your buffers from the schedule and lower your time estimates, they believe they’ve won something. Go figure.

One approach to dispelling these development myths would be to arm you with various well written explanations and superbly logical arguments as to why they are false. In my experience, that doesn’t work. The truth is the very nature of software development starts you off with a negative credibility balance:

The net productivity difference (all-in) between a good developer and an average one can be as much as 10 times (various organizations have studied this), so attracting the “good” ones is very important

Attracting and retaining good developers is a highly competitive business, so perks like a casual (comfortable) work environment, good pay, stock options and flexible work hours are thrown in to sweeten the deal

Developers typically love their jobs, so even when the pressure mounts, they may not show the stress cracks as much as someone who is equally pressured but doesn’t love their job quite as much

Add to the mix the fact that most development projects (even some of your own) have been late or troubled, and you don’t have a lot of credibility to begin with. Because of these software development realities, you as a leader need to be on top of your game to counter the negative perception of the nature of software development. If you want to convince one of your stakeholders of something unintuitive, you need to be the pinnacle of professionalism with credibility to boot.

Here are the things I’ve found that build credibility and help you get your message through without falling into the trap of arguing about how hard the developers work, whether or not shirts and ties make you more professional or why attracting and retaining top-notch developers is in the company’s best interest, compared to another type of employee:

You need to deliver. You need to keep your word. When you say you’re going to be done in 6 months, it is critical that you are. If you succeed, the next time you need to convince someone of something counter-intuitive, you’ll have more credibility in the bank, so it will be easier. If you fail, the next time will be even harder. It’s a cumulative thing. Each success or failure affects your credibility balance.

In order to deliver, you need to protect your schedules. I call it Risk Management and it’s your #1 job as a software project manager. Since statistically most software projects fail (70%), you’re inherently on the defensive anyway, so you need to think like everything is a possible risk. One of the best techniques you can use to protect the schedule is to build-in time for all of the things that typically throw software projects off the rails. Things like: Time Estimation Error, Distraction Rates, Overhead, Requirements Churn, etc.

In order to protect your schedule and the “padding” you’ve put in, you’re going to need a solid rationale as to why that particular % of time was chosen, and what factors you’re padding for. Otherwise, when you go up against a professional negotiator (like a Sales person), you’re going to walk away having been talked out of your padding. And while simply “refusing to give in” is better at protecting the schedule than giving-in, being able to convincingly articulate what you’ve padded for and why you chose the amounts you did is even better. It protects the schedule and builds your credibility at the same time.

Never use your “gut” as an unsubstantiated argument. You can talk about how good your instincts were after-the-fact, but it’s not very convincing up-front unless you already have a huge credibility balance. While I’m a big believer in using your instincts as one of the data points in decision making, it’s best to figure out a way to prove or disprove them anyway. If you disprove a gut instinct, you save yourself a costly mistake. If you prove it, you gain more credibility anyway, so it’s a win-win.

Be an obsessive note taker. Most people don’t do this. It takes discipline to get in the habit. In the moment, it’s hard to know which decisions or facts you’re going to need as corroborating evidence later, so write them all down. Any time you can point to written historical evidence of decisions that were made, when, and by whom, you’re going to have a psychological advantage in getting your point across. People regularly (and conveniently) forget how often they’ve changed their minds on their priorities, or a feature list.

Use metrics. Figure out what metrics you think are important for your type of project and track them. Whether it’s the rate of change for requirements, or how often time estimates are wrong (and you are therefore padding for that fact), nothing backs up padding in the schedule like stats. It’s hard to argue that a 30% buffer in the schedule is too much when you can point to statistical proof that developer time estimates are off by 30% on average, over time.

Hopefully some of these tips will help you incrementally increase your credibility balances. Unfortunately there’s no overnight solution, but with discipline and a structured approach, you can do it.

If anyone has any other tips or tricks on the subject, I’d love to hear about them. Please post a comment.

Trick Question: Could You Manage a Space Shuttle Launch?

2005-11-14T10:46:00.000-05:00

A few months ago I spent a couple hours with a project manager who by all accounts, is rather good at her job (I know several people that know her professionally and did some background checking). We were discussing domain (software) specific project management techniques, like tracking Time Estimation Error, Distraction Rates, and keeping requirements in-sync with schedule. As our meeting was ending, she mentioned that someone had asked her a while ago whether or not a good project manager (or a project manager with a good project management methodology) could manage any type of project – like a space shuttle launch. She quickly said yes, because the basic elements are the same in any project. It occurred to me on the drive home that this is not an uncommon belief – that a project is a project is a project...

So – why we are we (the project management discipline at large) so terrible at running software projects specifically? It’s a well known fact that the majority of software projects globally are considered failures (Standish Group’s Chaos Report) – failure being defined as: late, off-spec, and/or over budget. If general purpose project management methodologies aren’t making software projects slam dunks, then either the methodology isn’t all it’s cracked up to be, or there’s something about software projects in particular that continues to trip us up. I say both.

Here’s a trick question. I will read all sorts of things into your answer to this question and tell you about them in a minute: If you were the head of NASA, responsible for choosing the project manager for the next space shuttle launch, and you had 3 candidates to choose from, which would you choose? Here are the candidates:

“Newbie PM (Project Manager)” – has accreditation from a leading project management school; graduated top of class; knows the PMBOK (Project Management Body of Knowledge) like nobody’s business; can quote the process to you word for word; never managed a project.

“General purpose PM” – has accreditation, and has 10 years experience managing all sorts of projects (but never any 2 of the same type); sample projects ranged from: building a new home, a Windows 2003 server rollout, a training program for a new software system in an organization with 10,000 employees, planning a sales conference, etc.

“NASA veteran PM” – has accreditation, 2 years experience managing a variety of projects (similar to candidate #2), but has been managing space shuttle launches for the last 6 years.

Which would you choose? You’d probably want to know their track record too, but for the purpose of this little game, that information is not available. I’d bet dollars to donuts you’d pick #3 – the NASA veteran. But if you also started this article thinking that with a good process you can manage any type of project, then something is at odds – those 2 opinions are inconsistent with each other. If you truly believed that the process was the key, then technically any of those 3 candidates should do fine, because they all have the process down pat (the accreditation). And candidate #2 actually has more years experience overall. Reading between the lines, here’s what I think is going on:

Managing isn’t a true/false binary thing. Of course you can manage any project with any project management methodology, but the real question is: what would your success rate be? If you chose candidate #3, it’s because your instincts told you that experience with that particular type of project (a space shuttle launch) counts for a lot. Most people would intuitively believe that candidate #3 has something above and beyond the other 2 candidates.

Most project management methodologies are general purpose. For whatever reason, they continue to embody the opinion that all projects are the same – and should be managed the same. They are specifically designed to take the human element out of the equation – to say that anyone following the process can manage a project well – it’s the process that counts. For software projects en-mass, this approach clearly isn’t working, as evidenced by the poor success rates.

Today’s project management methodologies are useful for teaching someone the ABC’s of project management. There certainly is a lot of useful stuff to be learned. Unfortunately, there’s also a lot missing. Just like in school, consider that the typical project management accreditation is like a Bachelor’s degree. And we all know how dazzled prospective employers are when we tell them that we have a Bachelor’s degree right? Well, maybe not so much. Current project management methodology is the scholastic equivalent of reading and writing. You may need it, but you only learn the good stuff after you learn to read and write.

The real power (of success) – the advanced stuff - comes from some degree of specialization. If you want to go beyond the basics of project management, and hike up your success rate, you’ve got to focus on a particular type of project. Most of us do at some point in our careers anyway, because the organizations we work for are somewhat specialized: IT, Construction, Legal, whatever. What isn’t typically specialized however, is the methodology we use to manage those different types of projects. Our organizations specialize in some type of business, we specialize in some kind of project, and then we go use a general purpose methodology – no wonder software projects are late most of the time.

Specializing a project management methodology simply means looking for factors that typically affect a certain type of project (example: software projects), and modifying the methodology to account for those factors. (This is another way of saying: leveraging domain specific experience.) For software projects, some of the top factors that throw them off the rails are:

Time estimates are wrong – granted it’s difficult to produce accurate estimates, but few actually try anything more scientific than gut feel estimates, so we haven’t quite exhausted the possibilities here.

Distraction is rampant – software projects are long term (6 to 12 months) by nature, and are planned to have teams work on them near full-time, but the actual amount of time they get to spend on them is typically far less than near full-time; such is the nature of business.

Requirements consistently fall out-of-sync with schedules – we’ve somehow convinced ourselves that we can continue to evolve requirements and designs all the way through the project, but somehow the initial (gut feel) time estimate should stick.

If we know that these are the biggest common factors that throw a particular type of project off the rails, then what have we done to our methodology to account for them? Not much. Typically, most project managers of software projects are still trying to get away with that plain vanilla (“goes with everything”) project management methodology. It’s never going to work. It’s only half the solution.

Veteran project managers that have a high success rate typically use domain specific tips and best practices to run their projects. They’ve developed their own checks and balances to alert them when something is sliding off track. They’ve learned over the years, what the common factors influencing their particular type of projects are, and how to manage them effectively. Mostly, they do it in their head – they rely on experience and intuition to side-step the common pitfalls. For example, a veteran software project manager keeps tight control over requirements and schedule – keeping them constantly synchronized. He or she knows enough to take developer time estimates and pad the heck out of them, because there is typically an error margin with them. He or she also knows that on any v2 of some project, there had better be some time built in to fix bugs from v1, based on experience.

It stands to reason that these domain specific habits of the successful veterans would be of tremendous value to all other project managers in that particular domain. The trouble is, currently, it takes years to develop that experience and success rate. Wouldn’t it be great if this stuff was sharable, given to each newbie project manager in a particular field, and more widely and explicitly adopted? I think it would have a dramatic impact on the software industry’s track record as a whole. In fact, wouldn’t it be great if that acumen, those tips, tricks and experiences were built into your project management tool so that tracking, trending and reporting on all of it was automatic?! (Blatant plug: My company[Devshop.com], still in stealth mode, is working on a solution to this very problem – stay tuned!)

If you want to improve your success rate with project management, specialize. If you’re taking on projects of similar types (all software projects for example), don’t automatically look to more accreditation or general purpose PM methodology for the answer. First look for the patterns that throw your particular type of project off the rails, and manage those factors first.

Customers don't buy "solutions", they buy products and services. May the best products and services win.

2005-11-02T19:58:00.000-05:00

Several years ago, I remember being enlightened by some Marketing folks about "solution selling". The idea is that there are some strong advantages to elevating the discussion with prospects from simple feature lists and head-on comparisons with other products, to the broader topic of which "solution" is better than the other "solutions". See, a "solution" is fuzzy concept. It's really hard to quantify a solution, or say with certainty that one solution is better than another solution. Unlike feature lists. With feature list comparisons, one product typically comes out quantifiably ahead. Not good if yours is the weaker product. And so for many companies, solution selling became a great way of taking attention away from the feature lists (where they didn't look so good) and also made them feel like they were taking the high road. "Oh, Mr. Customer, feature lists aren't important. Look over here."

Over the years, I allowed myself to be convinced of this tidbit. After many years of working in the enterprise software space, I've come full circle and no longer believe it. Customers don't buy solutions. They buy products and services. The reason they buy products and services instead of solutions is that in the buying cycle, they typically only hook up with a prospective vendor after they've gone through the first few steps:

Feeling the pain of some problem

Understanding what that problem is in broad strokes

Looking around to get at least a light understanding of what some of the categorical solutions may be

Choosing the most suitable "category" of solutions

Begin researching products and services in that category

For example: If I have the problem of not being able to get everywhere I need to go with the two legs I was given at birth, then I don't start looking around for a "transportation solution". I already know enough about the various categories of transportation options (bikes, cars, buses, motorcycles) to weigh the various pros and cons of each, without ever talking to a vendor. If I settle on the idea of a car, then a bike vendor is going to have a real tough time convincing me I should go with a bike instead of a car. But, I've still got several car vendors and products (and services) to choose from, so there the selling game begins. Either I approach a handful of vendors on my own, or they "pull" me in with various advertisements, cold calls and free x-boxes with the purchase of every new vehicle. By that time, I'm a qualified lead. I'm not so much looking for a conceptual "solution" to my transportation problem, I've already narrowed it down and I'm now looking for a product or service with which I can solve my own problem.

Sales people know that it is way too costly and difficult to "create" demand. They land more sales and get bigger commissions by seeking out prospects that already have demand, and have determined what kind of "solution" they need. They are now at the product (or service) comparison stage. Now it's your product vs. the other guy's.

Besides. If a legitimate business problem is "we can't keep track of each time we interact with a customer", then most businesses figure out on their own that a CRM system is a categorical solution, and then enter the product comparison stage all by their lonesome, without the CRM company having to do too much to convince them that they actually need to keep track of all their customer interactions in the first place. And as further proof, I submit to you: When's the last time you saw a contract or invoice that read: "Ability to keep track of all customer interactions = $50,000". No, but many read:

Server license: $10,000

User licenses: $30,000

End-user training: $5,000

Telephone support: $5,000

There we go. They bought products and services. Not a solution. It's the things that appear on the invoice and in the contract that they actually bought. Not what problem they intend to solve with those things.

The reason this is significant is because it informs some strategic decisions for software companies. If you're selling a "solution", you're probably one of those companies that doesn't put a feature list, sticker price, or screen shots of your product on your web-site because you feel it cheapens you. You expect prospects to call you to ask to get a demo from sales rep that's going to hound them until they either buy or tell them to bugger off. I can tell you from experience, droves of possible customers will turn away without going past your front page if there aren't clear links to some or all of those things prominently displayed on page 1. The reason is, they don't need you to tell them what their problem is or what the solution is. Rightly or wrongly, they already believe they know, and now just want to easily compare your product (or service) to someone else's. I really can't see why hiding important information like that is a smart move.

In the last year I've gone looking through several product categories: Project Management software, Content Management software and Web-site Tracking software to name a few. Those companies that thought they were selling me a "solution" to "knowing my Web-site visitors", "creating predictability for my projects", or "consistent customer service" and hid their key feature lists, screen shots and price from me, didn't get more than 5 seconds of my attention. I don't have time to call a sales rep for each of the 20 products I want to have a peak at. Nor do I want to give you permission to keep emailing me or calling me just because I asked you how much your product was or if I could see some screen shots. If all of that kind of information is hidden, then I proceed to assume: it's too expensive, too hard to get started, and I generally won't like the product.

All this to say, put the focus where the customer is going to put it. On the product. What does it do? How does it do it? Is it easy to use? How much does it cost? What's better about it than the competing products? The one exception to this rule is if you're in a space that is so entirely new that consumers in general haven't even figured out that they have a problem yet, or what any possible solution may be. In which case, you've got a lot of education to do before you can sell anything, and I don't envy you.

It's not that I'm advocating your message and materials should only consist of a price and feature list for comparison shoppers. But somewhere in between the two extremes of completely abstract solution selling, and totally comoditized selling of a bag of features, lies a happy medium, where the focus is still on the products that solve the problem. Being "product" (or service) focused with your messaging doesn't just mean you're a list of features and nothing more. In fact, many times, products with less features are better than their bloated competition. The magic is how those features (I prefer capabilities to features) are sewn together in ways that are more useful, valuable or easier to use than the competition. Those things translate into competitive edge.

The funny thing is, I hear from several Marketing folks as they flip through product web-sites, particular technology companies' sites, a snort of contempt: "They're all so product and feature focused. They don't understand solution selling. They need to elevate the discussion." Actually, I think they just know their audience and want to make it real easy for them to make a qualified decision. If your product is weak, then invest in making it stronger - don't go hiding it from plain site behind a lot of abstract "solution" talk. Stand by your product, and at the end of the day, may the best products win.

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

2005-10-28T19:16:00.000-05:00

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.

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

2005-10-24T09:10:00.000-05:00

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

2005-10-24T09:06:00.000-05:00

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.

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

2005-10-19T09:39:00.000-05:00

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.

Managing Distraction

2005-10-17T06:26:00.000-05:00

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.

Think like the customer. You are not the customer.

2005-10-04T06:33:00.000-05:00

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...

The Cost of Late Software

2005-10-03T07:18:00.000-05:00

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!

Building it Front-to-Back

2005-09-27T07:14:00.000-05:00

Wow. I wish I'd tried this sooner. Conventional wisdom in software development says that first you design your architecture, then you lay the foundation, build the back-end, and somewhere near the end of your project, features start to bubble up through the user interface (UI). Maybe it's because we keep comparing software development to construction, where first the foundation goes in, then the framing, and the color of the paint and countertops doesn't even need to be decided until the very end. I'm not sure.

How many times have you experienced this: A gaggle of developers working feverishly for months, all the while, stakeholders asking, "Can we see it yet?" "Nope.", comes the reply, "We're still building the system that the UI is going to sit on top of." Then, one day, "Tada! Here's the UI!" "But that's not what we wanted!" Oh oh. (Or best case, the UI is functionally sound, but looks like ass because you're too pressed for time to polish it up and make it esthetically appealing and ergonomically friendly).

I never really thought to question it before. Not until I had the complete freedom to try it a different way, without having to fight to convince anyone that doing things in reverse might actually be a better way. I'm building a large system front-to-back right now (user interface to data storage), and am thrilled with all of the benefits this approach is offering.

Most people in development know that the last things on the project schedule are the things at most risk of being cut in a time crunch. Most development projects see the bulk of the user interface being developed after all the system work has been done. But the user interface is the only thing the customer sees - it's what they buy. See the problem? You're leaving the most important thing to last. This is way too risky, for you and your customer.

The idea that you can reduce an application design down to a bunch of nicely written Word documents is nice, but not realistic. Try and try again, with this approach, it'll never match having a living breathing example (UI) of what you're building, while you build all of the system architecture level things that no-one else gets to see but us developers.

Not that you shouldn't spend a really sizable chunk of time designing and building your architecture. (See my last post on architecture). But rather, the architecture should be derived from a living mockup, or UI design. Not just screen caps (not enough), and not necessarily a full prototype (too much, and too likely to get thrown into production), but something in the middle.

Here's the steps I followed with my current project (a web-based modelling tool, built to be hosted ASP style; = large scale deployments):

Started in Excel: 'cause it's a data modelling type tool, so I wanted to layout the main tables and views that people would have available to them

Moved to Photoshop: to put some lipstick on the pig and make it look pretty (don't forget, esthetics sell)

Got feedback on the concept - Was the concept right? How does it look? Good. Ready to proceed.

Moved to HTML/CSS/Javascript: This step might be unique to me, but I really wanted to have the richness of the desktop in my web-based application (drag/drop, inline editing, etc.), so I built a bunch of re-usable, cross-browser Javascript controls for this and demonstrated them on a few sample pages of the application

Got feedback on the interactivity - how does this behave compared to regular web-apps? What do you think? Good. Ready to proceed.

Moved back to PowerPoint: I wanted to mock-up every single screen in the application so that I could get feedback and make any changes quickly without having to rip-out months worth of coding. PowerPoint is great for UI design because you can throw in image pieces and move them around with text and rectangles quickly. And with one-slide-per-screen, you can still have 60 screens in one file, with annotations, printer-friendly, and sharable.

Got feedback - How does the functionality set look? Anything missing? Anything wrong? Good. Ready to proceed.

Implemented each screen in HTML/CSS/Javascript: At this point, I took the time to do some "real" development. Not hacking, not prototyping, but the real take-the-time-to-do-it-right design and development, but ONLY for the UI. The goal was to have every screen built to do nothing but show dummy data and move around to the other screens.

Got feedback - This was the single most important feedback stage, and allowed me to get the detailed kind of comments that would only otherwise be available at the end of a development cycle (when it's too late), because the application "appeared" to be complete, from the user's perspective - just that it was all dummy data. At this point, beyond looking at screen caps, they could actually click around and "use" it.

Business Logic and Back-end: Now things start to look like a normal development cycle from here-on-in. Do your architectural design, but this time with a living specification staring you in the face (one that the customer has actually approved), and proceed to implement it.

With this approach, I've pretty well eliminated the risk that the product won't match customer expectations because they've actually been able to see it and play with it before I go do the lion's share of the development. Not only that, but now that I'm building the back-end, while I still want to build a somewhat future-proof architecture and be fairly generic with it, I have an extremely specific, living example of the application I ultimately want to build with it.

Some might call this rapid prototyping, but there are a couple important differences:

Only the UI was mocked up: do we really need to demonstrate that we can read and write from a database? No. Skip that stuff. Just mockup the screens and connect them so the user can get a feel for the navigation. Populate the screens with dummy data.

There was nothing "rapid" about it: while the PowerPoint mockups were done quickly, they could also be changed quickly. When it came time to move the screens into HTML/CSS/Javascript, it was solid development practices the whole way. Not prototyping, not throw-away, but solid design and re-usability. This was production UI code.

While the goal of this approach was similar to one of the goals of Extreme Programming (get the customer in early), I think the approach is stronger because while you get all the benefits of the user being involved early on to validate what you're doing, you don't have to sacrifice the benefits of solid up-front design for each tier (UI, Biz Logic, Data Storage), by making it up as you go along and trying to convince yourself you can re-factor quickly.

I can't tell you how useful this front-to-back approach has been. Virtually all of the requirements and design unknowns have been squashed, and makes building the back-end a dream. Descreased risk, increased predictability, increased quality.

This approach definitely took more time upfront than a "document only" approach to design, but I believe the time saved later, and the risks mitigated make it an exceptional investment. I would highly recommend it to anyone.

How to Explain Good Architecture to the Non-Techie

2005-09-22T11:44:00.000-05:00

How many times have you tried to explain the importance of good architecture to one of the many stake-holders in one of your software projects? Could be from sales, or marketing, or even your boss, depending on your company. If you have, you've probably seen their nose wrinkle, or their eyes glaze over. After an honest attempt to make them see the light, you probably got frustrated and thought that they just don't care, or just don't get it - and never will. The frustration that both of you feel actually creates a kind of tension and over time, this lack of being able to relate to each other makes it more difficult to be shooting for the same goals.

Wise people say that to be a good communicator isn't about having any particular mastery of the language, or about demonstrating through over use of industry jargon how incredibly smart you are. It's about being able to put yourself in your listener's shoes and hear what they hear - or, simply about relating.

Although I've been managing software teams for many years now, it finally just occured to me while walking the dogs at lunch, what good architecture is all about, and how to get the point across to your non-technical peers. Like many, I intuitively knew what it was, but couldn't quite nail the explanation when trying to describe it to a non-techie.

I'm a firm believer that good architecture is actually a pillar of a successful product company. It's just that it's not for reasons you would necessarily think.

It'll sound a bit funny at first, but stick with me: Good architecture has nothing to do with the quality of the product you're building. You can have a product that customers absolutely adore, that is about to fall over dead tomorrow if one more tiny little feature is added to it because nobody can see the house of cards it's built on, except you. Customers don't buy architecture (unless your product is a platform, then they do). Even if your product is extendable through some API, they still don't care too much about what goes on under the covers. Customers buy a solution to a problem. Even if the problem is simply that they're bored and they're buying a video game to amuse them (problem solved). They buy features, benefits, and capabilities, but they don't buy architecture.

Good architecture is not about the product. It is about operational effectiveness. Ahhh, now your boss is listening. It's about being able to react more quickly to customers and the market, even the competition. Ahhhh, now Sales and Marketing are listening.

Understanding good architecture comes from understanding the symptoms of bad architecture, and knowing that good architecture prevents those symptoms. So. Bad architecture: Can't scale the system up; can't increase performance; can't make it easier to install; can't add any more features because of the unforseen conflicts they create with existing features; takes too long to fix bugs and add what new features are possible. Most of these things are about the company's ability to innovate, to react quickly to threats, to support their customers, to solve problems, to add new features, and to pump out new products.

A good architecture can get you: faster turnaround time on fixes and new feature development, more flexibility for supporting customers, a stronger ability to compete in the market place, etc.

The difference between a good architecture and bad architecture can often affect each of those symptoms by as much as 2 or 3 times. It makes the product team more effective at doing their jobs, even multiplying their productivity in many cases. Good for the team, good for the company, good for all the stake-holders.

Those are things that your stake-holders care about. And hopefully, this is a way to help get the point across.

An isolated occurance might be managable but a trend can kill you.

2005-09-19T06:45:00.000-05:00

Suppose you're running a software project and a task that was originally estimated to take 5 days actually took 8 days (60% longer). What impact to the schedule might that slip have?

The intuitive response is to think that the person that owned that task is now 3 days behind schedule. The intuitive response would be wrong. If managing software projects were that intuitive, the global failure rate on I.T. projects wouldn't be 70%.

Worse, it might be tempting to think that there is no impact, because that person can make up the 3 days later in the schedule. (If you ever convince yourself of this in a software project, go stand in the corner and think about what you've done.)

Here's the not-so-intuitive "real" story on that 3 day slip:

Firstly: We can make up those 3 days later. Really? You mean there is 3 full days in the schedule where this person is supposed to be sitting on their butt doing nothing, and we'll just use those 3 days to make up for this slip? No way. 9 times out of 10, a slip like that is not recoverable just by "willing" it to be so. If you actually do have buffer time to account for slips like these, pat yourself on the back. (But hope you have enough buffer to account for this sort of thing repeating itself.)

Secondly: Working overtime probably won't help. Do you know what it takes to make up 3 full days working overtime? Best case, suppose someone could work an extra half-day each day (4 extra hours). That's 6 days, more than a week, of working a day and a half shifts. If they can only sustain 10 hours per day (2 extra hours per day), then that's 12 days (over 2 weeks) of overtime to make up for a measly 3 day slip. Overtime makes up for schedule slips at a surprisingly unhelpful rate, and burns people out at the same time. Not to mention the poor quality code they produce while seriously demotivated and tired - poor quality code that they'll have to come back and fix later with, what... More overtime? And, while working overtime to correct for one slip, chances are that something else has slipped that will require even more overtime after that. Eventually the whole schedule just blows up.

Thirdly: Even if you re-jig the schedule so that the 3 day slip doesn't seem to hurt the product at all, what will you do with the next slip, and the one after that? Because unless this is your first software project, this isn't the first slip, and it won't be the last.

Finally: Don't you dare go reduce the amount of time scheduled for some future task unless you actually reduced the amount of requirements for that task. Otherwise, you've just swept the problem under the rug for now and it'll come back to bite you twice as hard later.

Crap. So, now what? Stop looking at a slip as an isolated occurance. What ever caused the slip, however it might appear isolated and unique, it is in some way part of a larger trend. Whether it was an error in the original time estimate, or the fact that this person got pulled off the project to go do something else for a while (a distraction), these things tend to repeat themselves if not managed as a trend.

The differences between an occurance and a trend are their perceived impact and the way you deal with them. The impact of a 3 day slip might seem small and recoverable, but if it is part of a trend (say every 10 days worth of work, there's a 3 day slip), its impact is much larger. An isolated occurance might be managable but a trend can kill you. 3 days is nothing, but 30% on a 6 month schedule is almost 2 months.

If someone on the team was off on a time estimate by 30%, what do you think the chances are that every other time estimate this person has given will be 100% accurate? Not very good. By the time someone has completed a few tasks, there's enough data to predict a trend that can have far more impact on your schedule than an isolated occurance, but thankfully is also easier to manage because a trend is more predictable.

The same goes for any time that this person may have been taken away from the project to go do other work. Was this the first time? Do you think that it could ever possibly happen again? Probably. By the time it happens a few times, again, there's enough data to form a trend.

So, if on average, tasks are slipping by 3 days for every 10 days worth of work, the pace of the project is off by 30%. By thinking about this as a trend instead of an isolated occurance, your approach to solving the problem is likely different. For an isolated occurance, you may be tempted to crack the whip and just try to get people to work harder or longer to make up for the 3 days slip. But as soon as you recognize it as a trend, you know that will never work - it's not sustainable. Your next option should be to re-cast the schedule, but this time you've got some real data (say, average Time Estimation Error or Distraction Rates) to pad the schedule with, thus negating the effects of the trend. Each trend that you spot and measure, gets some padding. Problem solved - well, immediate problem solved. You may still want to then attack the particular trends that are tripping you up in the first place, like improving your Time Estimation Error rates or reducing the Distraction Rates, but at least your project will be insulated from them while you figure out how to improve the trends themselves.

Better yet, if you tracked the trends from your last project, then you've already built them into this project schedule right? If not, then you should have enough data after the first month of a 6 month project to extend the trend over the balance of the project to figure out what its impact could be.

The software wasn't late, it was supposed to take that long

2005-09-14T07:17:00.000-05:00

Over time, new words keep getting introduced into the English language. It may take tens or hundreds of years of people using a particular term, but if it’s used enough, eventually it gets put in the dictionary. My spell-checker keeps telling me that verticalize isn’t a word, but enough business folks use it that I’m pretty sure some day it will be. Another term I think has a shot is: thesoftwareislateagain.

For the past year and a half, I’ve been working on a solution to that very problem. Unfortunately I can’t tell you about it yet because my company is still in stealth mode. But it is a multi-faceted solution, with one significant piece of the equation being time estimation.

People keep calling the software “late”. Of all the times we perceive a software project to be late, I submit to you that only half the time it actually is late. A software project can really only be late if it took longer than it should have. That “should have” part implies that we have some divine control over the duration, and we decide how long something should take like we decide what color it should be. Hate to burst the bubble, but we don’t. If a software project’s requirements (what it needs to do) and designs (how it’s going to be accomplished) stay reasonably fixed during the life of the project, and the team and platform are truly qualified for the job, then the duration is what it is. Our job as project managers (and developers) is to figure out that duration ahead of time - accurately. We estimate how long it should take – we don’t decide it.

If it didn’t ship on time and it wasn’t late, then what is it? It was estimated wrong. It’s that simple. If all other variables about a task were reasonably fixed, and it wasn’t done when you thought it would be, then it was estimated wrong. As a rule, we tend to underestimate things a lot. Software development in particular is difficult and complex (at least, to produce good software is – banging out crap is easy). That makes time estimation hard. Too hard to do with hallway conversations and incomplete requirements.

Most people think if a task was scheduled to take 10 days but really took 15, that it was 5 days late. In most cases, it wasn’t late, it was supposed to take 15 days. It was just underestimated by 5 days. Assuming everyone was working at capacity, and even if there were unforeseen technical difficulties along the way, the original estimate of 10 days was an illusion. The real duration of the task was 15 days, not 10. This is an important distinction because it determines your choices for action. If something was late, it’s tempting to start looking for ways to “make people work harder”, which often isn’t the solution. The only bad thing about the task taking the 15 days was that you thought it would take 10, so you planned around it. Then other parts of the organization got screwed up because you missed some deliverable to them. If you knew ahead of time that it was really going to take 15 days, there likely wouldn’t have been a problem. By shifting your thinking to time estimation instead, you can correct the problem at the source and insulate the rest of the organization from these costly inaccuracies.

People all over software-land would be better served by doing more of the homework upfront, so that their time estimates are more accurate. We've all heard the stories of big shaggy software projects never getting off the drawing-board because of too much design up-front. Does that really apply anymore? Seems to me that today, the trend has reversed. People rush ahead without knowing what they're trying to build. How the heck do you estimate the time required for something you haven't even written down in detail?

The power of suggestion

2005-09-13T14:50:00.000-05:00

Big fat books have been written on the subject of delivering software on time. Expensive courses are offered. You can actually go get your Masters Degree in Project Management. The success rate of software projects still stinks: sitting somewhere around the 30% mark.

I don't know of any other kind of business project that fails as often as software projects do. The strange thing is, people in the biz seem to know why they get off track, they just haven't figured out what to do about it! If you ask anyone in the software biz why projects fall off track, they'd tell you:

- Changing requirements
- Bad time estimates
- People getting pulled off the project to go do other work
- Etc.

If so many people know the text-book reasons that software projects run off the tracks, then why the unbelievable failure rate?

I think it's the power of suggestion. People want to believe they can get it done faster than they really can. They want to believe that they can keep playing with requirements after the schedule is set and the developers are off to the races, and they want to believe that the software keeps getting built even while the whole team is taken off to go help the Sales department figure out their new CRM system. So they keep telling themselves, "I think I can, I think I can...", until they actually become convinced of it.

So countless software project managers run off trying to come up with a Gantt chart that, while structurally sound, has no chance of ever being implemented on time. They've fallen victim to the trap of drawing out what they want to believe will happen, rather than what statistics and experience should be telling them will actually happen.

The tools don't help either. They say that people that give-in to addictive personalities are called "enablers". Like, if you take your alcoholic friend to a bar, then you're an "enabler". You're supposedly partly to blame for your friend falling off the wagon (or is it jumping back on the wagon again? I can't remember). If that's the case, then today's project management tools are enablers of bad schedules and failed projects. They show you want you want to see, not what will actually happen. Tsk. Tsk. Those pesky tools should know better. Countless failed schedules have been typed into those bloody tools and a few good ones too. You'd think by now they'd be able to stop you from making the same mistakes over and over again, by saying, "Ahem. Did you think about this?", and, "Um, I can tell you from your history that this schedule is just not going to work. Try this, that and the other."

What we really need are virtual project management Nanny's that slap us when we forget to build in vacations, sick time, holidays (the basics), and coach us with their vast historical references by telling us that on average, Suzy Queue is off her time estimates by 30% and Little Boy Blue always gets called off the project for at least 5 days each month to go help lead customers - so build that into your schedule! Reading a book once and subsequently forgetting it doesn't work. Neither does going to that annual conference in Las Vegas on Project Management. It's got to be in the tool, in your face, all the time.

We want to believe so badly that we suppress our experience and in some cases, actual historical data from our own environment so that we get the Gantt chart that makes us all feel good. Unless it's staring us in the face every time we look at that Gantt chart, we conveniently overlook the things that kill us every time.

If only there were such a tool. Wouldn't that be nice.