Every year in its ominously titled “Chaos Report,” the Standish Group publishes figures on success rates for IT application development projects. 2014’s Report found that 18% of projects were utter failures, never reaching completion or delivering products that were never used. (And this was a big improvement over earlier years.) A further 43% went past deadline, over budget, or failed to deliver the required features and functions. The good news is that the 39% of projects that were successful all had a few key elements in common. And the lessons that come out of these commonalities make a lot of sense to developers, because they deal with the types of challenges that come up in almost every project.
Three messages really pop out from the Chaos Report:
First, you should focus on smaller projects instead of trying to fit everything you want to accomplish into a single grand initiative. This means prioritizing core functionality over trying to check off every item on a lengthy wish list.
Second, you should use an agile methodology. Scrum, for instance, entails breaking large projects down into smaller subprojects, each of which culminates (ideally) in the delivery of a working component for users to evaluate. This process repeats with the next most important component, then the next, and so on. The feedback at each stage gets incorporated over the multiple iterations, making the overall process highly flexible and sensitive to evolving needs.
The third lesson is that not just any coders will do; you should do whatever you can to get the most highly trained developers on your project.
To most developers, these lessons are no surprise. But the rest of us may still be left wondering why so many projects go off the rails and why agile methodologies like Scrum are so effective at keeping the process on track. For a custom application project to be successful, you need both extensive expertise with the technology and a deep knowledge of the business situation where the solution will eventually be applied. Many of the problems that arise in these projects come from failures of communication between tech people on the one hand and business users on the other. Scrum, by having the two sides come together at several points throughout the process, goes a long way toward bridging this divide.
To understand why agile methodologies (Scrum is just one of the most popular of them) make it easier to avoid common pitfalls in custom development projects, it will be helpful to look at some of the issues that developers run into almost every time they set about building new business software.
One of the main purposes of software is to automate tasks that workers formerly had to do by hand. The difficulty in pulling off this kind of automation is that tasks that seem simple to people who perform them every day often involve several complex subroutines that they seldom consciously think about. Or there are contingencies that come up so seldom that no one considers including the routine response in the system. As Matt Noggle, Aptera’s Custom Software Practice Leader, explains, “A lot of really complicated work goes into software that seems really simple.”
One example of this would be a catastrophe response that gets activated so infrequently that no one even remembers how it works… except for that one employee down in the basement. You end up having to go downstairs and ask her to show you what’s supposed to happen, and that’s assuming she still works at your company. Scrum, by focusing on core functions one at a time, ensures that important business rules that have been left out of the documentation are discovered early on, when there’s still time to adjust course without baking the holes into the software.
What do you call a customer who hasn’t purchased anything from your company in two years? Is this person still a customer, a prospect, or a complete stranger? What often happens is that, over the course of software development projects, the team discovers that people using the old system are applying completely different definitions to these categories.
If the inconsistencies are discovered early enough, this is easy enough to fix. You get everyone together and decide on a taxonomy. But, if you’re using an approach that’s not agile, you may get to the end of the project without even realizing the inconsistency exists. That means change orders and, quite possibly, extended deadlines and budget overruns.
When a requirements list is drawn up by management without sufficient input from experts in the specific subject matter, you’ll often discover that the higher-ups have some pretty significant misconceptions about how their workers or customers are using their devices. For instance, the stakeholders may come to the developers insisting that a web app be tailored to Android tablets, because they assume that’s what everyone’s using. But, once the app is delivered, they come to find out most of the customers are actually using Windows desktops.
One of the reasons our software team at Aptera does in-depth upfront discovery for projects is that it gives the developers a chance to understand real use cases so they can avoid this kind of mishap. A good discovery will focus, not on producing a checklist of requirements, but on understanding the ultimate goals of the project stakeholders. “It’s more important to know the why than the what,” is how Noggle explains it.
Discovery addresses this issue by bringing together subject matter experts and key players in the business activity, so the developers can figure out how the application will actually be used. But using Scrum can also help head off issues of misunderstood use cases. The goal of each iteration in the Scrum process is to have a minimum viable product (MVP) that can be shipped to the client for evaluation by real users. If what gets shipped isn’t right for the actual context in which it’s used, the discrepancy can be addressed before the difficulties are compounded.
Eric Potter, one of Aptera’s Software Architects and a Microsoft MVP, says, “We’ve never shipped finished software thinking we completed everything we wanted to do.” As the project progresses, there are always features that occur to you which seem like they’d be really nice to have. There’s always something else you could automate or some other application you could integrate the new one with. This may not seem like such a huge problem, but when you’re forced to decide on all these features upfront for a traditional requirements list you realize just how hard it can be to rank all of them in order of their priority.
“There are features you may use once a day,” Potter says, “features you may use once a week, and features you may use once a month. It’s the daily ones that are necessary. Those are the ones you need to focus on.”
With Scrum, you weigh the priorities before beginning each iteration, so by the time you’ve reached the project deadline you’ll at least know that you’ve got all the most important features and functions built into the software. You can always keep the remaining ones in mind for the next project.
Okay, these are two completely different things. But they’re both common sources of anxiety because they’re either difficult to plan for, in the case of integration, or easy to overlook, in the case of training. They may both be easier to handle in an agile framework as well, but neither of them is addressed quite as directly by the Scrum methodology as the other issues discussed here.
A common integration hiccup would be something like one system storing dollar amounts in cents, with no decimals, and another storing them as dollars and cents, with decimals. You don’t know there’s a problem until the figures come out completely whacky, and then you have to go in and figure out what went wrong and where. Training is something you should plan for early on, but many businesses are way too lax about it. Factoring in a little training can mean the difference between full user adoption and an application that fails to deliver any returns because no one uses it.
Agile methodologies help to avoid or ameliorate most of the issues discussed in this list by breaking larger projects down into smaller components and by breaking down the communication barriers between developers and business users. With any luck, frameworks like Scrum will continue to spread, developers will continue to improve their skill at putting them into practice, and those success rates for development projects will continue getting better.
Other popular posts like this: