Lessons from a Lawsuit

(or How to hire a company to build your digital product)

You’ve probably heard of the lawsuit Hertz filed in April, seeking to recover fees and damages from Accenture for failing to deliver a functional website or mobile app. We’re not going to get into who’s legally right or wrong, nor do we pretend to know all the details of the relationship, but what we do know is that after two years and over 32 million dollars, Hertz had nothing to show for their money.

So let’s save you that time and money, and dive into what we can learn from their lawsuit about hiring a firm to build your digital product.

Hire based on related experience

This may seem incredibly obvious, but it’s worth stating here: The skills required to put together an impressive presentation have little to do with the skills required to build a web or mobile application, or even to adequately manage that process.

If you don’t have any technical staff who can evaluate the technical skills of the company you’re considering hiring, you should, at minimum, talk to past clients who have hired the company for similar projects (and ideally using the same technologies you plan on using). Ask if:

• the company delivered the product on time
• the completed product matched client expectations
• the product met the client’s needs
• the client found out about issues in time to correct them
• the company demoed the product throughout the process, so that the client saw what progress was made
• the company worked with the client to define releases and engaged the client in regular prioritization and backlog grooming

Own your product

Yes, you’re hiring a company to essentially act as your expert in an area in which you don’t have expertise, but this doesn’t mean you can sit back and relinquish all control. Your business/user needs are the ones that have to be met by this product, so you have the final say on the design and functionality and should be involved in defining all features and functionality. Here at Theory and Principle, no functionality that we’ve developed is considered complete until the client signs off on it.

Take responsibility for checking the product on your own throughout development, whether it’s as casual as quickly clicking through a website or as rigorous as leading multiple users through your app for their feedback. At this point in the process, is the product functioning as you’d expect? Is it even functioning consistently for you the way your development company says it functions for them?

Keep in mind that your job as the product owner is NOT necessarily to keep the company you hire focused on the requirements set forth in your RFP. As user testing and discovery (the process of defining the framework for your product) are completed, you may find out that the product needs to diverge from those initial requirements. But if this happens, 1) it should not be a surprise to you on launch day, and 2) the product should still meet your business/user needs. As product owner, you should stay particularly focused on that last point.

Ensure work is delivered — and released — in stages

Although the Accenture work for Hertz was divided into stages, phase 2 included “build, test, validate, and deploy the website” which kind of covers…everything. We don’t know whether Accenture and Hertz scheduled regular check-ins during which defined accomplishments could be shown to or tested by Hertz. We also don’t know whether deployment was to be staged, so that the redesigned website would be released independently of any mobile apps which would then be released at a later date, or if the go-live date was literally one single day intended to cover…again, everything.

In most cases in product development, small measurable steps will lead to better results than aiming for one giant splash. Theory and Principle uses an Agile model of software development, which breaks tasks down into smaller modules that can be completed in two week cycles called sprints. We work with our clients to define the feature sets to be developed each sprint, and demo the completed work at the end of a sprint. We don’t have the option of delivering nothing because we build functionality in increments.

We also release products gradually (to clients, if not the public) as functionality is ready. Staging your release can give you an idea of how your product will be used by real world users and draw out potential issues before you ramp up to heavy usage. And during development, staging internal releases every sprint means you’ll find out about any difficulties your software development company has with meeting deadlines before you invest more substantial time and money.

Don’t underestimate the importance of testing

Remember the product owner’s responsibility to check the product that we discussed a few paragraphs above? You don’t need an extensive technical background to run through the product in development the way a typical user would. (There’s even a name for this kind of testing: User Acceptance Testing.) But the bulk of the testing — functional, load, accessibility, usability, etc. — should be taken on by the software development company and performed prior to any public release, and certainly before any client release for your eyes.

If you’re contemplating hiring a company to build you a digital product, find out what their testing plan is. What kind of tests do the developers run? What about their quality assurance staff? How will they determine what error handling should exist within your product? What opportunities will you have during development to try out the product yourself?

Note that the testing undertaken by the development company in these situations differs from user testing, which is more research-oriented and can be performed by either you or the company you hire to build your product. While usability testing is generally done by the development company to ensure that your product functions as intended, user testing validates that your proposed product actually meets a need. User testing is equally vital to successful website and mobile application development, but it serves a different purpose than the testing Hertz discusses here.

Conclusion

The Accenture/Hertz lawsuit demonstrates that colossal failures can still occur in organizations with vast resources. You might not have the luxury of spending this kind of time or money, especially if, like Hertz, you have to start over with a new developer afterward. So hire thoughtfully from the start, and remember that in the world of software development, an impressive presentation can be like a glitter explosion: pretty to look at, but somebody’s gonna have to clean up after it eventually.