Agile Montage

For as long as I know, consultants have been thriving on the demand for improving processes, helping businesses transform, design and deliver solutions, and make decisions. They all seem to be types of engagements where you provide a service, add value, get paid for it and walk away, often like a star. But what you leave behind is a very temporal product that will again require your or some other consultant's services to make changes to it. One of the other types of engagements that I have been associated with lately also is 'enablement', where it is my responsibility to ensure that the client understands what I do and how I do it, and so it is for my other team members who represent Development, QA, Project Management, etc. The differences between the two is huge. From the fishing world analogy, it's the difference between catching a fish on client's behalf and teaching the client how to fish. The end product in both cases is the fish but it's the experience and the skills attained that make the difference. This is how I differentiate between 'delivery' and 'enablement' projects.

This differences, however, start to blur when the teams are co-sourced. By 'co-sourced' I mean that there is client member representation in almost all of the activities like analysis, development, testing, etc. It may very well be a delivery project but the team structure and the dynamics start to make it look like an enablement project. This illusion gets stronger as the proportion of client representation in the team start to grow.

With co-sourced teams one of the challenges is to be able to influence the practices and techniques of other team members so as to make the team productive and derive high productivity out of the group, something that I am used to and all of us strive for. A reaction to that realization is to start sharing best practices and having lunch and learns where a lot of knowledge exchange happens. I learn a bit about the client and their systems and they learn a little bit from me. Good results start to follow, more often than not. And then we (both client and I) get hooked on to this style of work where apart from delivery we start carving time out for knowledge exchange.

Suddenly, the questions start to pop up.

Answering any of these questions will no doubt sway any consultant in the direction that avoids enablement, when (s)he is on a delivery project. These used to be a hard ones to answer until I started asking myself a different question.

The answer to this question is very straightforward for a consultant. I am at any client's to generate some value. And value is generated not by one of two members of a team but by the whole team. If I think that some members of the team are not generating value for whatever reason, I get into the enablement mode to ensure that they are getting all the help and support in order to become valuable members of that team. That in the end will help me generate the value that is being sought.