Recently I’ve been helping a few not-for-profit organizations in Waterloo Region get a grip on their large web and IT projects (by large I mean $20k ~ $200k projects). Although they are going relatively smoothly, I keep forgetting that the people in these organization don’t have the same background I do, and so what seems “common sense” to me, doesn’t always translate. So, for those of you working on (or planning) a large web technology deployment, here are a couple of tips that are helping my clients:
1. Be sure to evaluate and, if necessary, reject the consultants recommendations
Those of us that dare to call ourselves “consultants” make our bread and butter off recommendations. We’d like to think that our recommendations are usually right, but to be frank – we don’t know your business as well as you do, and we can make mistakes. Sometimes our recommendations are just plain wrong, or simply aren’t feasible given the people involved. This is especially true when the recommendations are coming from a technology vendor. These vendors live and breathe their own industry, and so, what may seem like a basic change to them, may be a formidable challenge to your organization. Don’t be afraid to tell a consultant/vendor that you can’t act on their recommendations. That being said – it’s generally nice to at least let them know why you can’t, so that they can keep those factors in mind for future clients.
2. Custom Code is nice – but very limited
If you are getting a custom application developed, my rule-of-thumb is that you can only expect a custom system to do 2/3 of what you would like it to do. Getting to 100% is pretty much impossible. The reason for this is that if a company is selling shrink-wrapped or off-the-shelf software, all their R&D time is spent improving the product for all of their customers. Whereas, if they are building custom software, they need to split their time up to work on highly specialized functionality. Because of the level of customization, the time allocated to a different customor is unlikely to benefit you. This directly implies a reduced feature set, less testing and less polish in custom software. This means if you have a custom system that has grown over time, and only does 80% of what you need, then “functionality” shouldn’t be your reason for replacing it. That being said, there are circumstances where your business needs are so unique that custom software is required, but those situations are far and few between. Chances are if you look in the mirror, your needs really aren’t as unique as they may seem – it really is worth the second glance!
3. Get help in defining your requirements
I’ve seen this a million times: the Director of Marketing sends out a staff email with something like “we’re putting together an RFP for a new website/CMS/CRM/accounting package/portal/laser printer, etc…please send me your requirements so I can document them”. The resulting RFP turns into a tumultuous mix of everyone’s disparate wishlists. Rather, an RFP should document requirements and objectives. Requirements should be broken into what’s needed (read: functionality you use now, without which you can’t run your organization) and what would be advantageous but optional (read: stuff that would be helpful but not a deal breaker). Objectives should illustrate the business objectives of the change: is it to increase productivity, improve stability, increase sales, or something else? The reason I indicate you may want help with this process is that it’s often difficult for someone close to the system to properly categorize requirements, and more importantly it’s hard to know how heavily you rely on something if you are using and it doesn’t break. An outside set of eyes can often help you better document our needs and ensure you don’t miss anything.
4. Try to avoid feature-envy
As a developer, something I would often hear is “I’ve visited the sites of other organizations and picked the features on those websites I like. We need to include them all”. This request is incredibly difficult to fulfill, and can very rapidly increase the cost of a project. Generally speaking, only a few of these features are going to assist in your business objectives, so let’s focus on them and keep the others for consideration. To draw an analogy, can you imagine going car shopping and telling the sales rep “I like the grill from the Ford F150, the handling of the Hyundai Accent, the interior of the new Camero and a hybrid engine. We need all that in the car“. There isn’t a car that can meet those desires, so you’re either going to have to settle for something else, or pay through the nose to get a custom vehicle built-to-spec for you. The same goes for your web project.