PUBLISHED MAY 12, 2012

Stakeholders and Failure

A rusty boat sits adjacent to a weathered wooden structure

Today, I want to share two anecdotes about my life as a contractor.

One

About seven months ago, one of the projects on which I was an iOS developer received a stop-work order. In private conversations over the following days, I revealed to one of my colleagues that I had seen the writing on the wall since the inception of the project. I didn't know how to distill my feelings into words at the time, but two things in particular stuck out about the client: lack of total executive commitment, and lack of resources for user experience design.

Let's take the second one first: no UX design resources. The project was to port an existing Windows-only desktop application to the iPad. There was an iPhone project that had been completed by a different consulting team and then brought in-house, but it had performance issues and (in my opinion) a ghastly UI.

In our initial meetings for the new iPad product, it was explained that there would be no UI/UX staff on our iPad project. The presumptive reasons were (a) that the client just wanted to use "stock" UI components and (b) the functionality was a subset of the desktop app, so it could act as a living spec for the UI/UX of the iPad app.

Anyone with app development experience who also has an iota of taste will tell you that this is insanity. But hey, we were all Agile and SCRUM (emphasis on the ummm...). We trundled along on the project, using stock paradigms where possible, and trying to force them where they weren't possible. The only design guidance we got (and I'm not exaggerating) is from the PM, who was using Microsoft OneNote to draw wireframes. We went straight from wireframes to code. "Once more unto the breach, dear friends", and "into the Valley of Death rode the six hundred".

The second troubling symptom was lack of executive commitment. I got the impression that the CTO was lukewarm about iPad-only development from the start. Confirmation came quickly enough. The client was going through a rebranding effort during this project, and out of curiosity I googled the old and new trademarks. I stumbled onto a job posting indicating that the company was seeking full-time "HTML 5" developers. It used words like greenfield development and you choose the technology. I realized pretty quickly that our team was going to get shit-canned. The client had sunk tens of thousands of dollars into this project, but far from throwing their whole weight behind it, they were instead putting out feelers for a whole different kind of development team, a development team that could hit all the latest platforms instead of just iPad. Yes, we were about to get cross-platformed and responsive-designed out of business.

And so we did. Two weeks after the stop-work order, the project was shelved indefinitely.

If there are any lessons learned here, they probably go something like this. First, being Agile does not remove the need for a well thought-out design. Second, sometimes the client needs guidance on what resources to provide, and sometimes they're intransigent because they're playing politics. Sometimes, in fact, the wise thing to do is to see the writing on the wall, collect the check, and start emailing your resumé around.

Two

This second story isn't about abject failure, but about the consequences for a company that chooses to rely on contractors to plug a hole that would be better filled by full-time employees. About 18 months ago, I was brought onto an iPhone project that was already underway. This time, it was an existing Web application that needed to have an iPhone interface.

To make a long story short, because I have more to say about the lessons learned here than the project itself, this made for about eight months of fat checks. It was also a pretty high-stress project, with constantly slipping deadlines and sometimes hurt feelings. It could have been at least two orders of magnitude worse, though. At the end of the day, we shipped, and the product is by most accounts a hit.

I feel the need to mention here a very important fact: both of the companies in these tales are software companies. Their core competency was development, sales, and support of an existing piece of software that had a lot of moving parts and dozens of dedicated individuals in database architecture, programming and IT (not to mention the massive sales teams and managerial infrastructure).

The client was a company that should have focused on hiring better. Not just better people, but better roles. You've probably heard some variant of the adage, don't outsource your core competency. Similarly: if you are a software company, even if your products are in C# and SQL Server, your recruiters should know a thing or two about how to hire for other technologies.

If you have to use a contractor to get your project off the ground, treat them like part of your hiring staff for half of the time. Have them architect your new project, then move them aside with full-time hires. Otherwise, you'll have outsourced a new and potentially large piece of your core competency. There are at least two reasons why this is a problem: incentives and adjacency to the rest of your team.

Perhaps the best, if not only, incentive you can offer to a contractor is higher pay. If instead, you rely on internal resources to take over a project in an unfamiliar technology, they have all the reason in the world to excel (assuming a certain baseline of competence): promotions, esteem from their peers, raises and the rest.

Adjacency to the team is as important as correctly-aligned incentives. A team member will benefit greatly from being able to walk down the hall to a veteran on your mature projects and ask for clarification on business logic, or Web service endpoints, or preferred coding style or whatever. Consultants are nearly always harder to reach (unless you keep them on-site, which is both expensive and of questionable legality).

Epilogue

Well, if both of these companies had taken my advice, I would have been out of a job for most of last year, so I'm glad I wasn't wise enough (or in much of a position) to give it back then. In the mean time, I've had a chance to work with some tremendously effective teams as a hired gun, and I hope I'm able to continue building a track record of excellence. There are an awful lot of lessons you have to learn the hard way, but if you're lucky, you get to have fun along the way and get paid for your trouble.