Should it still be written as a "requirement?"

[seaduspx]

Here's what the business wants from the application.

"A minimum of 100 forms shall be validated in a 24-hour period."

The IT shop has stated that they are not sure that they can do it, but they can try. The business has stated that "this is what we require."

Question: Since IT is not sure if they can meet this requirement, should it be documented? After all, this is what the business wants. But by putting their signature to the reqs doc, IT feels as though their hands will be held to the fire.

Thoughts?

Thanks everyone!

[gescober]

Here's what the business wants from the application.

"A minimum of 100 forms shall be validated in a 24-hour period."

The IT shop has stated that they are not sure that they can do it, but they can try. The business has stated that "this is what we require."

Question: Since IT is not sure if they can meet this requirement, should it be documented? After all, this is what the business wants. But by putting their signature to the reqs doc, IT feels as though their hands will be held to the fire.

Thoughts?

Thanks everyone!

Well, I find it hard to believe that something like this is "impossible" - it's usually about time or money. I think it's entirely appropriate for IT to decline to promise something without doing some initial feasability. I mean, there's nothing stopping the business from stating - "it's gotta do a 100 forms in 24 hours, make toast, make coffee, mow my lawn, and cost no more than $24.99." If IT wants to go away and come back with a price/time/resource estimate, that's entirely within their perogative. And, for stuff that's truly impossible ("it should read my mind"), then they can also come back and say they can't do it. But, they actually have to go to the effort of figuring this out rather than just giving a knee jerk response.

What IT should not do is say, "maybe" or "we'll do our best". Do the feasability and come back with an estimate. Let the business decide what they're willing to pay.

[ddelancey]

They don't know if they can do it at all? Or they don't know if they can do it within the time and budget constraints for the project? Either way, IT should not signoff until they are able to actually say one way or the other if it's possible.

[seaduspx]

So your saying that if they don't know if they can meet the requirement they should not sign off?

Here's the situation. The business side of the org currently has a system that CURRENTLY validates 100 forms in a 24-hour period. The current system was designed by an outside vendor. The internal IT division has been charged to create a new system and the business side wants to keep this particluar capability. IT has stated that they want to comply, but they don't know if there design will be able to do it until after the fact.

What do I do? Others want sign-off on the requirements.

Thanks!

[ddelancey]

So your saying that if they don't know if they can meet the requirement they should not sign off?

Here's the situation. The business side of the org currently has a system that CURRENTLY validates 100 forms in a 24-hour period. The current system was designed by an outside vendor. The internal IT division has been charged to create a new system and the business side wants to keep this particluar capability. IT has stated that they want to comply, but they don't know if there design will be able to do it until after the fact.

What do I do? Others want sign-off on the requirements.

Thanks!

Well, it really depends on the definition of "sign-off". Is it considered a contract to deliver exactly what is stated? Or is it simply an agreement that all parties understand the content of the requirements? It's a big difference.

Validation of 100 forms within 24-hours IS the requirement. The business has stated such. The question is what exactly is the business asking of IT by signing off on that? It would seem that a proof of concept would be appropriate at this juncture. Everyone would benefit from knowing if this functionality can actually be delivered.

If it can not be delivered, IT should be able to say why it can not be delivered and what they would need in order to get beyond that obstacle. The business can then decide if they are willing to give up that capability OR if they are willing to supply IT with what they need in order to get it.