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.
Like sales & marketing, software acquisition has a funnel. See how to use this funnel to reduce the pains so prevalent with major software purchases.
In science, everything that is observed to happen must have a cause. Although the root cause of most problems with major software purchases can be traced to inadequate requirements, what is the cause of that problem? Why do so many organizations have inadequate requirements? The answer is that few know how to evaluate and select enterprise software. While it looks deceptively easy, in practice it is anything but.
Anybody who has worked with sales & marketing would be familiar with the sales funnel, which describes the steps needed to sell a product or service. The software acquisition funnel is similar but views the process from the perspective of the buyer rather than the seller. Note that in the diagram below the volume of each of the four buying phases corresponds to the amount of work in that phase, and shows that most of the work in a successful software selection is in the requirements analysis. This article looks at each part of the funnel.
The pain of a major software purchase going wrong can lead to wishing the project had never been started. However, by then contracts are signed and it is too late to do anything about it. Read and be warned!
In some ways selecting enterprise software is like painting a house - the key to success lies in the preparation. Rather than doing the work demanded by a mature software selection process, some organizations take shortcuts and create unnecessary pain for themselves. By the time they realize just how much pain they are in for, contracts are signed and it is too late to do anything about it. This article lists many of the pains caused by partial or outright software failures to help justify the effort of doing the up-front software selection work.