I am working on a large software implementation. We are past the RFP stage and currently working on the Statement of Work. Where I understand the importance of providing clear deliverables and success criteria within the contract, I have a resource that is taking that to another level. The requirements are something that you would find in a Use Case. I have only been at this job for a few months and this resource is telling me that this much detail is normal at this company. Yet, none of the other resources have provided this much detail on their attachments.
I have 2 questions:
#1 is there a risk to providing too much detail in the contract? Does it change your answer if you know that Fit/Gap is the first phase of the project? We have a high level understanding on what we are going to get but the scope is to modify the solution as little as possible.
#2 How can I get this resource to provide less detail and focus on what the vendor needs to deliver (and not tell the vendor how to deliver it).
Saving Changes...
Sort By:
Rogerio SantosDirector| .: RIZ | iko Software :.Rio De Janeiro, Rj, Brazil
I didn't agree with you, sorry. In my opinion, you should have detailed requirements on contract terms. As more detailed as better for you and vendors. If there are risk of gap or scope changing you must consider writting special clauses that share, transfer risks for someone or save money under contigence reserves account for risk issues. Telling to vendor what exactly, when and how (expected package and shape) will reduce risk and - at the end - cost. Saving Changes...
Al TaylorI.T. Contractor| IndependentWaterloo, Ontario, Canada
Good dialogue! The answer may depend on the nature of the contract, right ? Saving Changes...
Destiny OlivasIT Project Manager| Washington CountyHillsboro, Or, United States
I posted this question since a majority of my contract experience has been based on software development types of projects and I was hoping to get other opinions regarding the subject.
I think I have my views and filters on this subject because I have seen far too many situations where the customer goes in thinking they know what they want, then they see it and change their mind. My perspective is that in IT I much rather have business tell me their problem and let me decide the best way to resolve it, versus telling me how to resolve it. Being too detailed could lead to multiple costly and time consuming contract amendments throughout the project life cycle. I see no need to go down to the granular level (i.e. defining database fields) in a contract where the overall solution is still undefined.
By the way, I am speaking of technical requirements, not business requirements. However, the only business requirements that are mandatory in this project are those that are statutes and administrative rules. All others business requirements are nice to haves. Saving Changes...
Anonymous
Destiny, You're making me think of Agile! I work in the U.S government and I feel like I hear a lot of vendors say it is hard to price projects like this. Ones where the solution is undefined. But I think you hit the nail on the head by drawing a distinction between business requirements and technical requirements. I'm happy to spell out what the product needs to do (BRs) with some basic TRs. And let someone like yourself tell me the best way to resolve it - through response to a RFP, etc. Saving Changes...
