The requirement for a project invariably change. The service delivery team, being a subcontractor ro project team, is going to be last team to know about the changed requirements and the first one expected to be delivering its part due to changed requirements. So the SDT is going to be the fall guy for all the problems the project team is going to face, because SDT will not be able to deliver after being placed in such a precarious position.
So what we need from SDT, is commitment to project than involvement with project. Knowing and anticipating changes to requirements, from services perspective will be a key challenge. The major reasons for requirements changes I have seen in past is becuase,
Wrong people giving requirements
Strategy not getting properly articulated down the line, leading to wrong requirements
The first part is addressable by project team by involving all stakeholders, appropriately. Its the later part which results in major problems. Most business projects are result of some strategic decisions from executive. The way startegy gets articulated from top executive down to people executing projects, is nothing better than 'chinese whispers'. Every link in the chain adds their own spin, and overloads elements of strategy with their own agenda. The SDT, being an enterprise wide intiative, should be able to rise above these spins. So SDT needs to be committed to project success by being on par with projects, rather than being happy with a subcontractor status. Thats the only way a SDT approach will work in a large enterprise. SDT should be treated as one of the startegic projects undertaken by business, than a mere service provided by IT for rest of the projects.
This will guarantee SDT's commitment (of pig variety).