Home: Resources for Selecting Software
Software
Prototyping

Quick Links

Quickly and easily gather your system requirements and prepare your RFI & RFP.

Learn more about RFI/RFP Templates for:

Using Prototyping in Software Selection

A brief review of using prototyping to obtain answers in the detailed selection phase

Once you reach the detailed selection phase, you will be down to looking at only a few potential new software systems. And you are likely to have many specific questions about each. One of the options to consider, is to carry out some form of prototyping of the potential system in order to get answers. This brief review looks at prototyping at this stage.

Things to consider with software prototyping include:

Your objectives / goals

What are you looking to find out? What do you want to learn from the prototyping? Get your project team and users together to determine, agree and document your objectives.

Objectives may include proving that the new software system will work for you, how it will handle specific areas/processes, testing key aspects, how specific processes would work in practice and how these may affect users.


What to prototype?

Areas to consider prototyping include tricky or complex processes that you cannot see how they may work in practice, from your previous vendor discussions or demonstrations. Or, you may wish to carry out a detailed investigation or test of specific aspects of the system.


Why do prototyping?

Prototyping can be a visual demonstration of the solution to a problem. Consider doing it, if it is a better or faster way to find out the information you are looking for, than any other option.


When do you need the information?

Time is often an issue in the selection process. When you need the information from the prototyping - will therefore have to fit into a tight time scale. This may well restrict the amount of prototyping to specific key areas, or force you to look at other ways of obtaining information.


How will you do the prototyping?

As with all selection work this should be carefully planned before commencing. The key steps include:

  • Planning – so you will know what is included and excluded from prototyping
  • Building the prototype(s)
  • Measuring and checking
  • Learning the outcomes
  • Documenting and presenting the results


Prototyping is likely to be of the ‘throw away’ type, ie used to validate or demonstrate specific aspects and then discarded. At this stage, you may not have decided which vendor to use. However,  hold on to any prototypes, as they may be useful during the main system implementation.


Where will you do it?

Part of the prototyping planning is to decide where the work should be undertaken. Do you split the work over a number of locations / teams? Or do you pull it all together, with the project team and key users into one location?


Who will be involved?

Input from end users is absolutely vital. The new system is for them and they need to be fully involved with the prototyping. So identify key users, free them up and get them working closely with the project team.


In summary, should you do any prototyping?

Yes, if:

  • This is the best / fastest way to find out the information you are looking for.
  • It is complex system area.
  • The benefits of doing it outweigh the costs.
  • You have the resources to do it ie the time, funding, people and appropriate skills.



No, if:

  • It is a simple or straightforward system area.
  • The costs outweigh the benefits.
  • It will distract the project team / users, away from other more critical selection tasks.
  • There is insufficient time allocated within the selection process or it will take too long.
  • There are other ways to get what you are looking for.

Other ways of getting the information include:

  • Putting more detailed questions to the software vendors
  • Holding more detailed vendor demonstrations, focusing on your precise issues or scripts containing sample transactions which would be processed through your system
  • Using a vendor consultant to review/analyse your requirements and establish how the potential software may work with your requirements.
  • Contacting other users (eg the vendor’s existing customers) either on the phone or physically visiting them to see how they manage such situations or have got round them.

 

For more system selection information visit: Selection steps / Stakeholder analysis form / Stakeholder management tips / Sample project plan / RACI Matrix / Project initiation checklist / How not to select software / Critical success factors / Software selection time saving tips / Project issue log / Requirements gathering techniques / Reasons to write a good requirements specification / System design review / Simple risk assessment form / Risk assessment worksheet / Project reporting form / Project Status Report Template / Software selection warning signs

Home | Privacy Policy | Site Map

17 New Road Avenue, Chatham, Kent ME4 6BA, United Kingdom   info@axia-consulting.co.uk

Copyright © 2017 Axia Consulting Ltd. All rights reserved.

 

Protected by Copyscape Plagiarism Checker - Do not copy content from this page.