Wednesday, May 02, 2007

Commitment v/s involvement

A recent conversation with one of the project managers tasked with delivering services for enterprise (SDT -services delivery team), reminded me this old adage about commitment and involvement. The project manager said, "He is delivering to agreed project requirements and has put in a change control in place to handle the churn in requirement." So he believed SDT was totally involved with project for success of project and SOA initiative. The old adage goes thus, "In a breakfast of ham and egg, the chicken is involved but the pig is committed". What we need is not involvement but commitment (kind displayed by pig) from SDT.

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:

Ravi said...

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.

Wednesday, May 02, 2007

Commitment v/s involvement

A recent conversation with one of the project managers tasked with delivering services for enterprise (SDT -services delivery team), reminded me this old adage about commitment and involvement. The project manager said, "He is delivering to agreed project requirements and has put in a change control in place to handle the churn in requirement." So he believed SDT was totally involved with project for success of project and SOA initiative. The old adage goes thus, "In a breakfast of ham and egg, the chicken is involved but the pig is committed". What we need is not involvement but commitment (kind displayed by pig) from SDT.

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:

Ravi said...

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.