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).
1 comment:
Vlias, I think two issues are involved in this commitment vs involvement challenge.
First issue is "Output" Vs "Outcome" mindset. For example if I am doing a requirement study my output will be requirement document, but my outcome is clarity of customer requirement for project/delivery team. If I am commited to output, I shall only worry about structure and information. If I am commited to outcome I shall worry about how team understands requirements and I shall do lot more than writing document. lot of people whole are output oriented work with mindset of "doing the work" while people with outcome mindset work with "creating a effect" mindset.
Second issue is scope of context. In what context team should operate. In the context of "effect" of work they are doing or in the context of "effect" of work larger project team is doing. I agree that the goals of both these teams should support each other (alignment) but I dont think these goals should be same. It will be too much of an overkill.
Post a Comment