Define or Die!

A recent article in CIO magazine asserts that over 50% of IT projects fail. The article states, I think quite correctly, that the reason for this is that the systems that end up being implemented don’t align with the business interests for which they were intended. It isn’t a technology failure, it is a requirements failure. The takeaway is this: define or die! We must learn to define what we want before we go to the immense trouble of building this complex computer infrastructure.

Requirements Come First

To create a successful software system, one must work to define exactly what the business purpose of the system is. This is not always as obvious or simple as it sounds. Many people think that if they briefly describe their needs in a short meeting, and point to an example site or similar system, that is all that is needed. It is indeed helpful to look at legacy or example systems! But the truth is, one cannot simply roll up one’s sleeves, start magically programming, and make problems dissolve. The root problems aren’t programming problems. They are business model problems. They are logistical problems. They are workflow problems. They are human resource problems. They are financial problems. They are common-sense thinking problems. Our aim at Envision Data is to make your software systems start to revolve around your business issues, instead of letting your business issues revolve around your software system issues. Software systems should help, not hinder, the solution to these more fundamental problems. You should be free to think about your business as a business leader, instead of having to think as a computer person.

Where to Find Requirements Gold

How do we discover these requirements? Where to start? In general, even the most visionary and clear-minded business leaders are going to have a hard time sitting down to outline their brilliant common-sense vision from start to finish with no hiccups and mistakes. In fact, most business leaders don’t have the time for this nor do they need to have this level of knowledge about everything in their company. Micro-managers are not successful managers, so in a thriving enterprise, there will be much that is important that owners and high-level managers don’t know. The truth is, logistical knowledge of the business is scattered throughout the organization, sometimes in very unlikely places. It is the job of the requirements analyst to gather this scattered knowledge, and to understand it – not to improve it, not to second-guess it, but to honor the time-tested wisdom that has caused this business to succeed. Any new software changes must honor this hard-won experience that resides in the business, and must enhance it in ways that everyone understands and views as helpful.

Laser-like Focus

Without the focus of clearly defined requirements documentation, designers and developers can only guess what they are supposed to really be doing. It is easy, given the complexity networked electronic systems which handle the demands of so many people, for very smart and well-meaning workers to go astray. Everyone wants to try the latest new framework. Everyone wants to play with the latest design trends. But the requirements must be paramount or none of these things make any difference. As time goes on and work is being done and money is being burnt, without requirements documentation, you the owner/manager will not know how to ask if the project is on target to achieve your goals. Requirements documentation puts owners and managers back in charge of the very well-meaning and smart people who manage the computer systems.

Requirements frees up Solution

When you define and then design, it is a great benefit to realize that it separates the vision from the solution. You can clearly define what you really want to happen, without wondering how to make it happen. Perhaps your current setup can handle it, or there is a prebuilt system out there which can handle it, or perhaps you need to build something new. You can’t even make these decisions about solution unless you’ve thought through what you want in the first place. Then you can look at your existing infrastructure, and your options for already built systems, and your options for custom built solutions, and decide how you want to proceed. If your current infrastructure could be adjusted to handle 80% of your needs, and integrate with a custom built system to provide the rest, then you saved EIGHTY PERCENT of your time and costs! Separating Definition from Solution allows this kind of creative thinking about solving your problems the most efficient way. It allows you to look squarely at the situation from a business perspective.

Requirements Documentation = The New Sexy

Business analysis and requirements documentation is the sexy beast of the software design world. There is nothing as agile and adaptive as changing the words in a document until everyone knows that if this gets done, it will really make things better. The more precise the information, then the better the design will be. The better the design, the better the programming will be. It is impossible to design a great system without this knowledge. It is impossible to build a system which was not clearly defined first. Really excellent requirements documentation is your way of knowing that your vision has been understood, and your development dollars are not going to waste. The main thing you need in an IT consultant is not expertise in some specific technology. You need trust that your requirements have been thoroughly understood and are being as faithfully and straightforwardly implemented as possible.