The other day I was griping about our content management system, an activity I and other editors indulge in fairly regularly, as do members of our small IT staff, who probably get sick of telling us that it'll take a fair amount of custom development to add any kind of new feature to our site. In fact, although the system is not yet 2 years old, there is a growing chorus of folks lobbying to replace it.
Perhaps the system wasn't vetted as thoroughly as it should have been. I don't participate in technology evaluations, so I wouldn't know. But I think the problem is more fundamental than that. As I told my boss the other day, content management is one of those areas that, for companies like ours, is filled with a surprising number of specialized processes. Thus any off-the-shelf software application -- not just the one we are currently using -- would likely fall short of the functionality desired by our users.
Less than a week after having this discussion, I saw a Dr. Dobb's Journal article written by Mike Jones, VP of software development company Outsystems, that summed up my feelings about packaged software pretty well. He wrote:
Best practices aren't necessarily one-size-fits-all, especially in corporate IT. What works for one IT environment may burn another to the ground. This is where off-the-shelf software falls short -- most of it might work with your enterprise, but parts of it will need more than just "tweaking" to work with your business. With large amounts of customization, package implementations become very brittle and expensive, often resulting in difficult upgrades and an inability to respond to changing business needs.
Yet despite this reality, companies have long bought into the idea that they can shorten development cycles and cut costs by starting with packaged applications. That was Waste Management's goal when it purchased ERP software from SAP, according to a CIO.com story recapping the company's two-year lawsuit, $100 million lawsuit against SAP, which ended earlier this week with a one-time, undisclosed payment from SAP to Waste Management.
Whether it's packaged or custom-built software, the crux of the issue might be users who simply don't know what they want or have trouble conveying it to developers. In statements responding to Waste Management's complaint, SAP faulted Waste Management for not adequately defining its business requirements. Jones writes that "business users typically don't know exactly what they need from an application," which leads to lots of rework and results in time and budget overruns.
To be fair to users, it's not so much that we don't know what we want now; but it's hard to predict what we'll want months down the road given the rapid pace of business change. Jones, whose company specializes in agile development, not surprisingly promotes it as a solution to this problem. He writes:
With Agile, developers start with a high-level set of business needs to guide their team. The team then addresses the most glaring or important need, and shows a working demo to the business users within a very short period of time. User feedback is solicited to add more detail, and then iteratively and continually to build out the system. By embracing and expecting change upfront in the project, IT and the business can work together, building the right solution based on business feedback and priority.
Sounds good, right? Agile appears to be gaining momentum, with a recent Forrester Research survey finding up to 46 percent of IT pros said agile software development was being used at their companies. It's far from a panacea, however. A lack of communication between business users and developers will derail agile development projects just as it will wreck more traditional waterfall development projects.
We use agile development techniques here at IT Business Edge. When I interviewed Steve Hardin, ITBE's VP of software development, about agile, he told me it's easier to get both developers and business users "excited and focused" with agile, with its emphasis on breaking a software project down into smaller increments and producing more frequent deliverables. However, scope creep can be an issue, thanks to agile's at least theoretical flexibility in adding new features. If this occurs, said Steve, "you have to go back to the original business need" and make clear it'll require extra time and money to add features.