I worked as an independent consultant at GM (run by EDS) and at Sky, cleaning up the mess they left behind.
Firstly, on behalf of all the independent consultants and contractors at both sites let me say thank you to EDS. Thank you for our fees. Without your stunning incompetence all down the line none of this would have been possible.
The reality at Sky:
I joined a couple of years after EDS was slung out. Sky had a creaking legacy (green screen) customer installs system. They needed a comprehensive, fully architected CRM system capable of handling their millions of customers. EDS came in, did a brilliant sales demo, then sent in the drones. This is their standard operating procedure. They have smart people to call on - for sales calls. When it looked like they were about to get slung out of GM suddenly the kind of guys who wrote RFCs were all over the place. Once the attention was off they disappeared back to sales calls. This is how all outsourcing operations run.
Sky discovered pretty quick that they were being handed a pos that could never scale to a multi-million customer operation. Pretty quick being after a couple of years of pointless development. After they ditched EDS things didn't really improve: every department (customer services, billing, actuarial, etc etc) chose a "best of breed" app (more like "best of sales demos" app) then spent years customising it to fit. Then a bunch of said indy contractors tried to integrate it all together. We did the best we could.
Counting the bodies in the development halls, and allowing for what Sky had to pay to get people to work in Livingston (Detroit was comparable, if rather bigger) I'd estimate their costs at £50+ Million a year over rather more than five years. This settlement would put a big dent in that, but it certainly won't cover the cost of EDS's truly monumental incompetence.
Coda:
Between the GM and Sky gigs I had a drink with Compaq's top salesman in Toronto. I related the disasters at GM for amusement value, only for him to express his undying affection and admiration for EDS. What goes, I asked, for there was a twinkle in his eye. He explained thusly.
EDS would come to him for a quote for 10,000 PCs in their upgrade cycle for a major client. Said salesman would provide a quote for top of the line PCs at below cost price. A massive loss for Compaq. He would put this deal on paper, fully specced, and pass it across the desk for signatures.
*Three years later* EDS would come back with the sign-off and a purchase order. Compaq would give them 10,000 of the dregs of the warehouse. They would all surpass the three-year-old spec in the contract. Massive profit for Compaq.
I imagine the salesman made a pretty decent bonus too.
We have already Geo-engineered the planet - we have injected massive quantities of CO2 into the atmosphere, and continue to do so. Attempts to alter the behaviour of human beings to reduce these effects have run into the quicksand of global politics and vested interests. We should keep trying to find ways to reduce the input, but so far we've failed even to agree to reduce the rate of growth of the CO2 injection.
We'll continue to fail to get agreement on reducing emissions until such time that all countries are losing thousands of people and billions of dollars annually to weather disasters (when do we stop calling them 'natural' disasters). By this point the feedback loops of massive forest fires and melting permafrost will render the agreements moot. We'll be at the stage where we need to do *something*, even if it's half-assed, and poorly understood in its effects.
Right now we are doing geo-engineering - blindly and stupidly we're increasing the temperature, "anti-terraforming" if you will, and we'll need to find a way to reverse this once it starts causing mega-deaths. Let's hope we work out a way to reverse the process that doesn't do the same.
Plenty of other posters have pointed out that you sound a like an operation that is a bit small for the full Software Development Process. However if you're asking I suspect you're a growing company, in which case you need to get a Process in place, and soon or you will experience the full agony of a chaotic IT environment. (NB That's where I work now - I've worked sane places too)
Fairly typical Process:
1. Dev receive Requirements and Defects from the Business, and code to them, unit testing their code ().
2. Code is delivered to Operations with a 'Release Note' or equivalent covering how to deploy the code to Environments
3. Operations deliver (deploy) the code to test environment(s). Link and Acceptance testing is performed - does it meet Requirements? are key defects resolved? Plus regression testing - does it break the existing system? Test sign it off if it clears these tests.
4. Operations deploy the code to the Production system on sign off.
You inevitably end up with tensions in the Business vs IT, plus the divisions between the priorities of Dev, Test and Operations. Sounds like you are at the stage of not having any well-defined roles/teams for these responsibilities. I'll detail the Operations breakdown too.
Operations:
As others pointed out this breaks down into various teams. DBAs, Sysadmins, Change Management, Release Management, Operators, depending on your site. Operations are responsible for the stability and smooth running of the Production system - they must accept change, but control it.
Since I work there, and you specifically address the subject, I'll detail Release Management too
Release/Change Management
Usually end up the Gatekeepers on changes. They'll need to be familiar with the whole system, and resistant to the pressure they'll receive from all sides. They need to know what versions of code are where, and be able to reject bad code when it turns up, but be flexible enough to make sure Test have something to test. They need to be experts on everything your IT does. No jobsworths here, and good generalists are rare. Since you'll inevitably go through a period of chaos if you are growing I'll mention that staff turnover here is very high - unless you get in contractors, and pay highly for them.
The Change Management role, sometimes covering the Release role too, is to track changes and know who they impact, and be able to prioritise changes. If Release and Change roles are separate, CM is closest to the business.
Hope that helps.
Slashdot Mirror
We've always been at war with Eastasia
I worked as an independent consultant at GM (run by EDS) and at Sky, cleaning up the mess they left behind.
Firstly, on behalf of all the independent consultants and contractors at both sites let me say thank you to EDS. Thank you for our fees. Without your stunning incompetence all down the line none of this would have been possible.
The reality at Sky:
I joined a couple of years after EDS was slung out. Sky had a creaking legacy (green screen) customer installs system. They needed a comprehensive, fully architected CRM system capable of handling their millions of customers. EDS came in, did a brilliant sales demo, then sent in the drones. This is their standard operating procedure. They have smart people to call on - for sales calls. When it looked like they were about to get slung out of GM suddenly the kind of guys who wrote RFCs were all over the place. Once the attention was off they disappeared back to sales calls. This is how all outsourcing operations run.
Sky discovered pretty quick that they were being handed a pos that could never scale to a multi-million customer operation. Pretty quick being after a couple of years of pointless development. After they ditched EDS things didn't really improve: every department (customer services, billing, actuarial, etc etc) chose a "best of breed" app (more like "best of sales demos" app) then spent years customising it to fit. Then a bunch of said indy contractors tried to integrate it all together. We did the best we could.
Counting the bodies in the development halls, and allowing for what Sky had to pay to get people to work in Livingston (Detroit was comparable, if rather bigger) I'd estimate their costs at £50+ Million a year over rather more than five years. This settlement would put a big dent in that, but it certainly won't cover the cost of EDS's truly monumental incompetence.
Coda:
Between the GM and Sky gigs I had a drink with Compaq's top salesman in Toronto. I related the disasters at GM for amusement value, only for him to express his undying affection and admiration for EDS. What goes, I asked, for there was a twinkle in his eye. He explained thusly.
EDS would come to him for a quote for 10,000 PCs in their upgrade cycle for a major client. Said salesman would provide a quote for top of the line PCs at below cost price. A massive loss for Compaq. He would put this deal on paper, fully specced, and pass it across the desk for signatures.
*Three years later* EDS would come back with the sign-off and a purchase order. Compaq would give them 10,000 of the dregs of the warehouse. They would all surpass the three-year-old spec in the contract. Massive profit for Compaq.
I imagine the salesman made a pretty decent bonus too.
Meet the new boss. Same as the old boss.
I think a lot of people have missed the point.
We have already Geo-engineered the planet - we have injected massive quantities of CO2 into the atmosphere, and continue to do so. Attempts to alter the behaviour of human beings to reduce these effects have run into the quicksand of global politics and vested interests. We should keep trying to find ways to reduce the input, but so far we've failed even to agree to reduce the rate of growth of the CO2 injection.
We'll continue to fail to get agreement on reducing emissions until such time that all countries are losing thousands of people and billions of dollars annually to weather disasters (when do we stop calling them 'natural' disasters). By this point the feedback loops of massive forest fires and melting permafrost will render the agreements moot. We'll be at the stage where we need to do *something*, even if it's half-assed, and poorly understood in its effects.
Right now we are doing geo-engineering - blindly and stupidly we're increasing the temperature, "anti-terraforming" if you will, and we'll need to find a way to reverse this once it starts causing mega-deaths. Let's hope we work out a way to reverse the process that doesn't do the same.
Plenty of other posters have pointed out that you sound a like an operation that is a bit small for the full Software Development Process. However if you're asking I suspect you're a growing company, in which case you need to get a Process in place, and soon or you will experience the full agony of a chaotic IT environment. (NB That's where I work now - I've worked sane places too) Fairly typical Process: 1. Dev receive Requirements and Defects from the Business, and code to them, unit testing their code (). 2. Code is delivered to Operations with a 'Release Note' or equivalent covering how to deploy the code to Environments 3. Operations deliver (deploy) the code to test environment(s). Link and Acceptance testing is performed - does it meet Requirements? are key defects resolved? Plus regression testing - does it break the existing system? Test sign it off if it clears these tests. 4. Operations deploy the code to the Production system on sign off. You inevitably end up with tensions in the Business vs IT, plus the divisions between the priorities of Dev, Test and Operations. Sounds like you are at the stage of not having any well-defined roles/teams for these responsibilities. I'll detail the Operations breakdown too. Operations: As others pointed out this breaks down into various teams. DBAs, Sysadmins, Change Management, Release Management, Operators, depending on your site. Operations are responsible for the stability and smooth running of the Production system - they must accept change, but control it. Since I work there, and you specifically address the subject, I'll detail Release Management too Release/Change Management Usually end up the Gatekeepers on changes. They'll need to be familiar with the whole system, and resistant to the pressure they'll receive from all sides. They need to know what versions of code are where, and be able to reject bad code when it turns up, but be flexible enough to make sure Test have something to test. They need to be experts on everything your IT does. No jobsworths here, and good generalists are rare. Since you'll inevitably go through a period of chaos if you are growing I'll mention that staff turnover here is very high - unless you get in contractors, and pay highly for them. The Change Management role, sometimes covering the Release role too, is to track changes and know who they impact, and be able to prioritise changes. If Release and Change roles are separate, CM is closest to the business. Hope that helps.