Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Are purchasing practices killing your software projects?

David Taber | Feb. 3, 2014
Alan Shepard famously said, 'It's a very sobering feeling to be up in space and realise that one's safety factor was determined by the lowest bidder on a government contract.' Don't let the purchasing department determine the success of your software project.

Unless you're willing to invest an enormous amount of money on an exhaustive requirements spec, the RFP documents will be full of bad assumptions, misunderstood requirements and overblown details that all conspire to make your project a mess. With larger projects, many of the pages are obsolete or invalid by the time you implement them.

A small, flexible specification of goals with a dedicated, knowledgeable and strong project manager is a much better approach. Paper can't protect you from scope creep, misunderstandings and outdated goals, all of which contribute to project overruns.

Small Software Projects Don't Need Big, Onerous Contracts

The larger your company, the more likely you are to use these contractual tricks. In procuring large, long-running projects from large consultancies, such contracting issues can be easily amortized and hidden. Other than the high price tag, you may not even notice the effects on those projects.

Fine - but smaller projects, typical in IT's new cloud application paradigm, don't fare so well.

  • You'll drive up project costs. The "minimum feasible project size" is probably $20,000. (Larger consultancies may not answer the phone for less than $500,000, but boutique shops can make a profit on much smaller projects &mdash if you'll only let them.)
  • You'll lengthen the project schedule, as all the tech must be built from scratch, not from than recycling code or other IP.
  • You're less likely to get bids from specialist shops where the proportion of sharp-shooters is higher. The average staff quality on your project will be lower.
  • The inflexibility mandated in your contract means the project can't be as tight a "fit" to evolving requirements.

If you're trying to build software for today, and even tomorrow, you can't expect to succeed if you're still using the contracts of yesterday.

 

Previous Page  1  2  3 

Sign up for CIO Asia eNewsletters.