Requirements definition Supplier listing

A quick recap: 

We have looked at the pros and cons of COTS implementations. E.g.” Reduce development costs due to the mass production of reusable modules” or “What is the likelihood of customisation to meet all of the organisation needs?”  We discussed that COTS implementation is still a sizeable undertaking that many organisations take for granted.  We have a robust approach to ensure that the solution bought is the best solution to meet all the needs of the organisation: cost, value add, regulatory and use. 

What we want to look at today is;

• Problem definition: Research & Planning 
• Requirements definition 
• Solution & supplier evaluation 
• Solution and supplier selection  
• Solution implementation  
• Solution Review and sign-off 

Requirements definition and identify suppliers 

Identify the requirements 

This is a simple concept: Identify and document your requirements. But many business analysts will tell you that requirements are difficult to pin down. Requirements arise from;

• Previous analysis 
• Processes, records, training courses, manuals 
• Data storage and business continuity approaches 
• Consumer comments, other business areas comments 
• Regulatory needs. 
• Codes of practices, warning letters, industry trends 
• Technology trends 

• Existing defects 
• Interviews of functional areas 

Quantify the requirements based in risk 

As ever risk is central to every decision we make. No matter how you quantify risk (and no doubt you have a procedure for identifying and managing risks), establish clear definitions of what constitutes different levels of risk to your organisation (including ‘unacceptable risk’ as a benchmark). Prioritise the identified record keeping requirements according to this scale. An example can be: 

Step	Action
1	Assess conflicting requirements in terms of (e.g.):   the regulatory, safety or financial costs of meeting or not meeting the requirement  the business value of the information contained in the system  and so on…....
2	Identify and describe the consequences of not meeting each requirement, and determine the likelihood of each consequence occurring.
3	Weigh up the costs and benefits of meeting each requirement and the consequences of not meeting the requirements.
4	Discuss the issues with operational staff and management to reach an informed decision. Document this analysis and the decisions reached for future reference.

The results of this risk assessment, and risks linked to particular functions can help determine what requirements should be met. The various tables, matrices and other techniques used in risk analysis will help you to;

• identify specific areas of risk in your organisation 
• quantify and prioritise those risks in terms of the cost to, or impact on, your organisation (i.e. regulatory, safety, operational, financial and technical feasibility factors), and 
• make, justify and document recommendations for meeting requirements 

How to record a requirement 

There a plenty of requirements templates available, feel free to contact us for our version.  

Consider what data to compile in relation to each requirement;

• the name of the owner  
• the unique identifier 
• requirement description (objective language, UML) 
• any regulatory references 
• references to any linked requirements or dependent requirements 
• priority of the requirement  
• approval 
• requirement type (e.g. GxP, HR, Finance, Database, Business Continuity) 

A word of caution: Do not overstate the needs of the organisation. A supplier may need to respond to hundreds of requirements lists and it is best to have a list that details the needed requirements. A supplier will see the real needs of the organisation and better respond as a result. 

Upon completion, ensure to review the completed requirements with the functional areas and the project team. We find that a formal review process, where different reviewers assume different roles/perspectives provides a great static analysis of the requirements and helps reduce future faults. 

Contact us to find out more of formal inspections and reviews. 

Suppliers List 

The list of suppliers is ever changing. Research in this area is very important in order to be able to focus on a manageable list. Sources of information include: internet search engines and directories, consultants, industry associations, magazines, trade shows and vendors. Iteratively review and update this list to get the best list of candidates. 

Once a list has been established, seek to reduce this list based upon essential criteria. Once this is done, seek remote demonstrations from suppliers and reduce the list again to create a target list of suppliers for requesting proposals from. 

Draft RFP 

This step is often skipped, but in our experience it is the best way to communicate the full project requirements. There are plenty of RFP templates available. Feel free to contact us for our version.  

Elements of a RFP include;

• Organisation overview 
• Scope of project 
• Relationship with other systems 
• Schedule and deadline for response 
• Proposal instructions 
• Various services (e.g. training, QA/Test artefacts) 

Next time, we’ll examine the supplier evaluation portion of the COTS approach.