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.

7: Requiring the consultant to finance you. This is a favorite of finance departments, but it creates a perverse cost function. As a large company, you have much lower capital costs than a consultancy. This requirement burns up a consultant's credit line. Plus, if you have payment terms of 120 days or more - further compounded by invoice-approval cycles involving people who know nothing about the project or software in general - you also cause cash-flow issues for the consultancy. In extreme situations, this results in staffing problems for your project.

6: Making non-poaching agreements a one-way street. Any consultancy is willing to sign up for not poaching your staff. If you aren't willing to make the same commitment, you give consultancy an incentive to put crummier staff on your project.

5: Not allowing explicit project management or client-meeting tasks in the schedule of work. This is non-thinking at its best. Any project must be managed, and you'll be calling meetings and participating in system walk-throughs. To not allow these as explicit tasks on the SOW means they'll be buried in other items, leading to misleading measurements. Remember the old project management saying: "You can't fix what you can't measure."

4: Heads-I-win, tales-you-lose pricing. I go on endlessly about the perils of fixed-price projects; namely, how they can poison the agile methodology that's the core of lowering project costs. Asking a consultant to absorb the risk of fixed price can mean doubling the bid.

Some clients take it a step further with "hourly rates, with not-to-exceed" clauses. This makes perfect sense to every purchasing manager in the world, but it contaminates your project with sloppy thinking, gamesmanship and an adversarial relationship. Agile requires trust. If you aren't willing to start there, go back to waterfall.

3: Requiring the consultant to cover you for patent infringement on patents that don't even exist yet.Patent trolls are a grim reality, yes, but it's a bit much to require a consultant to cover infringement costs and all lawyer fees for patents that you haven't issued yet (pending ones are secrets) or can't read (because they're in a foreign language). Most firms can't buy insurance coverage for this at all, so if a huge infringement judgment ever happens, all you'll do is bankrupt your supplier. That'll help.

2: Mandating clumsy, overly detailed project reporting that the project manager doesn't have time to understand.Measuring the wrong things doesn't help. It can actually cloud visibility. There's simply no substitute for a strong, trusted project manager with enough time and energy to keep the project schedule and budget on track.

1: Relying on a requirements tome, not a strong project manager. The RFP process works for hardware systems. It means almost nothing to success of custom software - and for cloud projects, I'd go as far as to say that they contribute to project failure.

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.