INTERVIEW: Don Dodge (Microsoft) on Avoiding Project Failure

Don Dodge has been around the software industry for a long time. Currently Director of Business Development, Emerging Business Team, at Microsoft, Don works closely with startups and venture capitalists. I’m an avid reader of Don’s blog (called the Next Big Thing), so it was with pleasure that I ran into him at the recent Red Herring East 2007 conference in Boston.

I asked Don a few questions about avoiding project failures, based on his experience working with many IT companies and products. If you want to understand the dynamics of project failure and success, I urge you to read Don’s comments carefully; He’s distilled lots of wisdom into a few short answers.

Don, when we met at the Red Herring conference, you said (and I’m paraphrasing here) that one of the major causes of failure is ‘unrealistic customers who expect a lot but are only willing to pay a little.’ Is it really that dangerous to be a tough negotiator?

Not unrealistic customers…unrealistic or vague project requirements.

In my experience, many software projects fail because the requirements were unclear right from the start, and buy-in was not achieved among all the various stakeholders who should have been involved. I’ve never seen a project get smaller…they always expand and get bigger. Second, most software projects are not “rip and replace”; they need to integrate with many other existing systems, which are often not managed or controlled by the project sponsor. Integrating with those other systems causes lots of delays and potentially huge architecture issues. Third, I think the biggest mistake in software projects is not doing regular progress checks and demos of code early and often. I worked at one company that used the “Extreme Programming” model, sometimes referred to as “Agile Process”. The great thing about Extreme Programming is that you must demo your work to the customer every three weeks. You can’t get too far off track if you are demoing to the customer every three weeks and getting them to approve the work.

Regarding your second question, I wouldn’t call it tough negotiating…just clear negotiating. Be very clear about the project specs, schedule, and success criteria. Then regularly check progress throughout the project.

You work with many startups and small companies in your role at Microsoft, and they’re often in an extremely weak negotiating position when dealing with enterprise buyers. Is there a way for these companies to command a price that lets them do a good job for demanding clients?

Startups are not in a weak negotiating position. They can move faster, have lower overhead, and offer a more personal approach than big companies. In fact, startups can charge lower prices and still make lots of money because they don’t have the huge overhead expense. The problem is that startups often feel like they’re in a weak position and therefore under-price themselves. In fact, however, they are not in a weak position.

At the same time, some projects are just not worth taking. If the requirements aren’t clear, if the schedule is unrealistic, or the price is too low…don’t take it. Life is too short.

Any time there’s a bidding war among vendors, common sense suggests that the buyer better have a clear idea of key project requirements — must-have features and critical performance criteria vs. less-essential stuff. Do you see this happening in actual practice?

Bidding wars often result in the “winner” losing money in the end.

If a customer bases his or her decision strictly on price, there are sure to be bad feelings somewhere down the line. Most people are honest and try to do a good job. However, mistakes happen when people move too quickly, without clearly documented requirements, without taking the time to map out a realistic schedule, and so on. A quick deadline for proposals or vendor selection can cause the customer to make mistakes.

What about the role of consulting partners in an under-funded project? How can the consultants manage customer expectations so the project doesn’t fail?

Big projects can get very complex…too complex for any one person to fully understand. Customers and project managers rationalize away issues, hoping to make up the shortfall downstream, perhaps cutting features or requirements in the desire to make it all fit together and work. That’s a recipe for disaster.

Projects that are “under-funded” or where customer expectations are not clear are in deep trouble. It gets back to the basic points I made in the first question:

• Be clear about requirements and get ALL customer stakeholders to agree
• Get the integration plan and architecture clear up front
• Demo your work early and often and get the customer to approve

Is there a special Microsoft methodology that helps avoid doomed projects? Or are you guys in the same boat as everyone else?

Microsoft has been building massive software projects for over 30 years. Microsoft projects rarely fail, but Windows Vista is a recent example of a major project schedule slip. The project was successful, but significantly behind schedule.

We spend lots of time getting requirements clearly documented, and bringing all the participant groups together, so everyone knows what they need to do and when. Successful software projects always have a strong leadership team that communicates clearly.

The mechanics of a successful project are pretty basic…but often overlooked.