Its often expected by customers that the vendors take ownership and full accountability of the projects and related pitfalls. While on one hand its good to take ownership of the tasks in your project and deliver them on time, within budget and exceed expectations, its equally important to understand the remits and scope of your work and project before assuming the responsibility & the accountability of failures.
Not only by the customers, but the display of the ownership from team is demanded by project managers & senior managers as well.
A Dilbert strip below just about sums up how the management assumes project teams to “own” things !
Quite rite ? Do you think so ?
It is essential, to demonstrate the capability to own and deliver the things, however it is equally important to know the limits of the ownership and a clear understanding of what you should deliver and be accountable for.
If you are into application support and maintenance projects, its even more important to know your project boundaries & scope so you could actually define the components you own and maintain.
Typically in the support projects, with the scenario of multiple support teams supporting various components in an end to end journey, the problem or fault can lie in any one or more components in the chain.
If any service impacting incident occurs in such scenario, I have seen customers pushing the front end (or Portal or Website) support teams for solutions and RCAs. Irrespective of where the problem or issue lies. It is fact that in a web based journey the problems are only visible in browser and thus generally it is perceived that the teams that supports the actual portal application are responsible for owning the investigation & resolution of issues.
Generally it is OK for the ASGs to take up the responsibility of owning the issues & try to get a solution in place ASAP. However, it is probably too much to expect them to own the end to end stack and push for investigation & resolution where the fix lies outside the boundary of the support team. In such cases, I would rather have the E2E Service Managers to own the fault and drive the resolutions through the downstream systems rather than the poor portal ASG teams.
I do not think there is any concrete definition or rule which says which tasks / issues / problems / escalations you should own up and which you should not. However, in case of the conflict I would suggest it is always better to stick to the rulebook (i.e., scope of work, application boundary) and take a wise decision.
After all, you would not want to lose brownie points !!
Comments