Archive for the ‘Consulting’ Category
On the relationship between projects and organisations
Introduction
Most of the research and practice literature on project management tends to view projects as being isolated from their environment. It is obvious to anyone who has worked on a project that this isn’t so. In view of this, it is useful to look at the relationship between projects and the organisations that host them. This post looks at this issue, drawing on a paper by Gernot Grabher entitled, Cool Projects, Boring Institutions: Temporary Collaboration in Social Context.
The emergence of projects
Grabher begins his discussion with a sketch of the how projects emerged as a distinct work form. Projects – i.e. time bound, goal focused activities – have always been around. The modern notion of a project, however, arose from a development philosophy that came out of the US Department of Defense in the 1950s. He states,
…Instead of fragmenting and pre-specifying the development of military technologies along functional disciplines, these technologies were described in relation to their objectives, i.e. the military parameters of these weapons. The pacing of these concentrated efforts was crucial: parameters had to be met, goals had to be accomplished according to a grand scheme (program?) to win the armament race. Development processes that earlier were seen as separate activities were now conceptualized as an integrated entity called a program, system or project. The overwhelming scale of these projects in terms of financial and scientific resources as well as their ambitious timing created formidable problems of coordination and control. Experiments with various forms of organizational control ultimately lead to the professionalization of the role of the project manager…
From thereon the concepts of projects and project management were taken up (with much enthusiasm and optimism) by business and industry. The formalization of various project management methodologies, standards , qualifications and trade journals can be seen a culmination of this process.
Given the military-industrial origins of the profession, it is easy to see why a “command and control” philosophy dominates much of project management thought and practice. Many of the early projects that are paraded as textbook examples of successful projects operated outside normal organizational oversight. They were, to a large extent, deliberately shielded from external influences. I believe this is why isolation from the environment is seen as a Good Thing by project managers – problems of coordination and control become so much simpler when one does not have to manage relationships and politics that are (perceived as being) external to a project. This practice may be necessary and workable for classified projects that run on billion dollar budgets, but it doesn’t work so well in environments that most project managers work in. Projects don’t take place in a vacuum; they are born, live and die in real-world organizations. To forget that is to see the “tree of the project” and miss the “forest of the organization.” This is particularly so because, unlike those near-mythical mega-projects of the 1950s, the efforts that you and I work on are deeply entwined with their hosting organizations.
Organisation-related characteristics of projects
Grabher then notes some characteristics of projects. I summarize these in the next few paragraphs.
First, it is interesting that the original meaning of the word “project” referred to a “proposal” or “idea”, rather than a “directed, time-bound effort.” Grabher points out that this shift in meaning was accompanied by a shift in focus: from project as idea (or goal) to project as process (or means to achieving a goal). Projects are thus seen as vehicles for achieving organisational goals.
Second, Grabher notes that projects are often hard to decompose into constituent tasks, and that such a (commonly agreed) decomposition is only possible when stakeholders interrelate with each other continually. This underscores the importance of communication in projects.
Third, Grabher highlights the importance of the project manager (he uses the term contractor) as the “lynchpin on whom trust is focused.” The role of the manager is particularly important in projects on which team members do not have the time to get to know each other well.
Fourth, the project manager / contractor is also the wielder of organizational authority as far as the project is concerned. He or she is, in this sense, a representative of the organization – a person whose presence underlines the fact that the project exists to achieve specified organizational goals.
Finally, deadlines are a defining aspect of projects. They serve several functions. For example, they ensure that a sense of urgency for action and progress remains through the duration of the project. They also might serve to legitimize execution of project work without external interference (this argument was frequently used in the military-industrial projects of the 1950s). But above all, the final deadline, which culminates in the termination of the project, also serves as a connector to the rest of the organization. It is a time in which handoffs, documentation, team disbanding etc. occurs, thus enabling the results and experiences from the project disperse into the wider organization.
Projects in organisations
The characteristics noted above highlight the dual nature of projects: on the one hand, as noted earlier, projects are seen as semi-autonomous temporary organisations, but on the other they are also firmly embedded within the hosting organisation. An effect of the latter is particularly evident in consulting and software services firms (or even corporate IT shops), which tend to do similar projects over and over. As Grabher notes,
[projects] apparently operate in a milieu of recurrent collaboration that, after several project cycles, fills a pool of resources and gels into latent networks. Project organising is mostly directed towards the actual realization of a potential that is generated and reproduced by the practice of drawing on core members of (successful) prior projects to serve on derivative successor projects. Such chains of repeated co-operation are held together (or cut off ) by the reputation members gain (or lose) in previous collaborations…
Another aspect of embedded-ness is the co-location of team members within a larger organizational milieu. The standard benefits of co-location are well known. These are:
- Savings of transactional costs such as those incurred in communication, supervision of staff at remote locations etc. See my post on a transaction cost view of outsourcing for more on this.
- Co-location improves the efficacy of communication by encouraging face-to-face interactions.
- It enables “near real-time” monitoring of the health of the project and its environment.
There’s more though. Grabher notes that in addition to the above “intentional” or “strategic” benefits, co-location also ensures that team members are exposed to the same organizational noise – which consists of a “concoction of rumours, impressions, recommendations, trade folklore and strategic misinformation (falsehoods!).” Co-location enables project teams to make collective sense of organisational noise – this shared understanding of the environment can contribute significantly to the creation of a team spirit.
A related notionis that of enculturation: that is, the process of becoming an accepted member of the group, or an insider. This has less to do with expertise and knowledge than learning the unspoken rules and norms of a community. Although becoming a member of a community has much to do with social interactions within the workplace, there is more: a lot of essential know-how and know-what is transferred through informal interactions between senior members of the team (who are often senior members of the organisation) and others.
Projects generally need to draw upon a range of organizational resources: people and physical infrastructure being the most obvious ones. Grabher notes that the increasing projectisation of organizations can be attributed to a perception that project-based management is an efficient way to allocate productive resources in a flexible manner (…whether this perception is correct, is another matter altogether). However, there are other less obvious influences that organisations exert too. For example, Grabher points out that organizational norms and rules provide the basis for the emergence of swift trust, which is trust based on roles and professional ability rather than individuals and personalities. Further, at a higher level, organizational culture plays a role in determining how a project is governed, managed and run. These explicit and implicit norms have a stabilising influence on projects.
In addition to the stabilizing influence of the hosting organisation, projects also offer opportunities to build and enhance links between organisations – for instance, strategic partnerships. This is, in effect, institution building aimed at leveraging the strengths of the participating organisations for a greater joint benefit. In such situations the participating organisations take on the role of “lynchpins” on whom trust is focused.
Grabher makes the point that firms (and institutions comprised of firms) not only provide resources that make projects possible, but also host a range of processes that are needed to organize and run projects. For one, projects are usually preceded by several organisational processes involving deliberation, selection and preparation. These activities have to occur for a project to happen, but they normally fall outside the purview of the project.
A somewhat paradoxical aspect of projects is although they offer the opportunity for enhancing organizational knowledge, this rarely happens in practice. The high pressure environment in projects leaves little time for formal training or informal learning, or even to capture knowledge in documents. To a large extent the hosting organisations are to blame: Grabher suggests that this paradox is a consequence of the lack of organizational redundancy in project-based organizing.
I’ll end this section with the observation that the social dimension of projects is often neglected. Projects are often hindered by organizational politics and inertia. Further, a large number of projects fail because of varying perceptions of project goals and the rationale behind them. Although it seems obvious that a project should not proceed unless all stakeholders have a shared understanding of objectives and the reasons for them, it is surprising how many projects drift along without it. Many project planners neglect this issue, and it invariably comes back to bite them.
Conclusions
In the conclusion to the paper, Grabher states:
The formation and operation of projects essentially relies on a societal infrastructure which is built on and around networks, localities, institutions and firms. Relations between temporary and permanent systems are not a matter of straightforward substitution but have to be regarded in terms of interdependence. ‘Cool’ projects, indeed, rely on ‘boring’ institutions…
This is unarguable, but it should also be kept in mind that projects are often subject to negative organisational influences which can slow them down, or even kill them altogether (which is perhaps why those early defence projects were set up as near-autonomous initiatives). So although it is true that projects are made possible and sustained by the organisations they’re embedded in, they are sometimes hindered by those very organisations .
To sum up in a line: Projects depend on organisations not only for material and human resources, but also draw sustenance from (and are affected by) the social environment and culture that exists within those organisations.
Some pitfalls of contracts
Introduction
Individuals or organizations who have agreed to work together often formalize their agreement through contracts. One of the main functions of such contracts is to reinforce trust between the two parties – i.e. to assure each other that they will do as they say. Another function is to reduce risk. In an article published in the May 2009 issue of the Harvard Business Review, Deepak Malhotra argues that in some situations contracts end up destroying trust and/or increasing risk. In this post I present the pitfalls he discusses, along with comments and observations drawn from other sources.
Three pitfalls of contracts
The first point Malhotra makes is that overly detailed contracts can reduce trust by preventing spontaneous displays of good intentions. Here’s how the reasoning goes: extremely detailed contracts are a sign that the two parties do not trust each other fully (hence the need to write down every possibility that comes to mind). In such situations, the relationship between the two parties tends to be managed by contract, which acts as a disincentive to do things that aren’t written down.
More generally, it is obvious that trust cannot be created by writing it into a contract. At best, contracts might help in reinforcing trust that is built up by other means. How does one build up trust? Well, there are a couple of ways that come to mind;
- Through consistent actions that demonstrate good intentions.
- Through building relationships between individuals in the two parties.
Neither of these behaviours can be mandated by contract, but a detailed, hard-to-interpret contract can very easily discourage them.
The second point he makes is that rigid contracts can increase risk by discouraging adjustments down the line. Those who draw up contracts cannot be aware of all the possibilities that might unfold as a project progresses (a consequence of bounded rationality). For this reason, contracts should be flexible enough to permit changes as new information comes to light. Ironically, many organizations view rigid contracts as a means of reducing risk. Most often this is because the parties involved tend to underestimate the uncertainties in their environment. The point here is to put off contractual decisions regarding uncertain elements of the agreement, but to put in place arrangements to deal with some of the foreseeable outcomes. As Malhotra puts it, “Wisely structured contracts postpone agreement on terms that would be more effectively handled after more information is available, and they include contingencies commensurate with the current level of uncertainty.”
As I’ve written in my post on outsourcing and transaction costs, parties involved in contractual agreements need to take a farsighted view. Such a view would acknowledge the tension between the need for uncertainty in the face of an uncertain world.
The third point Malhotra makes is that incentives in contracts can signal mistrust. This often happens in contracts between high performing individuals and organizations, where a large portion of the individual’s compensation is tied to performance. Such an arrangement can actually end up demotivating the individual. How so? Well, employee performance in knowledge-related work such as programming, is directly related to intrinsic motivation – i.e. the internal drive (or inclination) to do the assigned work. Further, as I have discussed in this post, intrinsic motivation has more to do with interesting work than with tangible rewards or incentives. More to the point, intrinsic motivation cannot be fostered or enhanced by contract. So, in cases where one is dealing with high performers, a better strategy might be to empower them to make decisions on how their work gets done or , where possible, matching assignments to professional interests and aspirations.
Summarizing
Contracts are part and parcel of cross-organisational agreements. They are designed, among other things, to reinforce trust and reduce risk. If one isn’t careful, however, they may do just the opposite: contracts that are overly detailed or overemphasize monetary incentives can end up reducing trust and increasing risk.
The Approach: a dialogue mapping story
Jack could see that the discussion was going nowhere: the group been talking about the pros and cons of competing approaches for over half an hour, but they kept going around in circles. As he mulled over this, Jack got an idea – he’d been playing around with a visual notation called IBIS (Issue-Based Information System) for a while, and was looking for an opportunity to use it to map out a discussion in real time (Editor’s note: readers unfamiliar with IBIS may want to have a look at this post and this one before proceeding). “Why not give it a try,” he thought, “I can’t do any worse than this lot.” Decision made, he waited for a break in the conversation and dived in when he got one…
“I have a suggestion,” he said. “There’s this conversation mapping tool that I’ve been exploring for a while. I believe it might help us reach a common understanding of the approaches we’ve been discussing. It may even help facilitate a decision. Do you mind if I try it?”
“Pfft – I’m all for it if it helps us get to a decision.” said Max. He’d clearly had enough too.
Jack looked around the table. Mary looked puzzled, but nodded her assent. Rick seemed unenthusiastic, but didn’t voice any objections. Andrew – the boss – had a here-he-goes-again look on his face (Jack had a track record of “ideas”) but, to Jack’s surprise, said, “OK. Why not? Go for it.”
“Give me a minute to get set up,” said Jack. He hooked his computer to the data projector. Within a couple of minutes, he had a blank IBIS map displayed on-screen. This done, he glanced up at the others: they were looking at screen with expressions ranging from curiosity (Mary) to skepticism (Max).
“Just a few words about what I’m going to do, he said. “I’ll be using a notation called IBIS – or issue based information system – to capture our discussion. IBIS has three elements: issues, ideas and arguments. I’ll explain these as we go along. OK – Let’s get started with figuring out what we want out of the discussion. What’s our aim?” he asked.
His starting spiel done, Jack glanced at his colleagues: Max seemed a tad more skeptical than before; Rick ever more bored; Andrew and Mary stared at the screen. No one said anything.
Just as he was about to prompt them by asking another question, Mary said, “I’d say it’s to explore options for implementing the new system and find the most suitable one. Phrased as a question: How do we implement system X?”
Jack glanced at the others. They all seemed to agree – or at least, didn’t disagree – with Mary, “Excellent,” he said, “I think that’s a very good summary of what we’re trying to do.” He drew a question node on the map and continued: “Most discussions of this kind are aimed at resolving issues or questions. Our root question is: What are our options for implementing system X, or as Mary put it, How do we implement System X.”
Figure 1
“So, what’s next,” asked Max. He still looked skeptical, but Jack could see that he was intrigued. Not bad, he thought to himself….
“Well, the next step is to explore ideas that address or resolve the issue. So, ideas should be responses to the question: how should we implement system X? Any suggestions?”
“We’d have to engage consultants,” said Max. “We don’t have in-house skills to implement it ourselves.”
Jack created an idea node on the map and began typing. “OK – so we hire consultants,” he said. He looked up at the others and continued, “In IBIS, ideas are depicted by light bulbs. Since ideas respond to questions, I draw an arrow from the idea to the root question, like so:
Figure 2
“I think doing it ourselves is an option,” said Mary, “We’d need training and it might take us longer because we’d be learning on the job, but it is a viable option. ”
“Good,” said Jack, “You’ve given us another option and some ways in which we might go about implementing the option. Ideally, each node should represent a single – or atomic – point. So I’ll capture what you’ve said like so.” He typed as fast he could, drawing nodes and filling in detail.
As he wrote he said, “Mary said we could do it ourselves – that’s clearly a new idea – an implementation option. She also partly described how we might go about it: through training to learn the technology and by learning on the job. I’ve added in “How” as a question and the two points that describe how we’d do it as ideas responding to the question.” He paused and looked around to check that every one was with him, then continued. “But there’s more: she also mentioned a shortcoming of doing it ourselves – it will take longer. I capture this as an argument against the idea; a con, depicted as red minus in the map.”
He paused briefly to look at his handiwork on-screen, then asked, “Any questions?”
Figure 3
Rick asked, “Are there any rules governing how nodes are connected?”
“Good question! In a nutshell: ideas respond to questions and arguments respond to ideas. Issues, on the other hand, can be generated from any type of node. I can give you some links to references on the Web if you’re interested.”
“That might be useful for everyone,” said Andrew. “Send it out to all of us.”
“Sure. Let’s move on. So, does anyone have any other options?”
“Umm..not sure how it would work, but what about co-development?” Suggested Rick.
“Do you mean collaborative development with external resources?” asked Jack as he began typing.
“Yes,” confirmed Rick.
Figure 4
“What about costs? We have a limited budget for this,” said Mary.
“Good point,” said Jack as he started typing. “This is a constraint that must be satisfied by all potential approaches.” He stopped typing and looked up at the others, “This is important: criteria apply to all potential approaches, so the criterial question should hang off the root node,” he said. “Does this make sense to everyone?”
Figure 5
“I’m not sure I understand,” said Andrew. “Why are the criteria separate from the approaches?”
“They aren’t separate. They’re a level higher than any specific approach because they apply to all solutions. Put another way, they relate to the root issue – How do we implement system X – rather than a specific solution.”
“Ah, that makes sense,” said Andrew. “This notation seems pretty powerful.”
“It is, and I’ll be happy to show you some more features later, but let’s continue the discussion for now. Are there any other criteria?”
“Well, we must have all the priority 1 features described in the scoping document implemented by the end of the year,” said Andrew. One can always count on the manager to emphasise constraints.
“OK, that’s two criteria actually: must implement priority 1 features and must implement by year end,” said Jack, as he added in the new nodes. “No surprises here,” he continued, “we have the three classic project constraints – budget, scope and time.”
Figure 6
The others were now engaged with the map, looking at it, making notes etc. Jack wanted to avoid driving the discussion, so instead of suggesting how to move things forward, he asked, “What should we consider next?”
“I can’t think of any other approaches,” said Mary. Does anyone have suggestions, or should we look at the pros and cons of the listed approaches?”
“I’ve said it before; I’ll say it again: I think doing it ourselves is a dum..,.sorry, not a good idea. It is fraught with too much risk…” started Max.
“No it isn’t,” countered Mary, “on the contrary, hiring externals is more risky because costs can blowout by much more than if we did it ourselves.”
“Good points,” said Jack, as he noted Mary’s point. “Max, do you have any specific risks in mind?”
Figure 7
“Time – it can take much longer,” said Max.
“We’ve already captured that as a con of the do-it-ourselves approach,” said Jack.
“Hmm…that’s true, but I would reword it to state that we have a hard deadline. Perhaps we could say – may not finish in allotted time – or something similar.”
“That’s a very good point,” said Jack, as he changed the node to read: higher risk of not meeting deadline. The map was coming along nicely now, and had the full attention of folks in the room.
Figure 8
“Alright,” he continued, “so are there any other cons? If not, what about pros – arguments in support of approaches?”
“That’s easy, “ said Mary, “doing it ourselves will improve our knowledge of the technology; we’ll be able to support and maintain the system ourselves.”
“Doing it through consultants will enable us to complete the project quicker,” countered Max.
Jack added in the pros and paused, giving the group some time to reflect on the map.
Figure 9
Rick and Mary, who were sitting next to each other, had a whispered side-conversation going; Andrew and Max were writing something down. Jack waited.
“Mary and I have an idea,” said Rick. “We could take an approach that combines the best of both worlds – external consultants and internal resources. Actually, we’ve already got it down as a separate approach – co-development, but we haven’t discussed it yet..” He had the group’s attention now. “Co-development allows us to use consultants’ expertise where we really need it and develop our own skills too. Yes, we’d need to put some thought into how it would work, but I think we could do it.”
“I can’t see how co-development will reduce the time risk – it will take longer than doing it through consultants.” said Max.
“True,” said Mary, “but it is better than doing it ourselves and, more important, it enables us to develop in-house skills that are needed to support and maintain the application. In the long run, this can add up to a huge saving. Just last week I read that maintenance can be anywhere between 60 to 80 percent of total system costs.”
“So you’re saying that it reduces implementation time and results in a smaller exposure to cost blowout?” asked Jack.
“Yes,” said Mary
Jack added in the pros and waited.
Figure 10
“I still don’t see how it reduces time,” said Max.
“It does, when compared to the option of doing it ourselves,” retorted Mary.
“Wait a second guys,” said Jack. “What if I reword the pros to read – Reduced implementation time compared to in-house option and Reduced cost compared to external option.”
He looked at Mary and Max. – both seemed to OK with this, so he typed in the changes.
Figure 11
Jack asked, “So, are there any other issues, ideas or arguments that anyone would like to add?”
“From what’s on the map, it seems that co-development is the best option,” said Andrew. He looked around to see what the others thought: Rick and Mary were nodding; Max still looked doubtful.
Max asked, “how are we going to figure out who does what? It isn’t easy to partition work cleanly when teams have different levels of expertise.”
Jack typed this in as a con.
Figure 12
“Good point,” said Andrew. “There may be ways to address this concern. Do you think it would help if we brought some consultants in on a day-long engagement to workshop a co-development approach with the team? ”
Max nodded, “Yeah, that might work,” he said. “It’s worth a try anyway. I have my reservations, but co-development seems the best of the three approaches.”
“Great,“ said Andrew, “I’ll get some consultants in next week to help us workshop an approach.”
Jack typed in this exchange, as the others started to gather their things. “Anything else to add?” he asked.
Everyone looked up at the map. “No, that’s it, I think,” said Mary.
“Looks good,” said Mike . “Be sure to send us a copy of the map.”
Figure 13
“Sure, I’ll print copies out right away,” said Jack. “Since we’ve developed it together, there shouldn’t be any points of disagreement.”
“That’s true,” said Andrew, “another good reason to use this tool.” Gathering his papers, he asked, “Is there anything else? He looked around the table. “ Alright then, I’ll see you guys later, I’m off to get some lunch before my next meeting.”
Jack looked around the group. Helped along by IBIS and his facilitation, they’d overcome their differences and reached a collective decision. He had thought it wouldn’t work, but it had.
“ Jack, thanks for your help with the discussion. IBIS seems to be a great way to capture discussions. Don’t forget to send us those references,” said Mary, gathering her notes.
“I’ll do that right away,” said Jack, “and I’ll also send you some information about Compendium – the open-source software tool I used to create the map.”
“Great,” said Mary. “I’ve got to run. See you later.”
“See you later,” replied Jack.
————
Further Reading:
1. Jeff Conklin’s book is a must-read for any one interested in dialogue mapping. I’ve reviewed it here.
2. For more on Compendium, see the Compendium Institute site.
3. See Paul Culmsee’s series of articles, The One Best Practice to Rule Them All, for an excellent and very entertaining introduction to issue mapping.
4. See this post and this one for examples of how IBIS can be used to visualise written arguments.
5. See this article for a dialogue mapping story by Jeff Conklin.
Eight to Late 