Project scope management dynamics--exploring the advisor dimensions of the project manager



The Guide to the Project Management Body of Knowledge (PMBOK® Guide) specific focuses on scoping processes underlines that the concept and development phases are crucial to the success of the project. The aim of the paper is to discuss the advisory role that the project manager could play in defining and managing project scope.

The article explores the advisor role of project manager through several strictly related perspectives. The translation of vague customer wishes into project scope. At the beginning of a project, hardly ever are objectives and requirements clearly defined. The aim of the project manager is to “dig” out customer wants and needs and translate them into product and project scope. The identification of spoken and unspoken customer's needs. A fundamental challenge for the project manager is to detect and describe not only spoken desires of the customer but also latent needs. This implies listening and analyzing skills, the ability to see the customer's perspectives and to go beyond explicit statements. Project success in terms of the value customers receive from the product of the project. Using this approach, measurement of the project success is not only related to conformance to requirements, but, also, and probably above all, to the value in use. The context analysis. Since every project is run in a broader environment, it is extremely important for the project manager to be fully aware of the organisational influence. The advisor approach emphasizes the need to understand this broader context: the power and politics dynamics, influence relationships, organisational structures, and relation with the ongoing processes. The construction of the stakeholders system. Projects have multiple customers; each user classes and customer group has its own needs that are specific and unique to them. So the project manager has to pay particular attention in performing social network analysis and understanding the influence stakeholders exert over the project. The negotiation and agreement of mutual role and responsibilities between customers and project manager. The project manager has to examine and define the explicit and implicit psychological contract between customers and himself. He has to make clear what each party expects to give and to receive, what psychological conditions must be met for the exchange to occur successfully and how these conditions can be achieved.


The aim of this article is to discuss the role of the project manager from a perspective that is, in certain respects, new and hitherto little explored: the advisory perspective.

The intention, in particular, is to analyse some of the dynamics specific to management of project goals, using a different interpretative framework. Traditionally, all activities related to defining and framing a project and its objectives are comprised in the scoping process: from analysing the client's needs to specifying the product or service to be created, from constructing the meaning of the project to analysing the context in which the initiative is to be undertaken, from defining all the necessary activities (developing the Work Breakdown Structure) to supervising the project to ensure that it proceeds in accordance with the objectives defined in the initial phases. The PMBOK® Guide (PMI, 2000) places particular emphasis on scoping topics, stressing that the correct set-up of a project is crucial for its success.

The article examines scoping activities, highlighting the consultative role assumed by the project manager. In other words, it stresses that if scoping activities are viewed from this perspective, it is possible to focus not only on the tasks traditionally assigned to the project managerk, but also on a series of competencies crucial for the success of a project, and which specifically involve consulting and guidance capacities (particularly in relation to clients).

The consulting dimension of the project manager's activities cuts across application sectors and is present, in varying forms, in projects significantly different in type. In this regard, Lundin and Söderholm (1998, p16) propose an interesting classification of three kinds of macro project:

Production projects. Projects realised in industrial sectors where reliance on management by project methods is high, if not predominant, over other forms of organisation. Belonging to this category are projects pertaining to sectors like manufacturing, organisational advisory or information technology.

Innovative projects. Projects developed in industrial sectors where the use of the management by project approach is usually only partial, but nonetheless essential; only some areas or specific functions of companies employ this management method: for example, new product development management in technologically advanced businesses.

Renewal projects. Projects with unique characteristics, seen as exceptional for the organisation that primarily launch them: organisational development projects, for example, belong to this category.

Even on cursory examination, it is possible to identify advisory activities inherent to the project manager's role in each of the three above categories of projects. In the case of initiatives of the third type (renewal projects), for example, consultancy consists in activities geared mainly to the client, in an endeavour to progressively define the borders of the initiative, to define and share the collective meaning of the project and its objectives. As regards the second category (innovative projects), here advisory is primarily aimed at helping the client to ensure that the product being developed matches the needs that generated it. Finally, in the case of the first category (production projects), the project manager's consultative activity often translates into guidance of the client towards the most suitable solution, in an attempt to establish lasting partnership relations yielding value added to both the client and the supplier.

In short, regardless of the type of project, it is possible to interpret some of the project manager's activities along this consultative dimension: a dimension closely linked to the set-up of the project, the construction of the action context, the raison d'entre of the initiative and its objectives, and, therefore, to what is generally called project scoping activities.

In my opinion, it is possible to examine the project manager's role as an advisor along the following lines of inquiry: management of initially poorly defined objectives and of their progressive elaboration; joint formulation of a diagnosis with the client; translation of the client's generic expectations into a defined project scope; interpretation of the project's success in terms of the value perceived by the client; analysis and management of the context in which the project is embedded; construction of the map of the main stakeholders in the project; the construction of a relationship with the client; understanding the influence of certain intrapsychic processes. These aspects constitute what I have called the consultative dimension of the project manager and they will be examined individually in what follows.

It is advisable to explain, at this point, what I mean by ‘consultancy’. The term derives from the Latin verb “consulere”: to consult, to reach a decision. Here I use the concept of consultancy in the broad sense in order to emphasise that the role of a project manager is not merely to implement a mandate defined by others. The idea of consultancy underlines that the PM performs a role which is strictly managerial in many respects: s/he must not only express an opinion or technical assessment to achieve a tangible result as an expert, but also, in order to come up with a solution, interpret the action context, delve into needs and expectations, reconstruct the stakeholders’ system, guide the client and develop a relationship with the latter that enables the most appropriate decisions to be taken.

Therefore, as referred to here, is not so much so-called expert consultancy, where technical expertise on a particular subject is emphasised, but rather what Schein (1999, p22) has called ‘process consulting’: an approach centred on the consultant's ability to listen, understand and guide. Schein defines process consulting as the creation of a relationship with the client that enables the latter to understand and act on events taking place in his/her internal and external environment, the goal being to intervene in the situation according to the definition given by the client himself (Schein 1999, p.22). In short, this article eschews the concept of expert consulting, although this is often part of a project manager's activity, and focuses more closely on consulting as the capacity to build a relationship with a client and construct an action framework within which to operate.

The considerations developed in this article are based on analysis of theoretical studies by organisational scholars on one hand (primarily Schein, who has already been cited, but also authors such as Jackall (1988), Simon (1947), Lundin (1998), etc.), and on the findings of an empirical research on the other. This research was carried out at ISTUD between 2002 and 2003 and its aim was to describe how Italian companies deal with project management, seeking to understand the various approaches used and to identify the most common practices. Utilized for this purpose was a quantitative research methodology based on a semi-structured questionnaire composed of thirty-five multiple choice questions. The three macro-areas of project management examined were the relationship between projects and organisational system, the project manager's role, and the tools and the project management practices adopted by the companies studied.

The questionnaire was administered to a sample of 100 companies located in Italy and operating in different industrial sectors (manufacturing, information technology, retail, telecommunications, banking, automotive industry). In order to integrate and corroborate the data from the quantitative research, it was decided to flank it with qualitative research: consequently, six in-depth interviews were conducted with project managers working in different industries. The intention of this article is not to systematically set out the findings of the research, but rather to develop considerations based on some empirical facts. As said, this evidence will be analysed and integrated in light of theoretical contributions by organisation scholars.

Some In-Depth Guiding Principles of the PM's Consulting Dimension

The initial indefiniteness of the objectives and governance of the progressive elaboration process

One of the most frequent observations arising from theoretical analysis and field research in recent years concerns the initial definition of project objectives. Almost project managers complain about a lack of definition and organisation in the initial project phases. In the concept and initial development phase, project goals often strike the project manager as insufficiently clear, prompting him to describe them as ‘confused’, ‘undefined’, ‘unrealistic’.

These considerations involve the concept of progressive elaboration. The PMBOK® Guide (2000 edition) describes progressive elaboration as being able to integrate the unique and temporary features of a project. “Because the product of each project is unique, the characteristics that distinguish the product or service must be progressively elaborated. Progressively means proceeding in steps, continuing steadily increments, while elaborated means work out with care and detail, developed thoroughly. […] These distinguishing characteristics will be broadly defined early in the project, and will be made more explicit and detailed as the project team develops a better and more complete understanding of the product” (PMI,2000, pp. 5-6). In other words, a project is almost never defined in detailed and precise manner at the beginning; on the contrary, the characteristics of the product or service to be created, the boundaries of the project, and the specific activities that will have to be carried out are progressively defined as the organisation of the project itself proceeds.

In my opinion, this initial situation can be analysed and interpreted in light of two different perspectives put forward by two authors, Jackall (1988) and Schein (1999). The former, on analysing the kinds of action typical of management in large corporations, maintains that a fundamental characteristic of the authority system within businesses is “the tendency to disregard details and give credit” (Jackall 1989, p.31). Medium and high-level management (the organisational position of project client in the overwhelming majority of cases) is reluctant to give detailed instructions; an attitude officially motivated by the intent to valorise autonomy as much as possible, but which also conceals an endeavour to get rid of boring details. This frees those who occupy roles uppermost in the organisational hierarchy from the pressures that typically apply to middle management (which is often the organisational position of project managers).

Jackall's considerations explain why clients use typically ambiguous language replete with general and abstract formulas like “optimisation”, “greater flexibility”, “greater timeliness”, “improvement of overall efficiency” behind which the operative result is open to broad interpretation (1988, p33).

A different and, in a certain sense, complementary perspective has been proposed by Schein, one of whose best-known texts, Process Consultation Revisited, stresses that when a client asks for an intervention or launches a project, they often do not know exactly what they want: consequently, Schein writes, “we should not expect that they know” (Schein 1999, p.7). Put otherwise, if a client delegates responsibility for managing a project to someone else, it is because they do not have the time or the desire to supervise it personally or because an expert is needed who can handle the matter in greater detail. Schein continues: “Often clients do not possess the tools necessary for translating vague intuitions into clear operative concepts”(ibid). The reference is to both technical, expert knowledge and the ability to solve problems analytically. Every project originating in a context characterised in this manner must first involve the important task of helping the client understand the nature of the problem, and only then move to the project organisation phase.

Empirical analysis has provided numerous examples of these situations in various kinds of project. One of them is the classic situation of the Web Company whose clients want to “improve communication with customers”, but do not have the slightest idea of how they can translate this general objective into characteristics of the website to be designed. This dynamic requires the Web Company to gain deeper understanding of the client's world and to invest in pre-sales and pre-analysis phases, with the resulting problem of deciding where to offload the costs of these activities.

As said, progressive elaboration receives maximum effort in the initial phase of the project, which goes from impulse (which engendered the project itself) to the definition of objectives and activities. This gives rise, according to the situation, to a project plan, a commercial offer and the relevant technical documents. The project plan represents a ‘snapshot’ of the project which is agreed to by the various stakeholders as far as is possible, and on the basis of which the project will then be managed. But the progressive elaboration process does not conclude with this phase: in fact, the project plan and the commercial offer often comprise less well-defined, opaque, not completely shared areas. Consequently, the progressive elaboration process continues in parallel with the project realisation phase, determining possible variations, change requests and modifications with respect to what was previously agreed upon. In other words, the progressive elaboration phase continues throughout the entire life-cycle of the project, and a careful management of this process becomes essential for the coherence and success of the project itself.

Shared Diagnosis

The empirical analysis conducted showed that the unclear definition of objectives is one of the reasons why projects fail. This is confirmed by other researches, such as that carried out by the Standish Group (2000), for which reason it is necessary to stress once again the importance of project start-up activities and, in particular, what thus far has been called the progressive elaboration of initial objectives.

If objectives are initially general and poorly defined, and if the success of the project largely depends on their progressive elaboration, it follows that the initial needs analysis is of crucial importance. In this regard, various interviewees stressed the importance of an initial shared diagnosis between the mainly involved stakeholders. Therefore, in this phase, the principle aim of the project manager should be to assist the client performing this diagnosis and develop an effective action plan based on it.

When discussing the difficulty of this shared analysis, Schein stresses that whoever manages the initial analysis “should be able to avoid substituting himself for the client and instead recognise that the problem and the solution belong to the client and to him alone” (Schein 1999, p.21).

In the case of external projects (those performed by a company for another organisation), the importance of shared diagnosis stems from the fact that the project manager and the external accounts rarely have sufficiently profound understanding of an organisation for them to know beyond question what information is truly useful. This is because the members of the organisation read the information, reflect on them and react to them, filtering them through traditions, values and implicitly shared assumptions, in other words, through the lenses of their own organisational culture.

Furthermore, the indirect objectives of this shared analysis are to assemble and bring out latent needs. This again requires the ability to listen and analyse, a capacity to go beyond what has been expressly stated: a requirement that becomes more impelling, the more the project is aimed at achieving an intangible good..

The emergence of latent needs directly involves the kind of relationship that develops not only between professional figures (project manager and client), but also between organisations (client company and project supply company). The more a simple supply relationship becomes a partnership, the more will be necessary to re-direct the client's expectations on the basis of the needs brought out. (Damiani & Lo Valvo 2003).

In short, the immediate consequence is the requirement to establish priorities among needs and expectations, which is again an activity necessitating the ability to actively involve the client.

Translating the Client's Needs and Expectations into a Clear Project Scope

In the light of the discussion thus far, the crucial role of the project manager is to investigate initial needs in order to guide and organise the project in the best manner possible. This effort will rise to the process illustrated by the diagram below (see exhibit 1).

From needs analysis to defining the project's scope (adapted from Githens 2000)

Exhibit 1: From needs analysis to defining the project's scope (adapted from Githens 2000)

According to Githens (2000), the project manager's task at the outset of the project is to “dig” behind the client's needs and expectations. This entails analysis, verification, definition of priorities and congruencies. This investigation must lead to a second stage in the project: the requirements definition, that is, to define what the product/service resulting from the project should be able to deliver.

The next step is to describe the characteristics of the product, matching the requirements previously identified. Finally, description of the product gives way to design of the project: that is, all the work needed to realise the product as previously defined. The process just described is obviously an ideal one which moves from the customer's needs to design of the project, and in which each transition from one phase to the next is crucial: if it is not carefully managed, numerous problems and distortions may ensue.

The project manager plays two essential roles in this process, on one hand as translator and on the other as challenger. The term ‘translator’ emphasises that the project manager inspires an effort to translate one phase of the process to the next: from needs to requirements, from product characteristics to project characteristics. By ‘challenger’ is meant that the project manager assumes responsibility for achieving the result while respecting the three classic constraints (time, costs and requisites) - but only after s/he has negotiated a shared vision of the project with the various stakeholders involved.

The Project's Success as a Value that the Client Obtains from the Project's Results

For years there has been wide-ranging debate on the measurability of a project's success, and consensus on the parameters to use for the purpose is still far from being achieved (Rosenau 1993; Kerzner 1998). The absence of a common vision of a project's success is also evident in field analysis: project managers apply very different criteria in measuring success, and in general there seems to be no agreement, except in reference to strictly quantifiable parameters like time and cost.

It is undeniable that project success is a very complex concept, which is not always interpreted univocally by the various actors involved, each of whom develops his/her own personal meaning for the initiative (Hoegl & Gemuenden 2001, p.438). However, an interesting perspective from which to interpret a project's success is that of the client. If this perspective is used, a project's success is no longer exclusively tied to mere respect for the schedule, budget and scope (the iron triangle), but is instead viewed in terms of its correspondence to the perceived needs of the client. Success is therefore defined as the value transferred to the client, the value perceived by the client in relation to the project's product. It is clear from the terms used that this is a much vaguer, undefined area in which measurability is more complex and subjective perception plays a greater role.

From the standpoint of the project manager, adopting this perspective means measuring a project's success not only in terms of its conformance to requirements, but, also, and especially, of its fitness for use. In other words, a project to be considered successful must comply with the requirements defined at the outset, and perhaps over all, it must deliver a product or service that matches the real needs of those who launched it.

This point can be further specified by introducing the distinction between benefits and features. At the outset of almost all projects the client is interested in and focused on the benefits, that is, on the advantage received from the project. A crucial task for the project manager is translating these benefits into features - that is, into characteristics of the product-service that are truly able to produce the benefits expected. One way to achieve this passage is helping the client to “visualise” what the final outcome of the project will be and to support him/her in sharing this vision with the relevant project stakeholders.

Context Analysis and Context Management

The environment in which a project is carried out and the context's distinctive features may closely influence the project, the way in which it is conceived, and possible approaches of its management. There is, therefore, no doubt that projects require those who manage them to test the terrain: that is, interpret the substantial reasons for the initiative.

The advisory perspective stresses the importance of the project manager's endeavour to interpret and reconstruct the context, the map of stakeholders, the forces at play, the interests, the possible organisational influences, the relationships between the project and the other initiatives under way.

The variables at work within the organisational context relevant to the project are varied and closely intertwine. Schematically, it is possible to identify at least three areas (Damiani, Lo Valvo, & Pipitone, 2004): the organisational culture; processes and procedures typical of the organisation in which the project is managed; and the organisational structures.

These are very far-reaching themes and aspects, detailed treatment of which would be beyond the scope of this article. I shall therefore make only brief reference to them. Essentially, they concern the answers to questions such as: what is the organisational role of the resources involved in the project? What is their professional experience? And further, do procedures exist to guide the project work or are project resources free to proceed as they see fit? Are processes and procedures of the rest of the organisation influencing the project? As regards organisational structures, is it possible to ask where the project is situated? How does the organisation's configuration affect the project management methods? What communication and decision processes should be followed? Finally, how does the organisation's culture influence the way in which the project is managed and understood? To what extent can the organisational culture be useful in steering the project?

The Actors System

Closely linked to reconstructing a project's context is the activity of recognizing and understanding the various types of clients. When managing a project the project manager must analyse and segment the client system, carrying out what is usually referred to by the term stakeholder analysis (Bonke & Winch, 2000).

In general, it is possible to outline a map of the actors that, notwithstanding specific aspects related to the type of project and the characteristics of the reference organisation, is characterised by the presence of some recurrent figures (see exhibit 2): the client (who has a need or necessity and promotes the project), the project manager (who must respond to the client's needs or expectations, “bringing the result home”), the project team, the end users (those who will use the project's output product or service), the sponsors (who provide the financial resources so that the project can be implemented), and the external suppliers.

However, in contrast to what at first sight may seem to be a rather simple activity, defining the actors system is in reality a particularly tricky and complex process. This is so for two main reasons.

Firstly, the actors system is almost never clear and defined from the outset; on the contrary, it requires constant redefinition and reinterpretation. In a certain sense, as the project develops the map acquires borders and contents which gradually become clearer and more defined. It is wise, however, to keep in mind that the boundaries identified often change and evolve over the course of a project's development (Mead S.P., 2001).

Secondly, the various stakeholders, or actors, involved are characterised by a multiplicity of levels in terms of their ability and capacity to influence the project; furthermore, each has its own set of requests and expectations for the project. The situation is complicated by the fact that, in many cases, these requests become antithetical, generating tensions and setting one party against another. Therefore, one of the project manager's tasks is to strike a balance among the various needs and maintain constructive relations around the project.

The most common roles in a project stakeholder analysis

Exhibit 2 –The most common roles in a project stakeholder analysis.

Building Client Relationship

Not infrequently, the project manager is viewed by the client as mainly a subject matter expert on the specific problem which the project is intended to solve. Yet, besides technical knowledge, one of the crucial competencies of a project manager is the ability to involve the organisation in diagnosis and in the development of the project. In other words, as well as skills related to his/her own specific application sector (computer science, plant engineering, training, etc.), the project manager's ability to build relationships and manage client relations is of fundamental importance.

It therefore follows that a project manager must be an expert on the human relations. S/he must in particular be able to foster trust and to establish interpersonal relationships founded on mutual collaboration. Managing and coordinating a project crucially requires an understanding of the cultural rules that govern interaction and communication.

The empirical research highlighted various aspects of the relational dynamics specific to the client-project manager relationship such as: managing the psychological contract, implicit expectations, and resistance to change. I shall now endeavour to describe some of these aspects.

Firstly, it is essential for the project manager to analyse and contribute to the conscious definition of the implicit and explicit psychological contract between him/herself and the client. Defining what each of the two parties expects to give and receive is crucial, and so, too, is identifying the psychological and interpersonal conditions that must come about if this exchange is to take place in the most advantageous manner possible (for example, trust, acceptance, mutual respect may be necessary) and determining how these conditions may be respected.

Closely connected to the theme of psychological contract is that of role negotiation and implicit position. The relationship between the client and the project manager is often asymmetric. Restoring balance to it requires knowledge of the social dynamics of position and role. In every relationship within an organisational setting, in fact, the initial position and role that each party attributes to the other on the basis of cultural norms and personal expectations exert a strong though not immediately visible influence.

In particular, when a client perceives a problem, s/he begins a conscious or unconscious process whereby s/he decides to whom s/he should turn for assistance. This selective process generates a stereotype of what the project manager should deliver, and this image does not necessarily correspond to what the latter is effectively able to provide.

Exploring reciprocal expectations is an important step towards clarifying reciprocal role expectations. It is for this reason that a large part of the literature on consulting and client-supplier relations stresses the importance of stipulating a “contract” at the beginning of the relationship (Müller & Turner, 2002). However, in the early phases of the relationship, neither the client nor the project manager possesses enough information to develop a definitive contract. Progressive exploration of reciprocal expectations may be a concept that more closely corresponds to the process that actually takes place (Schein, 1999).

Although awareness of how a client may project pre-concepts onto the project manager, it should be borne in mind that the opposite behaviour also exists: that is, the tendency for the project manager to project his/her stereotypes onto the client's reality. For project managers, especially those working on external projects, learning to recognise the real state of affairs and to work on them requires understanding that reality is filtered through lenses unique to each individual, and is therefore distorted by his/her perceptive biases. During this activity it is vitally important for the project manager to admit that what s/he knows is not the reality but the interpretation given to it by each individual on the basis of their stereotypes and beliefs. It is therefore of primary importance to let the client explain his/her own situation and point of view, so that the project manager can then actively conduct inquiries in order to remedy his/her ignorance.

Another competence closely linked to managing the psychological relationship with the client, and with the stakeholders in general, is the ability to deal with resistance to change. Change and innovation are intrinsic to all projects. However, the majority of individuals are resistant to change. Firstly, because every new experience brings with it the sense of insecurity provoked by abandoning the traditional way of doing things; and secondly, because change challenges previous experience and the results achieved hitherto, generating disorientation and anxiety. The project manager must therefore learn to recognise and manage the inertia which is the natural consequence of resistance to change.

Understanding the Influence of Some Intrapsychic Processes

The ability to manage relations between two interacting subjects, in the specific case of the project manager and the client, crucially requires understanding of processes that occur in the mind. In other words, in order to manage a relationship in the best possible manner, it is necessary for the actor to assess his/her own sentiments, inclinations, perceptive distortions, and impulses. Developing this awareness is obviously a long and complex cognitive process, which I shall now briefly discuss, as I believe it to be often undervalued although it exerts a significant influence on the relationships between interacting subjects in general, and consequently on those operating within a project as well.

The activities taking place within the mind, and the way in which they influence behaviour, can be illustrated by the following model proposed by Schein (1999, pp.91u-105). According to this model (known as the ORJI cycle), we observe (O), react emotionally to what we observe (R), analyse, elaborate and express judgements based on observations and sentiments (J) and intervene (I), that is, take concrete action to produce events. The sequential model described (see exhibit 3) is a simplified representation of dynamics which are in reality extremely intricate, and it is, in my opinion, useful because it permits analysis of some complex aspects of our mental processes.

Observation should accurately record what is happening in the surrounding environment. However, we are not passive recorders of information; rather, we choose among the available facts according to, first, whether we are capable of recording them on the basis of our language and previously learned concepts and, second, according to whether we want to record them, whether we believe them to be useful. Various psychological studies have shown that considerable perceptive distortion may be caused by such defence mechanisms as negation and projection. On transferring these findings to the field of project management, the project manager must endeavour to remain rooted in reality as much as possible, drawing on his/her own personal history to identify his/her preconceptions, inclinations and stereotypes.

the ORJI cycle from Schein (1999)

Exhibit 3 – the ORJI cycle from Schein (1999)

Observation is followed by emotional reaction. Here the complexity resides in the fact that we are often unaware of these emotional reactions. Our culture teaches us that we should not permit our feelings to influence our judgement, but, paradoxically, we often end up basing our actions more on our sentiments, while deluding ourselves that we are only obeying reason. It is essential that the project manager be aware of his/her own sentiments, in order to ensure that his/her responses are not subject to distortion, and also so that s/he can use these feelings as diagnostic indicators of what is taking place with the client.

The process which follows reaction is judgement. The ability to analyse information, carry out evaluations and formulate judgements is at the root of the human ability to fulfil complex objectives and organise a multiplicity of actions over time. However, theories such as that put forward by Simon (1947) have stressed that agents possess only a limited ability to process information (bounded rationality). Humans act on the basis of incomplete information; their objectives are not always perfectly clear; and actors are not always able fully to evaluate the consequences of their choices. Consequently, a project manager must be aware of the limits to his/her reasoning power, and recognise that the effectiveness of personal judgement, and therefore the action strategy selected, is closely dependent on the quality of the data on which it is based.

Judgement is followed by intervention, which in its turn is influenced by the possible distortions that have been noted: selective gathering of data, reliance on stereotypes, perceptive distortion due to emotion, action strategies that are only apparently rational. In sum, the project manager's difficult task is to gain personal awareness of these dynamics but also to help clients understand that these processes may cause behaviour not always coherent with goals.


In this article I have discussed certain aspects of the advisory dimension which, in my opinion, characterises the figure of the project manager. Not infrequently, I meet project managers who tell me about their sense of discomfort at performing their professional duties as mere implementers, caught between the impossible demands of clients and the rigidity of those who are supposed to be collaborating on a project.

My direct observation as trainer, the empirical research conducted, as well as the reflections of various organisational scholars have prompted me to note that, in actuality, between the folds of operational obligations and binding mandates a series of “manoeuvring spaces” almost always exists. These spaces are largely linked to scoping activities, that is, to project initiation and definition phases.

This is why the advisory dimension of the project manager is expressed in a series of activities for guiding the client, developing and managing project relationships, defining the boundaries of the project, mapping out the interests at play, constructing the meaning of actions. In sum, the advisory perspective goes beyond the traditional interpretation of the project manager's role, highlighting a series of competencies crucial for the success of a project, and which specifically involve consulting, guidance and managerial skills.


Bonke, S. & Winch, G. M. (2000, June) A mapping approach to managing project stakeholders. Proceedings of PMI Research Conference 2000 “Project Management Research at the Turn of the Millennium”, 197-208. Upper Darby PA: Project Management Institute.

Damiani M. & Lo Valvo. P (2003, May) La gestione progetti: una scienza che cambia, ZeroUno, 256 (5)

Damiani M., Lo Valvo P., Pipitone I. (2004) Project management – organizzazione, metodi, relazioni. Milano: Il Sole 24 Ore.

Engwall, M. (2002) No project is an island: linking projects to history and context, Working Paper, Stockholm: Stockholm School of Economics.

Gervaise, H. (2001, November) Project Culture: a Paradigm Shift in Project Management. Proceedings of the PMI Annual Seminars & Symposium, Nashville, TN. 123-136. Upper Darby PA: Project Management Institute.

Githens, G. (2000, September) Strategies for Balancing the High Wire Dynamics of Product Innovation. Proceedings of the PMI Annual Seminars & Symposium, 94-102. Upper Darby PA: Project Management Institute.

Hoegl M. & Gemuenden H. (2001) Teamwork quality and the success of innovative projects: a theoretical concept and empirical evidence. Organisation Science, 12 (4), 435-449.

Jackall, R. (1988) Moral Mazes. The world of corporate managers. New York: Oxford University Press.

Kerzner, H. (1998) In search of excellence in project management: successful practices in high performance organisations. New York: Van Nostrand Reinhold.

Kunda, G. (1992). Engineering culture. Control and commitment in a high-tech corporation. Philadelphia PA: Temple University Press.

Lundin, R.A. & Söderholm, A. (1998) Conceptualising a projectified society – Discussion of an eco-institutional approach to a theory on temporary organisations, in Lundin, R.A. & Midler, C. (editors) (1998), Projects as arenas for renewal and learning processes. Norwell MA: Kluwer Academic Publishers.

Mead S.P. (2001, December) Using Social Network Analysis to Visualise Project Teams, Project Management Journal, 32 (4), 22-29.

Project Management Institute. (2000) A guide to the project management body of knowledge (PMBOK® Guide) (2000 ed.). Newtown Square, PA: Project Management Institute.

Rosenau, M. D. (1993). Successful project management. New York: Van Nostrand Reinhold.

Schein, E.H. (1999). Process Consultation Revisited: Building the Helping Relationship. Reading MA: Addison-Wesley Publishing.

Simon, H.A. (1947) Administrative Behaviour – A Study of Decision-making Processes in Administrative Organisation. New York: Mac Millan.

Standish Group (2000) The Standish Group's CHAOS Report, from

Van Maneen, J., Schein, E.H., Steele, F.I., Essays in Interpersonal Dynamics. Homewood, Illinois :Dorsey Press.

Van Maneen, J. & Kunda, G. (1989) Real Feelings: Emotional Expression and Organisational Culture, in Staw, B.M., Cummings, L.L. (editors) Research in Organisational Behaviour, 11, Greenwich Conn.: Jay Press.

© 2004, Pier Paolo Lo Valvo
Originally published as a part of 2004 PMI Global Congress Proceedings – Prague



Related Content

  • Scope and stakeholder management member content open

    By Orlando, Doug Project managers must avoid scope creep during projects, yet scope change should be embraced and used to enhance project outcome. Drawing from the Project Management Institute's A Guide to the…

  • Taking requirements to the next level member content open

    By Burek, Paul If a project suffers from vague or misunderstood requirements, missing information, or an unclear definition of scope, project failure may be imminent. These problems can occur with any type of…

  • PM Network

    To the End Zone member content open

    By Burba, Donovan The National Football League's (NFL) Dallas Cowboys franchise has long been called America's team. To provide this team with a new stadium that could showcase their games in a way that matches their…

  • Creating clear project requirements member content open

    By Burek, Paul Defining a project's requirements is not simply an exercise in understanding what a client needs; it is a process for outlining how the project team can help the client realize their goals. This…

  • PM Network

    Capturing project requirements and knowledge member content open

    By Githens, Gregory D. A requirement is the capability needed for describing a project's product; requirements are usually notated as product specifications. The process of requirements specification is very important…