Does anyone have any thoughts on the content required in a document/briefing pack that would be sent to vendors re their involvement in a Proof of Concept?
Anthony CaleoProject/Program Manager| Infosys LtdMelbourne, Vic, Australia
I am seeking feedback from the community on the above query Saving Changes...
I can explain to you for IT project. Normally for IT project, e.g : New server procurement, the proof of concept document will be to proof the application performance is better compare to the legacy server. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
You have to decide the concept you need to proof. When that is decided then you have to clarelly define the features (functional) and non-functional requirements about the proof. For example, as @Ahmad said above. Do not forget any related to test when you specified the proof of concept. Saving Changes...
In addition to the above, you could consider the following: Objective of the POC. Standards, assumptions, constraints, restrictions, etc. (i.e. - the rules). Specific criteria for success/failure.
Also, you might consider whether to have each vendor sign a certificate of confidentiality or non-disclosure. (I would). Saving Changes...
Jason GrabowskiOwner / Master Scheduler| Baseline Achieved, LLCFredericksburg, Va, United States
I agree with all of the previous postings. To take it a step further, you first must define the goals of the proof of concept before putting together your docs that will go out to prospective vendors. I am assuming that this proof of concept has some level of risk that it could fail. With that said, you really must first decide what type of contractual agreement you will use with your vendor based on the level of risk that your proof of concept has.
If your proof of concept has a high degree of risk, you could look at a Cost Plus Incentive Fee or Cost Plus Fixed Fee contract that pays the vendor’s allowable costs plus a fee for profit. In this scenario, you would put together a statement of work that provides the background, any relevant standards and documents, and what support you are looking for and for what period of time. You just need to provide enough information for the vendor to know what level of support you are looking for.
If the proof of concept is low risk, you could look at a Fixed Price contract. In this scenario, you would develop a statement of work that provides the background of the proof of concept, any relevant standards and documents, and clearly defined requirements that you expect the vendor to meet. This requires a lot more detail since you are paying the vendor based on successful completion of the defined requirements.
So in summary, the content that you provide your prospective vendors is really based on what level of risk your proof of concept has. This will drive what kind of contractual relationship you enter into with your vendor. And the type of contract you us will drive what content you provide for proposals. This will protect your organization. And, it will ensure your vendor has a clear understanding of what you expect from them to support your proof of concept. Saving Changes...
