Having observed a number of organisations approach to procuring new IT solutions we have gained a new understanding and insight to the issues that affect successful outcomes. Often the very people charged with the assessment and final selection who may well be highly proficient in the utilization of software are actually not particularly qualified when it comes to the analysis required to arrive at the best possible selection. This role may be better handled by a committed partnership between a software provider working in collaboration with representatives from the internal organisation to identify a specific design and specification brief. This approach recognises the expertise each party brings to the solution – staff from the internal organisation should be the experts on their organisation and the software provider should be the expert on scoping of the software to be developed. The process must be honest, transparent and realistic to achieve an optimum outcome and doesn’t preclude the purchaser going out to tender. If the purchaser goes to market with a poor tender or RFP document the risk becomes that IT companies tell prospective clients what they want to hear, or just make it up as they go, rather than the truth or facts which can unfairly penalize the company making the pitch.
#2 – Collaboration versus the RFP process
Without exception, the RFP’s we have looked at are particularly one-sided with great detail about the expectations and demands of the purchaser but with little or often no consideration to the reality of what is being requested. So while RFP’s may be an academic best practice approach they can also limit the possibilities of forming partnership or acting in co-creation. Our preference is to avoid the RFP process altogether and foster creativity in collaboration, by leveraging the knowledge and experience of both parties. We have found that open transparent and robust debate will invariably deliver superior outcomes, and it seems this is something the RFP process doesn’t naturally allow. The other mistake as we see it is the specification for the project is nearly always ridiculously overly complicated and in some cases we see areas in an RFP that are in direct conflict with each other, in other words some of the design isn’t even possible or if it is, the user experience will be difficult if not impossible. It would seem inexplicably in the specification stage executives can forget to consult the coalface and somehow become curiously disconnected from basic requirements at delivery, which in turn results in the project starting off on the wrong foot.
Real intelligence in design always seeks to simplify even if the specification is highly complex. This alone may be one of the single biggest hurdles to success
#3 – Staged rollouts
Because in software development we are regularly entering uncharted territory (especially when we are developing unique IP) we accept that we don’t know what we don’t know, as theory rarely matches reality. Versions are a fantastic way to implement and rollout less complicated platforms that allow the end user to derive a friendlier experience, ownership and buy-in to the project in turn facilitating feedback which enables fine tuning and cost effective responses for issues we couldn’t possibly have anticipated without this collaboration and feedback. Why? Mostly because the IT vendor can’t and shouldn’t know more about the business end of the client organisation than the client themselves. If we accept this prognosis then the transformation of client’s requirements into a viable IT solution is where a lot of projects derail, simply because so much gets lost in translation.
#4 – IT Solutions aren’t a substitute for leadership
A good IT platform should enable the organisation to be more effective and efficient and in particular faster and more responsive and in so doing should simplify process and remove barriers in delivery thus creating the opportunity to do more with less which in turn helps lower the cost of doing business. Real time information as a result is available to support better management and response to opportunities.
A temptation presents when the client organisation has deficiencies in its management and seeks to counter this by creating mandatory fields designed purely to react to this issue. The rationale being ‘if we can’t get our people to do what we want them to do by good management/leadership practice’, then we can force them through the design of our software. The problem with this approach is it runs a counter intuitive design which creates more complexity, alienates employees who are then more likely to go about sabotaging the project, something they are particularly well positioned to do should they choose.
#5 – Bigger isn’t necessarily better
Often we see what appear to be requests for proposals that have been crafted in such a way as to deliberately exclude New Zealand or smaller vendors from the selection criteria.
Ironically the NZ IT sector is spectacularly successful in offshore markets and there are numerous examples of world leading approaches that have been created in this country. Why is it that NZ Government and business procurement tenders regularly go to large offshore providers? We know very well that smaller companies that will work in partnership are more flexible and often better able to meet requirements at less cost.
For most organisations today getting your IT strategy right is a make or break proposition simply because of the investment required and the ramifications if things go wrong. The stunning reality would suggest that organisations are slow to learn from previous well documented mistakes of others and if not careful will only be destined to repeat them.