InfoPath Dev

We are developing simple InfoPath forms that have SharePoint Designer workflows to route them for approvals. (They have customized emails, so we're not using the OOTB Approval Workflow.) Sometimes the workflow adds the items to another list. Nothing too complicated. We're not using any custom code.

What, if any, are the risks of creating something like this directly in the production environment, versus building it in dev, then moving it to stage for testing, then to production?

We have developers who build forms and workflows right in production without any issues. But our contract SharePoint admin lead is trying to push some of us into using a much more complicated process that would take our development of simple forms from being something that could be created in one day in production to a multi-stage process that takes a minimum of weeks because of the bureaucracy of our IT organization...Trying to figure out if this is really necessary or if they're just trying to complicate the process to give themselves more work (and therefore more billable hours).

 Well - as a developer, I have some strong feelings about this. Especially since I often do development work for outside clients. I am always worried about doing damage to production data with a change, and then having to figure out how to fix it (if that's even possible). Like - what if I do something stupid in my workflow, and no one notices, and I've accidentally deleted customer information for 50 list items before someone realizes something is wrong?

For sending emails, I probably want to initially set up emails to send to a test account, so I can see the contents.... not actually send them to the person who approves. Am I supposed to be changing production data, or adding data to a production list in order to test this?

If there is a bug, I can go to my dev enviro to reproduce it. This allows me to have a sandbox where I can try whatever I need to try w/out worrying about disruption to a production system.

If I have a Test environment - this means I ALSO am able to test deployment steps, so when I go to production, I'm secure in the knowledge that I know what I'm doing.

I am a HUGE proponent of Dev > Test > Prod. It may sound as if they are overcomplicating things, but they aren't - they are protecting you, and your production data & site. They are also protecting themselves from having to clean up after some bug or development incident in the production environment.

And yeah, the bureaucracy sounds nightmarish, if it will now involve weeks, but perhaps if IT understands that this process offers a higher level of security & protection for the company as a whole they could consider some level of fast tracking the process? 

 Thank you, that is very good information. I appreciate the feedback, Hilary!