Author Archive
Blended project teams and client-vendor trust
Introduction
Many projects are run as collaborative efforts between customer and provider (or vendor) organisations. It is well accepted that such co-creation involving both parties is an effective way for service organisations to enhance acceptance of the services they provide. It is a common practice for IT service providers to locate their consultants at client sites for the entire duration of the project. In this period consultants and client-side employees work together in blended teams. It is clear that the (provider-side) project manager plays a critical role in such projects because he or she is at the interface, or boundary, between two organisations. A recent paper, by Sheila Simsarian Webber, entitled, Blending Service Provider – Client Project Teams to Achieve Client Trust: Implications for Project Team Trust, Cohesion and Performance, published in the June 2008 issue of the Project Management Journal, investigates the effectiveness of such teaming from the perspective of trust between the project manager (as a proxy for the supplier) and the client. I review the paper below.
Background and Objectives
Interestingly, most of the research on co-creation or co-production has focused on bringing the customer into the service organisation rather than the other way round. That’s strange (to me at any rate) because the latter situation, in which provider-side employees are placed in client organisations, is way more common in IT projects. Placing employees within client organisations gives the service provider ongoing opportunities to understand a client’s business better, and thus foster long-term relationships with them. However, this works only if there is trust between the two parties. The project manager (as a proxy for the provider) plays a key role in developing this relationship. In the paper, the author provides empirical evidence that the use of blended teams creates a more trusting relationship between the client and project manager. Further, the research also shows that gaining the client’s trust has the side effect of improving (intra-team) team trust, cohesion and performance.
Before proceeding any further, it is worth defining what is meant by trust. Following Mayer, Davis and Schoorman, the author defines interpersonal trust as the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the ability to monitor or control that party. Researchers have identified two dimensions of interpersonal trust: affective and cognitive. The first is based on emotional bonds and the second on notions of reliability, dependability and competence. Trust among business partners involves both types of trust. In the case at hand, it is important that the client not only believes in the project managers competence, but also that he or she cares about the client’s business (i.e. has an emotional bond with the client). Blended teams provide more opportunity for interaction between the client and provider and hence the basis for the author’s first hypothesis:
Hypothesis 1. Blended project teams will have greater client trust (than non-blended teams).
Katz and Kahn proposed that an organization be considered as an open system that interacts with its environment. If this is so, it is important that boundary relationships – i.e. relationships at the interface between an organisation and its environment (which could be another organisation) – be managed effectively. The open system concept has been applied to teams as well. Further, earlier research has demonstrated that managing relationships outside team boundaries is important for knowledge transfer and team success. In the case of project teams, managing external relationships is generally the responsibility of the project manager. In the present case the main external relationship (from the perspective of the provider) is the one between the project manager and the client. Based on research by Amy Edmondson , which suggests that boundary spanning relationships affect team trust, cohesion and effectiveness, the author proposes the following as her second hypothesis:
Hypothesis 2. Client trust in his or her direct project manager will be positively (or directly) related to team trust, cohesion or performance. That is, as client trust (in the PM) increases, so does team trust, cohesion and performance.
Finally, as a follow-on to the second hypothesis, the author suggests a that there is a stronger positive correlation between client trust and team trust, cohesion and performance if the team is blended. This leads to her third hypothesis which is:
Hypothesis 3. The relationship between client trust and team trust, cohesion and performance is stronger when teams are blended (as compared to non-blended teams).
Results and Discussion
The author surveyed 31 IT project teams (20 blended and 11 non-blended). Data was collected from project managers, their primary client contacts and project teams. Project managers reported on background information, nature and duration of project and whether or not the team was blended; clients were surveyed for an assessment of trust (cognitive and affective); and teams were asked about team trust, cohesion and performance. I won’t discuss specific metrics used by the author – please see the original paper for more on these.
The research results vis-a-vis the above hypotheses can be summarised as follows:
1. Clients tend to have greater (cognitive and affective) trust in project managers who are a part of a blended team.
2. The client’s cognitive trust in the project manager has significant positive implications for the team’s (internal) cognitive trust and has marginally significant positive implications for the team’s affective trust. Interestingly, the client’s affective trust in the project manager has significant positive implications for the team’s cognitive and affective trust. This seems to suggest that emotional trust between the client and the project manager carries more weight than perceptions relating to competence and reliability.
3. The results around the third hypothesis are even more interesting. The data suggests that there is a relationship between client trust / team trust, cohesion and performance and whether or not a team is blended. However, this relationship isn’t as hypothesised: it turns out that when the client does not have much cognitive trust in the project manager, a blended team has significantly less cognitive team trust than a non-blended team. Similar results hold for team performance: when the client does not have much affective trust in the project manager, a blended team will show significantly lower levels of performance than non-blended teams. Why should this be so? I suggest it is because non-blended teams, due to the lack of interaction between client and provider side team members, are shielded from the politics of the client-project manager relationship. In blended teams, on the other hand, co-location of team members and managers, and the resulting opportunities for informal communication, means that a sour relationship between the client and project manager can quickly translate to breakdown of team relationships.
The results lend empirical backing to the importance of client relationship management for project managers. Specifically, for blended teams, the research shows that trust between the project manager and the client is directly related to team trust and performance. Furthermore, blended teams tend to be more negatively affected than non-blended teams in cases where the relationship between the project manager and client is not good. This, again, highlights the critical role of client-project manager relationships for blended teams.
Conclusion
Although many of the results discussed in the previous may seem evident to professional project managers who work with blended teams, the research is interesting because it lends empirical support to such “obvious” notions. Having said that, the conclusions drawn by the author should not be overstated, particularly because of the small sample size and limitations imposed by the survey methodology (for example, the data did not capture the nature / scope of the project and other factors which may have an effect on the conclusions). Further, the research does not consider factors such as organisational culture and constraints, which may have a significant effect on the functioning of blended teams and the development of trust between employees from different organisations. In view of these limitations the results can be regarded as suggestive, but by no means definitive. Nevertheless, the paper is of interest to project managers and senior executives who work in service and consulting organisations.
References:
Webber, S.S., Blending Service Provider – Client Project Teams to Achieve Client Trust: Implications for Project Team Trust, Cohesion and Performance, Project Management Journal, 39 (2), 72-81. (2008).
On the role of processes in project management
The word process has several different connotations – an online dictionary lists more than twenty meanings of the word. Amongst these, the following is the sense in which the word is used when we speak of a project management process:
Process (noun): a systematic series of actions directed to some end.
The key word here is systematic – which (again from the same online dictionary) means according to a method. The word process thus has a very precise meaning – a series of methodical actions which are directed to some (definite) end. The word, as used in normal parlance, evokes a world in which a sequence of well-defined actions lead to certain desired results. This may be an excellent approximation to reality on the manufacturing shop-floor, but is little more than an illusion in the messy world of projects. Having made a potentially controversial statement, I’d better clarify what I mean. I do so below.
The objective in manufacturing is to mass-produce items in a controlled and repeatable manner. In constrast, in projects the aim is to create unique products (or services). In the former case, it makes perfect sense to formalise actions required to create the product into well-defined and detailed processes. Such processes tend to be very prescriptive: e.g. immerse the widget in the solution for 3 minutes, then air dry at 200 C for 2 minutes. Such prescriptiveness is required for ensuring repeatability (of processes) and reproducibility (of results). It also confers an advantage in quality improvement efforts: such processes can be tweaked in a controlled fashion whilst maintaining a sensible baseline for comparison. In the case of projects, though, the notion of a process isn’t quite the same. Given that every project aims to create a one-off, unique product, how does the idea of “systematic actions directed to an end” apply? I take a brief look at some half-answers below.
Wikipedia defines a project management process as a management process of planning and controlling the performance or execution of a project. The definition isn’t much help, so let us start with a commonly accepted example of a project management process instead: schedule development or scheduling (as per PMI or PRINCE2). Now, although schedule development has a bunch of inputs, tools and techniques, and outputs, these leave much open to interpretation. That is, they aren’t as prescriptive as processes in manufacturing. They don’t even come close to being “a systematic series of actions directed to some end.” Yet, they are often considered by project managers as being so. That, in my opinion, is the problem. Let me hasten to add that frameworks and methodologies aren’t at fault here – most do emphasise that they provide guidelines not recipes. As I have mentioned in an earlier post, this is largely a problem of our own making. To paraphrase the Bard: The fault, dear Brutus, is not in our processes, But in ourselves, that we are obsessed with them.
The history of project management yields a clue as to why the notion of process – despite its shortcomings – is so ingrained in project management theory and practice. As Patrick Weaver points out, the roots of modern project management lie in concepts of scientific management, or Taylorism as it is called after its founder, Fredrick Taylor. To quote Weaver, “…Project management has evolved in its specialist area along very similar lines to general management theory. In early days, project management closely mirrored the classical school of management with a focus on scientific processes…” Why this early focus on scientific processes? Well, Weaver mentions that, “…it is entirely reasonable to argue that the evolution of modern project management is a direct consequence of the need for professional schedulers for a forum to discuss and develop their new discipline….” Since scheduling is arguably the most mathematical (or statistical) process in the project management process pantheon, the focus on scientific management is really no surprise.
In recent years things have moved on. In their paper on future challenges and opportunities in project management (which I have reviewed in an earlier post), Shenhar and Dvir point out that there are three central paradigms of project management: operational/process, team/leadership and business/strategic. The process-based approach, rooted in scientific management, corresponds to the first. The team/leadership view puts people at the centre of focus, and as we all (should!) know, people aren’t as simple as processes. The last perspective is the big-picture: project management as a strategic tool. As is the case with people, this too cannot be reduced to formulaic processes. The fact that the latter two perspectives have been getting more attention in recent years indicates that things are changing. So, perhaps it is only a matter of time before the practice of project management is cured of its process obsession.
Related posts:
Blinded by the light: when project management methodology matters more than project success.
Increasing your team’s bus factor
Wikipedia defines the bus factor as the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed. Although most discussions about the bus factor revolve around software projects, the considerations apply to any situation where important, specialised knowledge is held by a small number of people. For example, an IT department where there is little or no cross-training or cross-over in roles would have a low bus factor.
Increasing the bus factor amounts to spreading the knowledge around so that there is a degree of redundancy in skills and knowledge within a team. This ensures that work will go on even if a key person has an unfortunate encounter with a public transport vehicle. It is clear that every manager should aim to increase the bus factor for all processes that come under his or her purview. Below I outline a few suggestions on how one might do so.
- Keep things simple: Keep processes as simple as possible (but no simpler!). This ensures that the processes are easy to maintain and hence easy to teach to others. Simplicity usually boils down to two things: a) using the right tool for the right job, and b)using the most straightforward way to achieve what’s needed. I have seen several processes that are needlessly complicated by inappropriate technologies or use of technologies. To elaborate on the latter, processes are overengineered often for no other reason than to demonstrate the cleverness of the process creator. Avoid creating such Rube Goldberg processes at all costs!
An important, simplicity related factor (from the bus point of view) is to use technologies that are familiar to more than one person on the team. This builds in a high bus factor from the start. - Document, document, document: This is a no-brainer, but people still think they can get away with “doing it first and documenting it later.” Documentation done after the fact is often less than useful because the author forgets to include some (many?) small detail(s) which, of course, turn out to be critical ones in times of trouble. What should a process document contain? Enough to help someone figure out what, how, where, when – what it does; how it’s run; where it sits (servers etc.); and when and how often it’s run. The documentation should also include some basic troubleshooting information and references to relevant sections of manuals.
Another important point is to keep the documentation in synch with the process – i.e. to update all relevant documents whenever the process is modified. This is essential because process documentation is your only guide when the owner of a process with bus factor 1 goes under the bus instead of getting on it.
A small word about style is perhaps in order – process documentation should adhere to the 3Cs of clarity, conciseness and comprehensibility. Yes, it is possible to write in a way that achieves all three, although this isn’t evident in my writing. - Encourage people to pick up secondary skills: The first two points dealt with process and documentation. However, in the end, it is people who make things happen. Despite well-engineered and documented processes, one can still have a low bus factor if the team doesn’t have skill redundancy. Who’ll look after the databases the when the DBA goes under (or is run over by) a bus? This question wouldn’t have to be asked if someone had been cross-trained in basic DBA tasks. As far as possible, every one on the team should have at least one secondary skill that will enable them to cover for someone else.
All this stuff is obvious. Yet I’ve seen more than a few outfits with very low bus factors (sometimes as low as zero. Yes, really!), so perhaps it isn’t taken as seriously as it should be. I therefore close with this exercise: take stock of the activities and processes that your department or team supports. Do you see any danger zones with low bus factors? If the answer’s affirmative, get moving before a bus comes around.
Eight to Late 