Project Management: Integrating Methodologies and Behaviors

By Marco Sampietro

Project management is a vast discipline that over the years has come to encompass content from a variety of fields. The book identifies the factors that are crucial to good project management and emphasizes the importance of integrating the methodological and organizational aspects of project management. Knowing how to manage projects provides companies with an important competitive advantage, as shrinking product life cycles reduce the time to return on investment, which means less tolerance for errors. From the main characteristics of projects to the identification of the key factors for their success, from the concept of life cycle to the behaviors that accompany each phase, from stakeholder management to the management of physical and economic resources, the book illustrates every relevant aspect providing numerous examples and concrete cases. A particularly extensive chapter is devoted to the Agile approach, describing its inception, its various applications, and some key operational practices. The volume is completed by an in-depth focus on the management of multi-project environments and a checklist for assessing the robustness of a project at each stage of its life span.

• Language: English
• Publisher: EGEA Spa - Bocconi University Press
• Release date: Nov 14, 2022
• ISBN: 9788831322607

Book preview

Background

Project management is nowadays a broad discipline, and probably a few thousand pages would not be enough to touch all the topics related to it with adequate depth. Over the years, project management has not only developed original contents, but it has also embraced contents coming from other fields, which have proved to be relevant.

In the following pages, therefore, I have tried to distil the key elements of effective project management, starting from the observation of how important it is to oversee both methodological and organizational aspects. Usually, these two perspectives are the subject of separate sections or chapters, with few or no points of contact. The peculiarity of this book is instead the integration between the two dimensions. Project management methodologies are, in fact, used by people, and the way they interpret, use, and disseminate them has a great impact on their effectiveness. Separating methodologies from people would not represent how project management in the real world works.

The book lends itself to different levels of reading. Project management fundamentals are exposed in plain text, while other details are added in three different types of boxes: in-depth studies addressing advanced topics or curiosities; case studies related to the experiences of some companies; and historical notes that explain the origin of some elements of project management, sometimes with real twists.

So, I wish you all a good read, hoping that the book will support readers in improving project performance.

Introduction

To summarize what kinds of activities organizations (all of them) carry out, we could simply say: processes and projects. In some organizations, such as consumer goods manufacturers, banks, and energy suppliers, the process component is predominant; in others, such as construction companies, software development companies, and consultancy firms, the project component is more relevant, However, it is unthinkable to identify organizations that do not carry out both types of activities.

Processes and projects can be seen either as being at odds with each other or as having strong similarities. To emphasize differences, we can mention that processes are carried out repetitively, so they do not have an expiration date; they are designed to last. While when speaking about projects, being temporary endeavors are often cited as projects have a start and an end date. In addition, it is often mentioned that projects are unique since each project is different from others.

To emphasize similarities, we can mention three elements:

•The first stems from the definition of process itself, which is a set of interrelated activities, carried out within the company, that create value by transforming resources (process input ) into a final product (process output ) with added value, intended for a person inside or outside the company ( customer ). Moreover, the process is aimed at achieving a business objective . As you can see, the definition can also be applied to projects: They too, in fact, transform inputs into outputs, have customers, and should reach a goal.

•The second stems from an almost philosophical question: Why do projects exist? The answer is very simple: In the vast majority of cases, projects exist because of the need to create new processes or to improve existing processes. Take the development of a new information system or the construction of a new industrial machinery: These are undoubtedly projects, but once completed, they will be used for process activities.

•The third consideration arises from questioning a romantic view of projects, in which the element of uniqueness is strongly emphasized to the point of extreme assertion that each project must be managed in a completely customized way. In reality, many organizations run very similar projects, where the traits of repetitiveness outweigh the traits of uniqueness. Consider a firm specialized in residential constructions: While each house may have different characteristics, the structural calculations, working methods, and materials to be used are well known, unless there are very specific client requests. It is thus a matter of combining the different inputs and then following very consolidated work processes. In essence, even projects can consist of processes, and the more projects are similar, the more project processes can be standardized.

The commonalities between processes and projects do not always make it easy to clearly distinguish them. In practice, all things being equal, some organizations prefer to treat some processes as projects and, conversely, some projects as processes. For example, for some retail giants, opening a new store is considered a process, as it is now so familiar with this project and its procedural aspects that it no longer generates uncertainty; conversely, for a newly formed firm, opening its first store could be an extremely complex project.

Regardless of whether or not you are looking for similarities between processes and projects, it is clear that companies are now carrying out more projects than in the past. Causes are well known: Increased competition and changing consumer tastes have led to shortening the product/service life cycles and increasing the product variety. Studies report that, in different sectors, the variety of products has doubled in the last 15 years, whereas their life cycle has shortened by 25%.

To summarize, knowing how to properly manage projects is critical because:

•Organizations are doing more and more projects.

•Given the shorter product/service life cycles, there is less and less time to benefit from the investments; therefore, mistakes made during the project are less likely to be financially recovered.

•There are no signals that the trend is reversing; on the contrary, product/service life cycles will probably become even shorter in the future, and the variety of products will grow even further.

We can thus conclude that knowing how to manage projects is and will increasingly be an element of survival or competitive advantage for organizations.

1Anatomy of a Project

Projects have peculiarities that, if not well understood, may mislead people involved in their management.

We already discussed some characteristics of projects, to provide a more complete view, we can define project as a non-repetitive effort, aimed at achieving one or more goals in a certain period of time, carried out using a joint effort of a pool of resources. As we will see in Chapter 7, poor goal setting is the primary source of poor project performance. The joint use of a pool of resources emphasizes the fact that managing projects means managing resources, but above all such management of resource is based on coordination, a fundamental element we will discuss several times.

Let’s focus on the element of uniqueness (or non-repetitiveness), the origin of a series of consequences, often underestimated.

1.1 Cone of uncertainty

Let’s start with an assumption that might seem almost threatening: There are few certainties in projects. One of them is that our estimates are certainly wrong.

To understand this statement and its implications, we refer to Figure 1.1.

Figure 1.1 The cone of uncertainty

Figure 1.1 The cone of uncertainty

On the horizontal axis, we represent time flowing and on the vertical axis the estimate error. Let’s focus on the latter concept. In every project, it is necessary to estimate, for example, the duration of the project, the budget, and the number of resources required for its completion. As you can see, the curved lines indicate that the uncertainty of the estimates is greater at the beginning of the project and then decreases, in a nonlinear fashion, over the life cycle of the project. The two curved lines depict the so-called cone of uncertainty, developed by observing software development projects. The dotted line represents the true value of the variable taken into consideration. The true value, if tracked, can be measured at the end of the project. If the variable is above the dotted line, it means that we have overestimated it; if it is below, it means that we have underestimated it. If we took into consideration more variables, some could be below and others above the dotted line. For example, an oil and gas company on average reported projects behind schedule but also spent less than the available budget, which means it was below the dotted line in the time estimate and above in the cost estimate.

Going deeper, the cone of uncertainty suggests that:

•The true value of the variables is known only at the end. Along the project, we have thus to rely on estimates. This leads us to conclude that it is not relevant knowing whether our estimates are wrong, we know they are, it is more relevant to understand how much they are wrong. It is therefore necessary for people involved in projects to try to reach to a point where the estimation error is tolerable by the organization and consistent with the characteristics of the project. For example, it is physiological that on highly innovative projects, such as the development of a new molecule for medical purposes or futuristic modes of transportation such as the Hyperloop, ¹ estimates can be very wrong. Shrewd investors know this, so much so that, when they participate in such projects, they expect very high returns on their investments in view of the high risk assumed. Very different is the situation with projects that have to do with the construction of a new corporate headquarter, with standard features. In this case, a construction company unable to realistically estimate the cost of the work would quickly go bankrupt, as the average marginality of projects in the construction industry is very low. As a result, a major error on one project could erode the earnings of many other successful projects. Different industries and projects therefore have very different degrees of tolerance with respect to estimating error. However, there is one thing they all have in common: Reducing the cone of uncertainty as much as possible, therefore making fewer mistakes, is always welcome. In summary, the project team has the responsibility to try to reduce estimation errors as much as possible, in accordance to time constraints and available resources.

•The real performance of the project normally remains unknown throughout its life. Some rules of thumb suggest that after the first 20–30% of project progress, the real performance of the project is sufficiently clear. ² For this reason, the cone converges fairly quickly to values close to reality. This observation might be challenged by the fact that many projects seem to be out of control until the end. In reality, the explanation is simpler: We often lie to ourselves what we want to believe to. In fact, it happens many times that troubled projects are re-estimated. This is good, but then it is noticed that optimistic estimates are provided, without any explanation of the profound changes to the projects that led to such dramatic performance improvement. The question is: What is the rationale for such significant improvements?

In operational terms, the cone of uncertainty suggests that the project team should try to make fewer mistakes while estimating, thereby reducing the distance between estimated and actual values. In theory, the approach seems logical, but in practice, how do you achieve this? Here are two ideas, simple but often unheeded.

•Plan properly . While no one would think of heating 10 liters of water with a lighter or painting a house with a nail polish applicator, when it comes to planning, the most varied and creative ways are seen. In surveys conducted by the SDA Bocconi School of Management, interviewing future participants in project management courses (i.e., people who are theoretically sensitive to the subject), when asked if they adopted a planning method, almost all responded affirmatively; when asked about the source of the planning model adopted, over half referred to methods developed on their own; finally, when asked about their knowledge related to list of pretty common project planning methodologies, less than 20% said they knew them and even less said they used them. In summary, everyone thinks about planning, but only few adopt the correct approaches to do so. If, therefore, we want to improve our ability to estimate, it is advisable to adopt the most effective methodologies for the purpose.

•Copy (or reuse) . This may sound like a bad thing, but one of the most common problems in the project world is that... we don’t copy enough! However, it all depends on the concept of copying and how it is implemented. The concept of copying can be applied to the product/service resulting from the project, to parts of it, or to some project management practices. The first approach can be used when faced with a project that is not very innovative, that has no ambition to create product/service innovation, but simply aims to make the product/service available to clients and users. Think of the need to install a roundabout on a secondary road. Roundabouts were invented over a hundred years ago and have been installed millions of times around the world. There are also documents, freely available, that describe in detail how to design them. In this case, the best approach would be to copy existing solutions that have proven to be functional; reinventing a roundabout from scratch, without taking into account existing best practices, would likely result in less than state-of-the-art solutions, widening, not reducing, the cone of uncertainty, not to mention that the team would be engaged in low value-added activities (reinventing the wheel). In other cases, the concept of copying (or reusing) may apply only to specific elements of the project. For example, in the development of a new car, it is unlikely that all components will be redesigned. Those that are less visible to the client, are consistent with the design, and have proven to work well and comply with regulations can be reused, thus helping to reduce uncertainty. Finally, in some cases, the product or service to be developed is completely customized; nevertheless, it is still possible to reuse technical or managerial practices that have proven successful. Unfortunately, the advice to copy or reuse is not being adopted as it should be. There are basically two reasons for this:

–The concept of copying or reusing is confused with that of lowering innovation. In reality, it is a matter of copying or reusing practices and components that, compared to the characteristics of the project, are unable to create true product/service innovation. Copying and reusing allow you to be more innovative because they free up resources for value-added activities, preventing them from being wasted reinventing existing solutions.

–A very individualistic view of the project is adopted. A recurring phenomenon is that people perceive themselves or the organizations they work for as very different from other people or organizations. Seeing oneself as a little special enhances the sense of self-esteem as it avoids direct comparisons that would not always be flattering. The reflection on the world of projects is that they too, embedded in an organization, end up benefiting from this aura of distinctiveness and diversity, which outweighs rational elements. This leads to not looking for tried-and-tested solutions and disregarding advices from similar experiences that would work very well in the project. Finally, accepting suggestions and indications from outside means having a humble attitude toward knowledge, admitting the limits of one’s own knowledge and accepting that the effort of others may have generated better results than we ourselves could achieve (on this, see the box One way, a world of its own ).

While both of these attitudes cannot be attributed indiscriminately to everyone, research on the topic shows us that as many as 70% of people have a natural tendency to reinvent the wheel. However, organizational practices and rules can significantly mitigate these behaviors (a case in point in the Incentive to copy box).

The impact of project management methodologies on estimates

To illustrate the relevance and benefits of using project management methodologies on estimates, we conducted the following experiment. During the first lesson of a project management course with about forty students with an average age of 23 and no or limited work experience, we proposed the case of a business processes improvement project, with subsequent automation through IT solutions. We left an hour for the participants to estimate the project budget. Being the first lesson of the course and being the first request we made to them, none of the students had any knowledge of project management methodologies yet. The true project budget, unknown to the students, was approximately 80,000 euros. The students provided estimates between 5,000 and 300,000, while most estimates were in the 20,000–40,000 range, well below the actual cost. In another classroom with students with similar characteristics but at the end and not at the beginning of the course, we posed the same problem with the same time frame available to solve it. The students, using project management methodologies, provided a minimum estimate of 27,000 and a maximum estimate of 120,000. Most estimates were in the 50,000–70,000 range, much closer to the actual project budget.

One way, a world of its own

Before the start of a day’s training on project management in an Information Technology firm in Genoa, a seaside city in north of Italy, the teacher was alerted to the skepticism of some people toward the adoption of such approach. For this reason, he opened the course by showing data that indicated that Information Technology was one of the sectors with the highest rate of project management adoption. There was no objection to that point, probably because no one knew what project management really was. After having presented some project management topics, the teacher resumed the beginning of the presentation, showing again the data, just to remark that many other companies were leveraging project management. But then, a participant commented: Maybe in the rest of the world it works, but not in Genoa! The lecturer, a bit surprised, replied: Excuse me, but Genoa is a shipbuilding city, and in shipbuilding project management is widely used. At the level of project management culture, Genoa is even in a better position than other cities. The answer was disconcerting: Yes, but that’s the port of Genoa, here we’re more inland.

Incentive to copy

One of the world’s largest consumer goods multinationals, after a thorough evaluation of project performance, noticed that project teams tended to spend a lot of their time designing solutions that could be easily found on the market at a lower cost. This led to overuse of resources and mistakes that others had already solved. In part, this behavior stemmed emerged from the fact that they were for a successful firm, and so people tended to favor their own ideas over those of competitors or suppliers. The management, also to the light of the necessity of a strong recovery of productivity, decided however that that situation could not be tolerated any more. A new incentive program was launched: In essence, people involved in projects received incentives when they demonstrated that, through the use of information or solutions from the market, they were able to reduce the project duration while achieving the desired objectives. As a result of this initiative, many people changed their approach to projects: from let’s see how I can tackle it to let’s see if someone else has the solution already. This had a positive impact on productivity, quality, schedule, and cost performance.

1.2 Project life cycle

Let’s now delve into a second aspect of a project’s anatomy: its life cycle. Projects, as well as people, go through different evolutionary stages during their lives, each with peculiar characteristics. These evolutionary stages are called phases and represent a set of logically related activities that normally culminate in the completion of one or more deliverables. Different projects have different phases and different firms define different names for similar phases. In any case, it is possible to identify some phases that are common to most projects.

Conception. The conception phase is usually the least structured of all the phases. This phase arises from the recognition of the need for a project, starting from a situation of dissatisfaction or from the identification of an opportunity. This is followed by activities aimed at assessing whether the first project ideas make sense, whether they are consistent with the needs, and whether they will bring appreciable benefits. This phase is very iterative, as some ideas are quickly discarded, others seem more promising but then are shelved, and shelved ideas come back into focus. The output of this phase is not always formalized. When it is, the output document takes the