Ambiguous requirements can lead to purchasing software that doesn't meet expectations. Here are some simple techniques for avoiding ambiguities in your requirements.
Adequate and well-written requirements are the foundation for selecting enterprise software that meets expectations. A common problem with requirements is that some of them may be ambiguous. While ambiguities are easy to see in requirements written by others, they are difficult to spot in your own writing. Ambiguities cause problems selecting software in cases such as these:
It’s the unknown unknowns that get you every time! Learn how to identify unknown software needs, and then evaluate the urgency and importance of satisfying them.
While internal growth can drive companies to make major software purchases, another driver is external growth. Internal growth refers to a company growing organically through new customers, by mergers, acquisitions and so on. External growth refers to a company operating in a growing environment or a growing market, and is occasionally described with the phrase “A rising tide lifts all boats.”
Marketing technology is one such example of a growing environment, and it is spectacularly illustrated by Scott Brinker and his annual Marketing Technology Landscape Supergraphic. In 2011 he listed about 150 marketing technology companies on a single page in graphical format. Scott has updated this graphic annually, and in 2017 it contained 5381 products from 4891 companies. For several years there was an astounding 100% annual growth, although in 2017 it had tapered off somewhat.
In the corporate world many decisions are made in meetings, but too often things fall between the cracks. Here's a look at how a San Francisco law firm used new Workboard OKR software to solve the challenge of getting things done.
Even with the best will in the world, it usually takes too long to get things done in corporate situations. Meetings are a primary way in which goals are decided and agreed upon, but they consume inordinate amounts of time when you consider things like developing agendas and PowerPoint presentations, meetings that run over schedule, and the need to have some meetings again because you can’t remember commitments. Some things always seem to fall between the cracks, and results take too long to achieve. Workboard aims to solve this problem in a new way. To find out more, I interviewed Workboard CEO Deidre Paknad.
See how poor requirements analysis puts enterprise software purchases at risk of partial to outright failure...and how to fix the problem.
There are multiple reasons why major software purchases fail, but one of the most common is that of an inadequate requirements analysis. The problem is caused by people being unfamiliar with requirements gathering techniques, and by grossly underestimating the amount of work involved.
Requirements are to software selection as foundations are to a building. Get them wrong or leave things out and there always will be problems. This article examines the consequences of missing requirements in the analysis phase and describes how to avoid the problem in the first place.
In spite of the time and money spent, few software deployments meet expectations. Why? This article examines common reasons why selecting software is so difficult, so these problems can be avoided.
Successful software purchases meet or exceed expectations; failures do not. Failures vary in degree from benign -- e.g. those that are delivered late -- all the way through to outright failures where the new software is dumped and the project may be restarted.
In this article, we look at common factors that make purchasing enterprise software so difficult. Being aware of these difficulties before starting a project can help you reduce their corrosive effects on the success of your next enterprise software acquisition.
Think of business process management software as 'the oil that lubricates corporate machinery.' With dozens of options on the market, use the reverse-engineering technique to find the BPM system that best meets your particular needs.
While enterprise applications like ERP, CRM, HRIS and others cover their respective domains, business processes often need information to flow between these systems. An organization may also have specific processes that are not well handled by these enterprise applications, for example, unstructured or partly structured processes, or those touched by people outside the organization. The last thing you want to do is to customize application code to handle these types of processes because that makes upgrades difficult, risky and expensive. Another problem is that enterprise applications may not be easily adapted to changing business conditions.
To handle these situations, you may want to consider business process management (BPM) software. BPM could be seen as the “oil that lubricates corporate machinery,” allowing workflows to span multiple systems, coping with semi-structured or unstructured processes and allowing highly business specific processes to be built and maintained.
Many people think process analysis and optimization should be done before embarking on a software project. This article explains why it is unnecessary when buying cloud or commercial off-the-shelf software.
When an organization wants to improve operations, they can be faced with the choice of buying software or writing their own. If they decide to write the software themselves, early phases of the project involve business process analysis and optimization. However, writing software is an expensive and risky proposition for most organizations. Sometimes they can’t even finish what they start; for example see "An IT failure unicorn: Endless 19-year project in Massachusetts" by Michael Krigsman. If suitable software exists, it is usually far cheaper and less risky for an organization to buy the software than to write it themselves.
Collecting detailed software requirements from users is difficult. See how rewriting software features as requirements helps develop a comprehensive requirements list for selecting enterprise software.
When buying enterprise software, conventional wisdom says that users are the ultimate source of functional requirements. While this seems logical, it is incomplete because, apart from their pain points, few users know what they want from the software. The question is why does this happen and what can you do about it?
Why users can’t articulate their requirements
I loathe the banality of “the devil is in the detail”, but you can’t discount its wisdom when it comes to IT agreements. Let me tell you a true story about what happened during a software deal as a result of a divestiture. The original agreement provided for a divestiture re-assignment to another party with the vendor’s written permission, which permission would not be unreasonably withheld. I’m facing the vendor’s vice-president of sales and with a straight face he states; I’m allowing the assignment, I’m giving written permission but I never said there wouldn’t be a transfer fee and proceeded to demand a $900,000 fee.
With major software purchases, the key to maximizing success is preparation. Even if you already know what software you want, there are still numerous benefits to a rigorous evaluation & selection. Maybe the favored software is not the best-fit after all.
Rigorous software evaluations are a lot of work, and the payback only comes once the new software has been in production for a while. With a major software purchase, that can be months or years in the future. So what are the benefits of doing all this work?
The primary advantage of a rigorous evaluation and selection process is that you identify the software that best meets your particular needs. By definition, this software will return the greatest ROI. However, although a rigorous process minimizes the risk of selecting the wrong software, it is possible to select best-fit software by experience or even sheer luck. What, then, are the other benefits of doing all this upfront work? This article provides some answers to that question.