Enterprise custom software is becoming more complex and more intricately entwined with workers’ daily tasks and routines. As a result, businesses are having to change the way they think about software development projects. At the same time, however, our deep familiarity with certain applications is giving rise to many unrealistic expectations about how readily any new software can be incorporated into our businesses. If Facebook is so easy to use, for instance, you may wonder why all business communication platforms can’t be just as user-friendly the first time you try them.
Even though we understand that custom software has to fulfill far more functions than it used to, we still can’t help taking for granted everything that goes on behind the scenes. On the front end, it seems so simple to, say, attach a file from a cloud folder to an email message or a Trello board. So it’s hard to grasp how complex a task it can be to integrate a new application within an existing software environment. The more embedded our software becomes in our work lives, the more we treat it like a bunch of appliances. You open a refrigerator and pull out what you want. Shouldn’t the design of our business applications be just as simple?
Integrations are just one of the aspects of development projects whose complexity is commonly overlooked. Good software is easy to use, right? But how can the developers know what constitutes ease-of-use if they never learn how workers will actually be using the application in its business context? The more business use cases, the more complicated the development process. And however much the software may simplify daily tasks, workers will probably still have to be shown how it works if you want them to use it.
The Uselessness of Upfront Requirement Lists
If you’re searching for a custom software vendor, then the application you need probably has a long list of special requirements—otherwise prepacked software would do the trick. The way this worked in the past was that you’d get all the stakeholders—department heads, managers, c-levels, and maybe a couple IT guys—together to draw up a list of what all the application would have to do to be considered a success. The problem with this approach is that good software serves as a solution to a complex set of challenges, and the viability of any upfront requirements list depends on your team’s ability to come up with an armchair conceptualization of the application that actually works in real life.
If you go back to 2010, failure rates for IT projects were about 75%. By 2014, that number had fallen to 61%, largely due to improving development methodologies. The qualities common to the 39% that succeeded were that they had smaller scopes, involved highly trained developers, and relied on an agile methodology. Since agile approaches entail breaking complex projects into simpler stages, the takeaway is that it’s just really hard to adequately conceptualize big, complicated technology initiatives in the planning stages and then go on to build the tools without running into serious, even catastrophic impediments. Building enterprise custom applications is a far cry from deciding on the dimensions of a new refrigerator.
Scrum, probably the most popular agile methodology, addresses this challenge by focusing on user stories and assigning teams to build individual components of the application sequentially. At the end of each “sprint”—the term for the individual stages of the process—the team will usually have some working software to deliver. That way, someone on the business side of the arrangement can try it out and offer feedback. The feedback then gets incorporated into the plans for upcoming sprints. This methodology is effective because it takes into account the near impossibility of business leaders knowing exactly what they need without getting their hands on a few examples of tools that are close but just aren’t quite it.
As Matt Noggle, Aptera’s Practice Leader for Custom Software Development, explains,
“A good scrum team should focus on delivering a component that could theoretically be used to conduct business activities (this should be the goal of every sprint). This focus allows the team to incorporate feedback from project stakeholders, while acquiring knowledge that improves the product. In many cases, it allows the team to concentrate on creating and delivering a product that meets the primary objectives of your business. All those nice-to-have things, or functionality that’s not the primary day-to-day focus of your business operations, can be added later. This allows your business to begin recognizing the return on the investment while those additional features are being added to the core functionality that is being used by your business.”
What almost invariably happens over the course of a Scrum project though is that the final project looks significantly different from what the stakeholders envisioned at the outset. The projects are a success, the software delivers a substantial ROI, but the upfront requirements list has proven to be almost completely useless.
Bidding Wars vs. Job Interviews
When you’re searching for a solution to a complex problem, you probably don’t begin by drawing up a list of all the features the solution should have. What you need, rather, is some creative thinking and maybe a little focused tinkering. As long as you think of an application as an appliance with a static list of features, the traditional RFP will seem like the best way to make sure you get precisely what you need at the lowest possible price. But thinking of software in this way was exactly what led to three-quarters of all projects failing back in 2010. Refrigerators built to the same specs probably work pretty much the same no matter who builds them. The same can’t be said for custom software.
But if agile methodologies are so important in ensuring project success, and if those same methodologies render the traditional RFP process obsolete, then how do you choose a partner to develop your custom software? How do you make sure you’re getting the lowest price?
First, it’s important to get away from software-as-appliance thinking. Enterprise software plays a dynamic role in your operations, far more similar to a new employee than to a new copier. When you’re hiring a new employee, you’re not looking for the person you can pay the least; you’re looking for the person who will bring the most value to your company.
Second, there needs to be a shift from thinking of the vetting process as a bidding war to thinking of it as something more like a recruitment initiative. The old joke about flying to the moon in a spacecraft built by the lowest bidder highlights the absurdity of imagining that all vendors can be counted on to deliver products of equal quality, regardless of cost. Obviously, cost is still a critical issue, but it’s no less critical when we’re talking about salary negotiations with a prospective employee.
Because methodologies like Scrum involve a lot of collaboration between people on the development side and people on the business side, treating prospective partners like job candidates makes intuitive sense. You’ll have a number of candidates with sufficient experience and qualifications come in so you can discuss what role you envision them—or the software they develop—playing in the company. You’ll assess how well they understand the business challenge you’re hoping to take on, how likely their planned approach will be to succeed, and how easy they’ll be for your existing employees to work and communicate with.
As likely as not—actually half again as likely as not—if you simply draw up a list of requirements and choose the lowest bidder who promises to meet them, you’re going to end up dealing with a project that involves numerous change orders, extends well beyond the deadline, exceeds the budget, or results in an application that fails to deliver on some important functionality.
Having vendors respond to an RFP simply doesn't create an environment where apples-to-apples comparisons can be made, as too many businesses continue to assume it does. Two important things to consider:
- RFP estimates are typically built upon a number of assumptions, and aligning those assumptions would be nearly impossible when doing a cost comparison.
- Let’s be honest, going through a 50+ page document outlining a project is time-consuming. Expecting all the respondents to arrive at an identical understanding of all the details incorporated into those pages is probably unrealistic. Even if all the assumptions were somehow miraculously aligned, it’s pretty reasonable to expect that one or two things were missed by someone, probably the lowest bidders.
The new approach many businesses are taking to avoid all these pitfalls in the planning stage and beyond is to build software in iterative stages, incorporating user feedback at several points along the way. Of course, along with the evolving project methodologies, businesses are also adjusting their approaches to choosing development firms. By treating the decision-making process more like a recruiting project, we can keep those ridiculous failure rates for IT projects on their current downward trajectory.
Popular posts like this: