Bill Gates’ Exit Interview

Have you seen the Channel 9 interview with Bill Gates?  The link is below.  The interview is about a half-hour long, and focuses on Gate’s plans for the future as he transitions out of Microsoft and into his philanthropist foundation to help the poor.


Here are some quotes I found interesting.  These are the kinds of lines that drive my own thinking.  They drive me to fight for our brand position in the marketplace.

You’ve got to have product plans for every product you expect to release in the next few years.  And those plans have to be very realistic.

 Making sure we take some risky bets.

We are a very self-critical culture.

Software seems to be so complicated…  Software has some composability today…  But we have to make it easier to write big software.  We’ll have a lot more progress in the next decade.

 It’s always surpring to me there’s little attention paid to what we are doing for business users.

We care about the information worker.

We’re always sharing about where were going so people can make plans.


Best of luck, Bill.  Care to comment on the Channel 9 interview or this humble post?  🙂


Why IT Projects Get Killed

I like CIO Insight.  They seem to hit a lot of relevant issues.  Their “Why IT Projects Get Killed” is a short slide-show with a simple breakdown of the top five reasons IT projects get killed.  A link to the article is below, and I’ll comment on the top reasons.


  1. 30% Business Needs Changed
  2. 23% Does Not Deliver As Promised
  3. 14% No Longer a Priority
  4. 13% Exceeds Budget
  5. 7% Does not Support Business Strategy

Well, that’s only 87%.  I suppose the other 13% fall into the “Other” category.  I’d like to take a crack at interpreting the numbers.  Here are my thoughts on why IT projects are killed.

30% Business Needs Changed
From the time a project is first proposed until it is started, things have changed.  These are often projects tightly connected to cultural events.  For instance, your proposal for a new drive-through pharmacy may lose 7% of its expected revenue if the price of gas goes to $5.  Anything that tightly connected to consumer behavior must be watched closely.

23% Does Not Deliver As Promised
Oversell and hype.  Lots of people do it, and lots fall for it.  It always surprises me how pessimistic people are when investing money, but how easily they fall for a good story.  Almost a quart of the projects don’t live up to the promise.  But it’s not jsut hype that contributes to this number.  Sometimes people simply don’t realize how big a project is when they start it.  That’s understandable.

14% No Longer a Priority
This feels like reason #1.  Business needs change, and the project is no longer a priority.  But I suppose there other reasons a project may no longer be a priority: Can’t make money at it, Other solutions have arisen to replace it, Employees or customer have changed.  But still…  aren’t these all “business needs.”  If so, a full 44% are canceled just because “things change!”  Yikes!

13% Exceeds Budget
I expected this to be higher.  Most people I talk to go over budget on their projects.  That’s why they use products like Standard Time®.  They know they’ll be cancelled if they go over .  Well, maybe it’s doing its job!

7% Does not Support Business Strategy
This happens when unlearned individuals go off on exciting missions that the executives don’t support.  A project gets started, but killed soon after – once it’s discovered to be nonsense.  I’ve run into quite a few of these individuals.  But I don’t fault them; they try.  And that’s all the CEO really expects of them.



Ready to Release?

How do you know when your product is ready for release to waiting fans?  Does it have what they want?  Is it high enough quality?  Will it crash and burn, costing you thousands of dollars?  Tough questions.  Unfortunately, there are no great answers, but consider the following factors.  They may help.

Keep it foundational
There’s always a temptation to boil the ocean with your grand scheme.  To have the best product in your class.  After all, you’ll never make money without it.  But this is a trap.  Great products take years to develop, and if you wait that long, you’ll never get a foothold in the marketplace.  It’s far better to get started early with a foundational product, and constantly improve it.

Listen to customers
Every feature in your product should come from customers.  Don’t invent stuff yourself unless you are certain it’s the next great thing, and then still don’t.  Chances are, you’ll have a tough time selling pipe-dream features that customers don’t ask for.

Always ready for release
This only applies after you have already released the product at least once, and applies best to iterative products like software.  Never dive so deeply into new features that you can’t release the product at least once a month – even when doing major upgrades.  Release the product frequently to beta testers and trusted customers, but don’t let it stay “down under” too long.  This keeps the bug count lower, and keeps you closer to customer input.

Test twice, and twice again
If you’re like most engineers, you’ll spend half your time polishing and fixing bugs.  But many don’t realize that.  They want to blaze new trails and invent new things – all the time.  But you can’t make a living like that.  Be patient with your product, allowing it to mature into a robust system.  Don’t walk off until you are sure it is.

Good luck with your release, and let me know how you made out.  🙂



Death by Distraction: 3 Ways to Avoid it

A huge number of projects, usually small ones, die ugly drawn-out deaths simply from distraction – and nobody knows.  Yeah, people get distracted and forget them!  It’s true, I’ve seen it happen dozens of times.  Here’s how it happens. First, the big boss decides he wants something.  A new product or policy.  A new way of doing things.  An improvement in procedure.  He’s sure it will save the company money, so he launches a new initiative (a project) to get it.  He assigns it to one of his people, and expects to hear some status in a while.  FIRST MISTAKE! The employeee may have no strong allegence to the new initiative, and gets distracted and never completes it.  He’s bored, and doesn’t want to mess with it.  The boss forgets he asked, and the project is effectively dead.  Every seen that happen?  That what I thought…  So, how do you fix it?   Tip #1: Document it. If you don’t write down your project initiatives, they can easily be sabotaged by bored employees.  If there is no record of them, employees can safely ignore them without any consequences.  And they will.   Tip #2: Don’t pile on. Giving your employees too many projects means they won’t do them when asked.  I’ve seen managers throw so many projects at employees that they simply ignore them until asked later.  If the big boss never asks, he must not want it badly enough.  They simply wait him out and deal with only the important ones when he asks.  Yikes!   Tip #3: Reduce the chain links If Joe is to do the job, but needs input from Britnney and Travis, and they can’t get to it until Keyshawn obtains his status from Lisa who gets her materials from Joe, you may never get anything.  Don’t believe it happens?  It does.  There are sometimes so many links in the project chain that the effort fizzles out, simply because one person can’t get what they need.  Of course, they never bother to find out why, but you need to realize this can happen.   Bottom line: you need a project champion who walks everything through its paces.  If you’re the big boss, that may be you.  No champion?  Well… chances are the project will die of distraction. –newshirt

An Ounce of Inspiration

I suppose it’s no surprise, but I for one, perform better when under the influence of inspiration.  My projects just flow when I am driven with excitement to complete them.  I don’t even have to ignore the boring aspects of the project; I just fly right over them as if they didn’t exist.  But without that inspiration, it’s sometimes a drag.

Okay, that’s me.  Now, how do you get the entire team motivated like that?  All at once?

Clearly the answer lies in goals that every one shares.  Fame, fortune, accomplishment?  It’s different with every project, and every person.  The key is to find common ground that everyone can get behind.

I remember the old MacPaint program on the early Macintosh’s.  All the author’s names were in the About box.  Those guys met in Andy Herxtfeld’s home, and pounded out the next great thing: Fatbits!  But there’s no simple formula for every project team and every project.  In other words, you cannot simply offer comp time or best-employee certificates for every job.

Years later, names in the About Box isn’t enough.  Been there, done that.

Eventually, people grow weary of simple incentives.  They need big “life incentives” that mean something to their lives.  They need to know their efforts are making a difference in the world.  That people recognize their work.  Yes, it takes that much.  Nobody wants a shallow life.

How do you inspire your team, all at once, to change the world?


Project Tracking is an Albatross?

I just got off a conference call where the customer lamented that project tracking (in his organization) is an albatross.  E.g. too much work!

His company had been using an Excel spreadsheet, and wanted to switch to Standard Time® for project tracking.  Their spreadsheets had grown so large that grooming them consumed too much time.  His statements really got me thinking.

Every project has two components: doing the work, and managing the work.  That’s no big secret.  This person was lamenting about the management part, and wanted to know how Standard Time® would improve that.

Unfortunately, the answer is not in the tool, but in his organization.  Questions arose regarding the size of his teams, their self-sufficiency, and how granular his tasks needed to be.  We agreed that his tasks were too granular – too small.  He had been trying to micro-manage everything, and that was driving him crazy.

Let’s face it, project tasks change frequently.  It’s nice to document every task you’ll work on, but in practicallity, some well-defined buckets could catch all the task work.  Each time log could describe the work performed, and you’d still have some basic tasks to report on.  Simplicity is best.

Web 2.0 Collaboration

eWeek published a little piece in the Application Development department regarding Web 2.0 collaboration.  (See a link to the article by Darryl H. Taft below.)  The upshot is that developers have been using Web 2.0 collaboration for years.  It’s the rest of the world that’s just catching up.  How about you?  What Web 2.0 technologies do you use?

I use the following resources pretty regularly.


Honestly, I’m not a big web surfer.  I don’t spend a lot of time subscribing to RRS feeds and plugging into the forums – with the exception of projecteamblog.  I don’t even have special ringtones.  Web 2.0 is not that exciting to me.  I’m not much of a social networker.

Tell me why I’m wrong!  What am I missing that could help in the areas of project management, application development, and team management. says there’s 11 million blogs out there, plus or minus 500 million that come and go every month.  I must be missing something!  I’d like to hear your comments…


There’s Some Done Already!

I know a person (who will remain unnamed) who uses a little trick to work on projects.  When starting a new job, she does just a little bit the day before.  When she comes in the next day to begin the project, she’s happy to see that there’s some done already!  And then, she can continue where she left off.

Nobody likes to start a new project with a blank page.  Yuck, where do I begin?  That small hurdle is sometimes enough to make you procrastinate a whole other day.  Yes, I do it too!  I have hundreds of small projects I’m responsible for, and sometimes I can’t bring myself to start another one.  To avoid a new one, I’ll putter around on secondary tasks, avoiding the real work.  But, if my project is already started, I have no trouble picking up where I left off.  It’s the starting that bugs me.

I think I’ll try this little trick next time!

— newshirt

Don’t Boil The Ocean

When I develop products, I like them foundational.  In other words, simple.  Every release of our products is simple.  They are almost never a week away from release.  That affords a few good luxuries.

First, the products are (almost) alway stable.  There are never any huge releases that introduce a dozen bugs into the system.  Every release has at least a few small bug fixes and polish.  We keep up on that, along with adding new functionality.

Second, we’re nimble.  If a customer asks for a new feature, it’s less than a week from delivery.  Customers love that, I can assure you.

Lastly, project management is simpler.  There are no huge project plans to deal with.  Just small to-do lists we can check off rapidly.  Does it always work?  Yes.  Well, maybe not always…  Okay, about half the time.  But that’s better than deep-dives and unstable products.  Wouldn’t you say?