Add to this, the volatile nature of requirements and stiff timelines - and what you really have is an attitude of "how do I get out of this?". Next comes the strict delineation of responsibilities at a micro level, & therefore it becomes nobody's' responsibility to oversee that the solution as whole is the way it should be.
That everybody is a stakeholder in the project in her own right, is a notion that is neither marketed nor ever sold. Especially in the Indian environment, the drive to get certifications, define and collect metrics, & documentation heavy process models mean that you have just a lot of data ( though I doubt how representative or true these data are), & perhaps a lot accountabilities fixed - but these aren't necessarily contributing to the ultimate business goal i.e. solving the business problem. What this is doing however, is taking focus away at a managerial level from the solution to the solution delivery process. At the same time, such data is important as it is used in future sales pitches.
It is important to revisit and reunderstand the following:
- That, irrespective of well defined granular responsibilities, it is ultimately the product that is the most important.
- How the team is helping: If actual numbers are not too sensitive, percentages can definitely be exposed. Numbers apart from money can be shared. This will go a long way in cementing a tangible picture of the ultimate business goal that the engagement is helping with.
- Encourage communication and personal interaction - Change is inevitable and the turnaround time is of critical importance. It is okay to bypass change management system in the favour of speed & product quality. Increased communication helps build trust and solidarity & helps catalyze such actions.
- Look to fix the problem & not the blame/responsibility.
