There are many ways for an organization to implement a software solution, whether it is an automated workflow tool, a digital asset management system or some combination of functionality that uniquely fits the needs of the organization. Hopefully, process is used to identify the needs of the organization and the solution candidates, as well as to manage the eventual selection and rollout of the final solution. We won't discuss the other strategy that usually starts with "I just saw this really cool app!"--that one is usually doomed for failure.
It should be pretty well understood these days that selecting a software tool has to be based on much more than cool interfaces and buzz words. Part of this understanding is that it's important to identify requirements, and then use those requirements to drive selection of the appropriate tool. The challenge is that there are many types of requirements, and you need make sure you're identifying the right ones. And that can be dependent on the type of solutions you're considering.
Let's take a workflow system as an example. These systems can cover everything from basic project scheduling to resource load balancing, automated task management and CRM functionality, and require significant definition up front. So, scope is often the first thing to look at before even thinking of defining the requirements. Then the next question is, what kind of requirements is necessary in order to define your needs? Well, some of your requirements choices are:
- Functional
- System
- Security
- Internal/External Access
- Import/Export
- Integration
- Customization
- User Management
- IT Platform
How do you decide just what you need in order to define your project? Well, it all starts with functional requirements. In business language, what do you want to accomplish with this system? That is, of your overall activities that are necessary to do business, what are you going to expect a software solution to either contain or enable? It's very important to be clear and realistic at this point, and it may be necessary to step back and look at short-term and long-term goals. If the scope and functional requirements are not well defined, your probability of successful implementation is not very high.
Now, what about all those other requirement categories? It really depends where you are on the "build versus buy" spectrum. If your functional requirements and your budget indicate that a configurable packaged software solution will meet your needs, then most of the other requirement types are really not necessary. For example, if you are going to implement a hosted project scheduler as a departmental solution and that will meet your functional requirements, then things like integration requirements are much less important.
On the other end of the spectrum, if the long-term vision is a fully-integrated enterprise marketing resource management solution that will talk to enterprise legacy systems like finance and document management, then it's important to take a deep dive into things like integration, security, user management and custom development needs. The biggest problems usually occur when a deep dive is used to pick a packaged solution or when only functional requirements are used to try to define a large enterprise system.
A final thought to consider is what resources to involve in your requirements definition. If the scope is pointing toward a packaged solution, then it's important that good functional requirements are developed so they can be mapped to solution capabilities as part of the solution selection process. On the other hand, if you are either developing or integrating with enterprise systems, IT or outside technical resources need to be involved in order to fully define things like domain models, context diagrams and use cases. Just make sure that the resources fit with your eventual goals.
Software solutions are available at many price points, but regardless of the cost of the technology if the selection, implementation and adoption process are not well managed with knowledgeable, dedicated resources, the likelihood of success and recognizing an ROI on your investment is significantly lower. We've seen many creative teams fail in this regard--don't underestimate the amount of upfront effort necessary in these projects.
