• Engage specialists to capture the precise business requirements:
  • Business processes and policies
  • Use case and UML, depending on the complexity of the application
• Engage specialists to capture the precise user requirements
  • Understanding customer need and expectations
  • Understanding staff needs and expectations
  • Resolving these against the business requirements
  • Establishing a definitive statement of exactly how the application needs to work to allow people to achieve their goals and deliver business outcomes
• Create all user interface designs required to deliver the business processes and policies to the desktop
  • The information architecture
  • The workflows that reflect how people think and work, as well as best practice
  • All user interface designs for the entire application

These steps aggregate to what we call the IT Blueprint — a complete and unambiguous specification of what the application needs to do to support business and individual performance.

Go to market with the Blueprint

The Blueprint is just like a building blueprint.  The builders know exactly what needs to be done as they have a clear view of the end goal.

• Release the Blueprint to market for vendors and integration partners to quote on.  Because your requirements are now complete and unambiguous, you can easily determine who can actually deliver what you need to run your business effectively.

If there are confidential matters in it, then release it to a restricted group under NDA.  In this case you would release it to both packaged solution and custom development vendors.

• The Blueprint means the prospective vendors can precisely quote on the assignment as they know exactly what is needed and how ‘big’ the application is.  You don’t need to pressure the vendors on price, because they give you a fixed price quote on a fixed piece of work.
• As the project progresses, use the Blueprint to evaluate what is built against what is required.  If the gap analysis is large, you can easily enforce compliance, because you told them exactly what you wanted.  There should be no room for interpretation or misunderstanding.

This may seem quite a bit of initial work, but the fundamental causes of IT failure are poor requirements and an unusable interface.  You don’t see buildings go up, or cars getting built without a blueprint.

If you don’t get the requirements right up front, your project ends up experiencing high levels of iteration and multiple releases to get it right.  The ongoing cost to fix problems is easily between 10 and 100 times more expensive than the initial cost, in terms of direct redevelopment costs and lost opportunity.  It is always cheaper to invest properly up front, rather than pay for it many times over at the other end.

The initial activities that should occur up front usually account for a small proportion of the estimated project cost: typically around 10 to 15%.  But the net effect of getting this part right, first time, means that iteration is drastically reduced, as are post launch change requests.  This approach can halve the total cost of ownership, with everything required, available in the first release.

Unfortunately, many project managers fall into the trap of cutting development costs in an effort to curb the total costs of IT.  Activities such as requirements and user interface are often, mistakenly, considered optional and unnecessary.  But if you don’t know exactly what you’re building, then you’ll never get there.  What happens after launch is considered to be someone else’s budget / problem, or it comes out of costs already incurred.  Yet all of the costs contribute to the total cost of ownership, and affect the final return on investment of the application.  If all you do is break even, why did you bother disrupting your business or change your business processes to suit the application’s way of doing things.  You might as well have left things alone and spent the money elsewhere, or not at all.

New IT applications provide an ideal opportunity to instigate change and new business processes.  Therefore, make sure that they are the ones customers value and they create a positive benefit to the company.

Evaluating tender responses for the right vendor for your business, staff and customers

During tender evaluation, there are steps you can take to pick the vendor that can actually deliver on your business and user requirements.

Consider doing the following during your next tender evaluation:

• Engaging specialist usability and user interface designers to evaluate the application’s ability to provide a usable, high performance interface,
• Engage business specialists to evaluate the applications’ way of doing things for compliance with best practice in running businesses, that suit your business, rather than making you change your business to suit.

If the best result you can achieve is to reject all tender responses, then you’ve achieved the very desirable result of avoiding technology overruling your business.  More importantly, you have achieved this for cents in the dollar, compared with embarking on an ill advised ‘adventure’ with an inappropriate piece of software, with an ill defined set of requirements.  With the just described alternative approach, however, you are positioned to take alternative courses of action, such as a well defined custom development.

You have also avoided being trapped in a vortex that sees you having to do so much customisation to make the system work the way you need, that you are locked into continual upgrades with the base application; a process that can result in becoming unsupportable by the vendor.  At this point, you throw it out and start again.

Alternatively, if there is a good level of fit, you can choose a vendor knowing that they can actually deliver an interface that people will enjoy using to effectively do their work and achieve business outcomes for both you and your customers.

Managing development towards success

If you’ve already chosen your vendor, then you have an opportunity to determine user requirements and user interface (UI) designs before a single line of code is written.

If you’re into development, use requirements and UI design work can occur in parallel, informing the system architecture to ensure that the necessary interface can be implemented easily.

If you’ve finished development and are in UAT, then usability testing can identify any risks you may have prior to launch.  The last thing you want to do is launch a product that people flatly reject.  It’s hard to recover from user rejection and re-launch a refreshed application — people are easily jaded and don’t often give you a second chance.

In closing…