Strategic CIO // Executive Insights & Innovation
Commentary
2/18/2014
12:32 PM
Josh Oakhurst
Josh Oakhurst
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%
Repost This

4 Biggest Custom Software Buying Mistakes

Procurement is broken. Here's how companies can avoid the biggest blunders.

Stagnant procurement processes often kill innovation. As more companies look to build software instead of buy it off the shelf, the first process that requires improvement is the one where the contract gets signed.

At Skookum Digital Works, our 55-person shop in Charlotte provides tech investment strategy advice and also builds hardware and software from scratch, so we live this. To avoid irrational fears, policy-driven blinders, and downright rule-bound stupidity during the  procurement process for innovative technology, avoid these four mistakes.

Mistake No. 1: You think you're buying a product
You're not. You're going on a journey. Custom software development is not something you should purchase like paper clips. Procurement departments are wired to haggle over incremental per-piece pricing, volume numbers, and delivery dates.

Pre-packaged technology providers have "inventory" sitting on the self; they sell what's in the box. In contrast, custom technology consultants take pains to map out investment options and craft custom software executions. When business units express the desire to go on a technological journey, procurement should help them pick a tour guide, not insist on cross-shopping hotels. Projects slow down or can implode altogether when procurement gets this wrong.

[Considering custom software? Don't miss this post from Coverlet Meshing: Build Vs. Buy: A Dangerous Lie.]

Custom software service companies exist because someone decided what's in the box won't work. For a custom execution, the process is the product.

Mistake No. 2: You require the contract have a hard delivery deadline
Custom technology engagements are best controlled by budget and ambition, not deadline. The goal of a tailored software creation process is to create working software as soon as possible. After all, code is a liability; you want the least code possible. Features determine how much code will be written, and at the moment of contract signing, the features you think you'll include are always dubious.

What you will want in the contract is a nod toward a delivery date for a minimum viable product, and a proposed sprint schedule. But it's folly to assume anyone knows the final end date of your journey at the time of contract signing.

Mistake No. 3: You view custom software as a dollar-per-hour commodity
Developer cost per hour is a terrible way to look at a custom software project. Is the value of the Empire State Building a function of the price of steel and the labor hours that went into it?

Procurement departments run straight into this trap because developer cost per hour, like the price of steel, can be easily measured. If custom software development were merely a function of developer time, then hiring an array of the cheapest offshore coders would get the job done. You're paying for business technologists who can implement or invent technology that does what you asked for -- make your business faster, more efficient, more profitable, more robust.

Mistake No. 4: You assume the standard software contract deductions apply
Because out-of-the-box software contracts have been negotiated with standard deductions, buyers often assume custom software is also highly negotiable. But the logic of volume pricing doesn't apply to creation-from-scratch. Always fighting for a discount off sticker price is not only obnoxious, it's myopic. (And, in some cases, downright stupid.)

Procurement helps its business units succeed by doing a complete cost-benefit analysis. Often, the best way to measure the value of custom software development is to stack it against the cost of doing nothing.

Simply, you can't get a unique act of creation wholesale.

Best custom software procurement practices
So how can procurement pros know they're getting the right price, and not getting taking to the cleaners, on custom software procurement? Here are some guidelines:

  • Use this value cheat sheet: pre-packaged software = tech to-do list; custom software = tech wish-list. Since there is no rate for technology invention, assess custom software providers based on the business value they created for past clients, not comparatively between off-the-shelf vs. custom options.

  • Factor speed of decision making into how you support your business unit heads and their partnership decisions. Be a speed facilitator, not a speed bump.

  • Treat the hiring of custom technology providers much like hiring management consultants. Both are tasked with (and will be measured by) business-change -- specifically with increased revenues or process automation. So if you’ve ever hired management consultants, you might already have a procurement paradigm for custom software.

  • If you want a markdown, be willing to compensate your technology partner for the increased profits or productivity you receive on the other end.

  • Instead of uniformly and reflexively beating up vendors, find another way to demonstrate procurement performance. On innovative technology contracts, factor in speed of approval, flexibility (novel), problem solving ability, and general helpfulness, as measured by reviews from leaders in the requesting business unit.

Businesses often try custom software when they see a chance -- often fleeting -- to grab new revenue. But the lack of neat edges on the forefront of innovation can cause some real problems for policy-driven departments like procurement.

In short, procurement leaders need to be as innovative as their fast-moving business units require. 

Engage with Oracle president Mark Hurd, NFL CIO Michelle McKenna-Doyle, General Motors CIO Randy Mott, Box founder Aaron Levie, UPMC CIO Dan Drawbaugh, GE Power CIO Jim Fowler, and other leaders of the Digital Business movement at the InformationWeek Conference and Elite 100 Awards Ceremony, to be held in conjunction with Interop in Las Vegas, March 31 to April 1, 2014. See the full agenda here.

Josh Oakhurst is the Chief Strategy Officer at Skookum Digital Works, a growing technology investment and innovation partner hiring NY, SF, and SV refugees since 2005. He's @joshoakhurst on Twitter and linkedin.com/in/oakhurst.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
TerryB
50%
50%
TerryB,
User Rank: Ninja
2/20/2014 | 9:49:59 AM
Re: No Hard Deadline?
Your Coverlet Meshing had the best description ever of Agile to business:  The middle finger of methodologies.

We (IT) don't need business and IT management to hold our our hand every step of a project. Point us in a direction and get out of the way. Good developers will deliver what the end users want.

Agile is something formalized for large businesses. At SMB's where I've always worked, that just how you get things done. There is no reason to produce these time consuming business requirement documents and have endless meetings, there are no people to read or attend. Just you and the people who use your software. The quicker you get to running code prototype, the quicker you can iterate to the final product that works like users need.

Agile is the formal attempt to get big IT teams and big bureaucratic companies to operate the same way. Long overdue. But it only works if you have developers that can communicate with users and understand the business. Many non technical IT managers don't want any part of that.

 
JoshOakhurst
50%
50%
JoshOakhurst,
User Rank: Apprentice
2/19/2014 | 7:32:14 PM
Re: No Hard Deadline?
RE: Chris Murphy "I'm wondering how companies can manage their business planning without a hard deadline for completion. When I hear of companies building custom software, it's often because there's some really pressing need or ripe opportunity -- meeting a competitor's app offering, or a looming cost savings."

 


Emphasis above is mine, I highlighted those two word for a reason:

 

It's hard to plan for ripe opportunity. That's the rub.

 

Planning happens for the to-do list: we need x on y date to make sure z ships on time.

 

Opportunity realization happens for items on the wish-list: woah, wouldn't it be great if x could influence y?

 

Often, the wish-list vs. to-do list is a dichotomy we draw for clients. Succinctly, fresh tech/process automation/"invention"/innovation servicing is more condusive to the wish-list. And buyers in that mindset don't have deadlines as a top priority. 

 

RE: "How do you manage business unit expectations in that case? "

Once we're engaged with a philisophically aligned client, we manage expectations by showing them cool stuff early and often. We share the knowledge we pull out of our observations and hacking, and we quickly lay out prototypes/concepts/sketches (six weeks or less).

 

Yes, it's Agile, but technological transformation is much more than code slanging.

 
JoshOakhurst
100%
0%
JoshOakhurst,
User Rank: Apprentice
2/19/2014 | 7:22:06 PM
Re: No Hard Deadline?
RE Somedude8: "Living by The Rule of the Deadline is short sighted and unwise, but it looks good on a spreadsheet."

 

I'll go so far to say that we decline work when infinite variables are unknown yet a hard date is among the top three considerations.

 

Like a personal trainer aproaches a wanna-be-athlete, we holistically apply technology to the enterprise to make it better. It's okay if the client wants to run a marathon in six months — they'll certainly be a better runner on that hard date — but the longer we train, the more value we'll create.
JoshOakhurst
50%
50%
JoshOakhurst,
User Rank: Apprentice
2/19/2014 | 6:44:08 PM
Re: Really re build?
LOLZ TerryB RE: Management Consultants

 

You're right, I should have been more explicit with the analogy: instead of running your technology-invention partner through procurement, take them golfing instead. 
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
2/19/2014 | 4:20:33 PM
Re: No Hard Deadline?
So if business units can't be made to understand and value Agile development, and they're the ones who want and requested the software functionality, is there any hope of the procurement pros embracing Agile? Is that necessary?    
DDURBIN1
50%
50%
DDURBIN1,
User Rank: Ninja
2/19/2014 | 2:41:24 PM
Re: No Hard Deadline?
@Garey, If it looks like a duck, talks like a duck, yes it's Agile development LOL!  Business managment at most organizations I have worked only care about cost and delivery date with very little concern about the process however talk to them about the business's product life cycle and they know everything about it.  I'd like to see them apply the same conern and vigor they show in product development to software development then maybe IT will get some respect.  It is happening at more and more companies as the "old" guard retires.
Lorna Garey
50%
50%
Lorna Garey,
User Rank: Author
2/19/2014 | 2:02:11 PM
Re: No Hard Deadline?
Aren't you describing Agile development?
TerryB
50%
50%
TerryB,
User Rank: Ninja
2/19/2014 | 1:59:44 PM
Re: Really re build?
Most of the Build vs Buy argument is around whether you have internal development team or you don't. Companies like Josh's throw a whole new twist on this.

I assume what he is doing is, for example, writing a mobile app to connect your internal systems to customers. That can make a lot of sense because you may have some internal guys to know the technology your inhouse ERP (or SaaS ERP for that matter) uses but has no clue how to write for mobile devices. And if you limited recurring need for that kind of development, training your inhouse people or hiring someone new are likely more costly alternatives than using someone like Josh.

Josh, my only criticism of your article is your comparison to mgmt consultants. I'm assuming people can actually see and use your software when you get done. I've never seen a mgmt consultant produce anything of tangible value. Except maybe teach you some new buzzwords.  :-)
Somedude8
IW Pick
100%
0%
Somedude8,
User Rank: Ninja
2/19/2014 | 1:36:19 PM
Re: No Hard Deadline?
Mega game makes Blizzard is a good example. Their software is ready when it's ready. This often frustrates the crap out of gamers who are dying to get their hands on that next game/patch/expansion. Blizzard won't even give a projected release date until they are pretty close to being done.

They do of course live in a dramatically different world then your corporate cubicle farmers live in. But consider for a minute the true cost of software: Maintenance. After years in this business, I am 100% convinced that the most expensive thing in software development is crappy code, which is the inevitable end product of deadline-based development.

I mostly bailed on cubicle land and went freelance a little while back. One of the freelance sites I get work from lets clients rate 5 aspects of the freelancers work. One of those is schedule. I have never gotten less than a top rating in all categories, except schedule. If I think my code isn't up to snuff, I don't turn it in, I refactor or whatever I need to do.

I am not saying that projects go completely without deadlines, but that common sense needs to be in the mix here, and that code quality is by far the most important part. Living by The Rule of the Deadline is short sighted and unwise, but it looks good on a spreadsheet.
DDURBIN1
100%
0%
DDURBIN1,
User Rank: Ninja
2/19/2014 | 12:45:27 PM
Re: No Hard Deadline?

I spent many years as a software developer and I can attest to all these mistakes.  I'd settle for a building a building project apporach to software development but in many cases the seat of the pants approach is taken by CFOs and CEOs.   The key to delivery dates is a fully defined and designed deliverable that doesn't change over the time of development.  That rarely happens in the real world.  Try starting a building project when you're not sure how many floors it will contain or half way into the project two more floors are added by management.  A building contractor would never allow that to happen and if did would not have a fixed date.  However it happens most of the time in software development but its a mistake.  To allow for "fix" delivery dates the deliverables need to be short and sweet developed over not more than six months otherwise scope creep is about to creep in and destroy your time line, guaranteed.

Page 1 / 2   >   >>
InformationWeek Elite 100
InformationWeek Elite 100
Our data shows these innovators using digital technology in two key areas: providing better products and cutting costs. Almost half of them expect to introduce a new IT-led product this year, and 46% are using technology to make business processes more efficient.
Register for InformationWeek Newsletters
White Papers
Current Issue
Video
Slideshows
Twitter Feed
Audio Interviews
Archived Audio Interviews
GE is a leader in combining connected devices and advanced analytics in pursuit of practical goals like less downtime, lower operating costs, and higher throughput. At GIO Power & Water, CIO Jim Fowler is part of the team exploring how to apply these techniques to some of the world's essential infrastructure, from power plants to water treatment systems. Join us, and bring your questions, as we talk about what's ahead.