While many researchers concern themselves with the skills being taught to our students, there have been very few inquiries into the tools and techniques actually put to use in industry. A number of studies propose that different aspects of PM education be strengthened or changed in some manner, such as the addition of experiential learning [1], group work [2], and the teaching of both technical and human skills [3]. However, we have yet to obtain a clear picture of how many of these skills and techniques are put to use as taught or whether they are modified or even ignored. It is commonly known in the information systems industry that much of what is taught during systems design classes as formal processes are actually only used informally or not at all in many firms, and there is anecdotal evidence of the same phenomenon occurring in the management of projects in other industries. This research follows [4,5] as one of the few analyses to inquire into the manner in which industry actually applies these processes to the projects they manage.
This study is set in the information systems industry. This venue was chosen for a number of reasons, not the least of which is the author’s familiarity and experience with this application of PM. Moreover, the information systems function within a firm has lately become a key creator of competitive advantage, thus it is an important strategic aspect of the firm. Also, the business of information system design and implementation takes place in almost all industries and carries with it a significant level of variability and dynamicism, making PM a very important, and difficult, function. These characteristics combine to create a useful place to begin this research.
2. Literature Review
The present research fits into a research space peripheral to the study of project management education in that the central question centers on the difference between PM tools and techniques taught and those that are applied. Thus, the literature surrounding these educational issues helps to frame the research by describing those PM processes and techniques that are currently being taught in PM courses and degree programs. The second part of the literature review discusses the few papers that have begun the process of exploring the actual versus presumed use of PM tools and techniques in industry. These analyses will provide this project with some context and a means of validating the qualitative methods employed.
2.1. PM Education
Researchers in the field of PM have been examining PM education from two perspectives, topics and pedagogy. In terms of pedagogy, the primary thrust has been the enthusiasm for a more team-based, experiential learning environment. For example, [1] stress the importance of experiential learning as the only way for students to obtain a firm grasp of the complexities and dynamics of a typical project environment. The authors stress the need for education to prepare the student to understand a project and operate at the individual, group, and organizational level. Projects rarely exist in a vacuum and the better positioned a PM is to understand the project’s context in the organization, the better he or she will be in navigating the inevitable organizational pitfalls. As part of experiential learning, students should spend at least part of their time working in a team environment [2]. This allows instructors to provide a glimpse of how many projects are run. Rather than the lone PM giving direction from above, a typical project is run by a team that must negotiate both within itself and with outside entities for resources. Thus, a team environment within the classroom helps to acclimate students to what can be a challenging aspect of project management. With proper preparation, PM professors can create an environment that actually includes the approximate level of uncertainty and political activity, but that might be appropriate only for graduate students with some understanding of PM basics.
Pedagogy aside, there is much attention being paid to what we teach our students. In an effort to prepare students with all the skills and knowledge necessary to become productive in a project environment, researchers have suggested that a number of topics be included in a PM curriculum beyond those that typically occur. In a traditional PM course, the curriculum tends to follow the Guide to the Project Management Book of Knowledge (PMBOK) [6]. This is true both in the United States and beyond, though in other parts of the world there are other standards utilized that closely mirror the PMBOK. There is no call to abandon the PMBOK as it embodies the essential tasks and tools necessary to manage projects. It is important that a budding PM be conversant in these tools in order to become a productive part of the PM team [7].
Beyond the PMBOK, however, there are a number of topics that are increasingly considered to be important areas of knowledge for the well-educated and effective PM. For many researchers, the application of “soft” skills beyond the “hard” skills enumerated in the PMBOK can be the difference between a well-run project and one ridden with both organizational and technical problems. The concept of soft skills cuts a wide swath through the organizational and interpersonal knowledge base. The importance of these soft skills is discussed by [8] as they discuss the improvement in soft skill proficiency after the conclusion of comprehensive PM training. Leadership skills have been identified as being particularly important as many activities surrounding the successful conclusion of a project require close coordination and benefit from strong leadership [9]. Most projects are far too large and complex for one person or sometimes even a small team to complete. Many project teams consist of hundreds of people working together across various time zones, cultures, languages, skill sets, and organizations. Leadership plays a key role in the coordination of these team members as well as encouraging them to perform at their best. The researchers in [3] extend the call for a more comprehensive knowledge base in the PM course by pointing out that many soft skills are implied by the PMBOK but never explored in depth.
Other areas of expertise that have been identified as being essential to the successful PM include the addition of complexity theory to the fields covered as well as an examination of the ethical issues inherent in projects. Complexity theory provides a framework within which the complications that make projects difficult to complete might be examined and solved [10]. As the authors point out, projects in the modern business environment are characterized by complexity, chaos, and uncertainty, and oftentimes the projects with the most value occur in the most inhospitable situations. Thus, knowledge of how complexity affects decisions and, more importantly, can be used to the project’s advantage, is crucially important.
As information systems become increasingly embedded in every industry from healthcare to finance, and since the creation of information systems occurs within a project framework, it has become much more important for an ethical understanding of projects to be included in PM education [11]. Information systems in these and many other industries handle extremely sensitive data and the accidental (or intentional) release of these data could prove disastrous. This is but one example of ethical dangers that might be avoided with proper ethical education for project participants.
These are but a few of the PM areas of knowledge that have been identified by researchers as being of more than a passing interest to prospective or current project managers. As the field of project management continues to mature, it is likely that this list of knowledge areas will continue to expand, challenging project management curricula to include them. The next subsection examines those aspects of project management that, when properly executed, lead to successful projects.
2.2. Actual PM Practices
One of the most recent studies conducted to evaluate the use of PM tools and techniques is that of [4]. Using a rather large, multi-country survey, these authors were able to determine that many projects do not use all, or even any, of the traditionally taught PM techniques. The authors find that the extent to which standard PM tools and techniques are used varies across the category of tool as well as across national boundaries. For example, a majority of firms surveyed in Australia and Canada used an “in house” methodology rather than one standardized in sources such as the PMBOK. Far fewer admitted to following the PMBOK during their projects. Likewise, a majority of respondents used Microsoft Project or the like, but some complained that the tools was inadequate for large projects and carried with them too much administrative overhead. Lastly, approximately 10% of the firms surveyed used no project management methodology at all and between ten and twenty percent, depending on the country, used no project management software.
This research, along with its predecessor [12] suggests that project management methodologies and tools are far from standardized in use, despite what might be presented in the classroom. Moreover, the use of any PM tools and techniques at all is hardly guaranteed. This level of uncertainty increases dramatically when decisionmaking and risk management tools are considered.
The researchers in [5] examined a similar set of variables, but their approach was to determine the relative value of the various tools and techniques listed. Respondents specified how often various PM tools and techniques (from a provided list) were used. Most of the more commonly known tools and techniques were listed as being used most often, but the data did not reflect how many respondents used each tool or how many respondents did not use any tools.
This review of the literature demonstrates an important issue. The skills and tools contained within documents such as the PMBOK and taught in PM programs around the world are still held to be worthy of intensive examination and revision. However, it remains largely unexamined whether the tools and techniques taught in these programs and discussed by these researchers are actually being put to profitable use. In other words, how much of what is taught and studied actually finds its way onto a live project. This question is relevant for a number of reasons. First, if the procedures utilized on a typical project are not those being taught or researched, this mismatch should be addressed so that the alignment between academia and industry can be improved. Secondly, if this mismatch does exist, we should try to understand why it is so and either find ways to remove the reason(s) or develop new ways of managing projects that do not run afoul of these issues. Lastly, if the procedures taught and examined are not those in use, the impact of this mismatch should be addressed from a performance and strategic alignment perspective.
Thus, we come to the research question at hand. What PM tools and techniques are actually used in industry and, if there are in fact some processes and tools not used, why are they left out of the current PM toolkit?
3. Methodology
As an exploratory study, a qualitative methodology is an appropriate first step. Without existing theory to base a quantitative analysis upon, a qualitative study provides a means to identify the various facets of the situation at hand and allows the researcher to create some foundational concepts upon which further research might be based. In this case, the methodology selected was the semi-structured interview. Using this method, the researcher starts the process with a series of predefined questions, sometimes provided to the subjects before the actual interview takes place. In the present study, the list of initial questions including questions regarding the control of scope during the project execution, the methods by which communications occur between project stakeholders, and the definitions of a successful project. As the interview proceeds, the researcher can then pose follow-up or clarification questions that can provide further data for analysis [13]. In many cases, the most difficult aspect of the methodology is obtaining access to the necessary research participants.
In the present study, the participants are all midto upper-level managers in the cosmetics, banking, brokerage, and electronics industries. Each of these managers is directly involved in overseeing the creation of information systems within their respective firms. The choice of these participants was due partially to accessibility and partially to provide some constancy of professional perspective, in that all of the participants are from the IT sector, even if their employers are not. Each of the participants, a total of five, participated in an interview lasting approximately one hour, with numerous follow-up questions being answered by telephone and email. The data gathered during these interviews was transcribed and subjected to content analyses. During this process, a close reading of the transcripts begins to uncover themes that, while somewhat fuzzy at first, begin to coalesce as the analysis continues. Using a technique known as open coding, these themes are grouped together and examples from the text are employed to illustrate them. Often, the themes identified in the analysis of interview data, or any textual data contributed by research subjects, will include certain conflicts that must be identified and the reasons for their existence analyzed. However, the present sample of interview data provided very well aligned themes with very little in the way of variance.
4. Findings
A number of themes became evident during the analysis of these data. One of the most serious, and possibly least surprising, is that many of the participants in the study considered the formal use of PM tools and procedures to be wasteful of their time and resources. Though many of the participants are provided with state of the art PM software and sufficient computing platforms to utilize these tools, they are often unable to see the value in using these tools during the project planning or execution process. They complain that all but the most rudimentary tools are far too cumbersome to use in a typical project environment and that any advantages they provide are not worth the time involved in using them, not to mention the opportunity costs associated with other, more “worthwhile” activities.
Some participants extended these sentiments to include their view that their firm was doing fine without these complicated tools. The firm’s size has grown significantly of late without these tools and techniques, thus lending support to the view that these PM tools are unnecessary, at best, and a distraction at worst. The project manager from the cosmetics put it very succinctly: “PM didn’t even exist here and this company went from a $2B company to a $10B company doing what they did the old way.” The respondents who felt this way were more experienced managers and had not received formal PM training during their education. Those with some formal PM training, which was a small segment of the participant group, were more inclined to embrace the PM tools in use, though this receptive attitude was modulated by organizational culture and standard procedures.
Of those managers who were unhappy with the computer-based PM tools in use or on their way, most of them stated a strong preference for interpersonal, rather than computer mediated, communication. They are much more comfortable discussing options and status in an informal group setting than tracking a project using a networked PM tracking tool, thus lending support to the importance of the inclusion of soft skills in PM curricula. The participant from the cosmetics industry stated that the intranet-based tool in use at his firm detached him from the project and lessened his ability to manage it properly. “I’m somebody who just, maybe I’m old school, or my interest in daily work is more hands on with people that are doing the work or working for me rather than setting at my desk for 5 hours creating plans and drawing wall charts and monitoring.” His approach was highly dependent on interpersonal relations and he did not feel that he was fully able to utilize these strengths in an electronically-mediated environment. He expressed significant displeasure that some of his design team was going to be located in other geographical areas thus forcing a more detached, long-distance relationship.
A common complaint of many managers is that the tools in use, even the most popular PM tools, serve as more of a barrier than a tool to improve project performance. In the words of one participant from the banking sector, “I like Microsoft Project to plan the project, I hate it to execute the project. It’s a great planning tool but it often hinders the tracking of activities if they do not happen in the way the system has been told they would.” Small deviations in task order, which can be caused by small perturbations in resource availability, weather delays for key personnel, or even human performance variability, require a great deal of effort when shown in the project software. In many cases, the effort required to put the project plan back on track from the point of view of the PM tool is far more disruptive than the initial issue. In his view, once the tools or procedures are no longer useful for speeding up the project, they should be discarded in whole or in part, in favor of more expedient methods, even if those methods are much less formal and provide no audit trail or documentation. It should be noted that this was the sentiment of more than half of the participants, even those who routinely deal with rather large projects.
The question of project management consistency was another important theme in the data. In each organization except one, the project manager is responsible for selecting the manner in which the project will run, including the choice of which tools and techniques will or will not be used. In this environment, each manager can choose to utilize or ignore any project management tool or technique. Moreover, with no consistency enforced between projects, two projects in the same firm will use very different approaches to PM based on each project manager’s preferences. With employees being transferred between projects, it is no surprise that employees are faced with widely varying PM approaches and must quickly acclimate themselves to the various environments. This could require the project team member to adjust to different reporting requirements, coordination processes, communications processes, or scope control mechanisms, to name but a few potential differences. The potential for missteps by the new employee, and the resultant damage to project performance is substantial and is addressed in the Discussion section.
The third theme to emerge from the data is the lack of trust in various aspects of the project management team. One project manager from the cosmetics industry expressed doubt that the oversight board in charge of approving initial project budgets and scope changes had the requisite knowledge to fully understand the issues at hand. He wondered if the information he was providing to this body was being used properly to make these decisions. Other participants from the financial services industry noted that people attached to the project who have approval over the budget, but who do not have sufficient depth of knowledge of the task, pose a potential danger to successful project completion by promoting scope creep by imposing unplanned for, and often unnecessary, requirements.
Any discussion of project management styles and processes usually turns to scope control. The control of scope is often noted as a specific indicator of project success. During the course of this research, each participant was asked to describe the approach taken to set and control scope on projects they manage. The responses varied rather widely, but a majority of the respondents provided descriptions of very informal scope control measures. They explained that after the initial scope of the project was approved, the project scope was usually controlled using informal practices such as conversations or status meetings to convey or negotiate changes.
Few respondents described formal change control mechanisms except for the largest projects. While the electronics manufacturer specified rigorous scope control methods, in most cases, scope was negotiated between specific stakeholders and disseminated to the proper parties to be acted upon.
This informality is curious given the belief by most of the participants that effective scope control should start with a clear set of requirements, but that these are very hard to obtain at the beginning of a project. Thus, many IT projects, especially those adhering to a more agile development methodology, start with a rather loose set of requirements and tighten them as the project progresses. With a less than specific initial scope statement, it seems that an informal scope control process such as the processes described by these participants might prove costly and encourage project failure rather than success. However, as with the other formal PM processes, most of the project managers interviewed found formal scope control methods too costly and of limited value.
A common theme surrounding the control of scope is trust. Project managers stressed the need to trust the parties they deal with to understand that big changes cannot be made without approval, but small changes can be handled without invoking formal processes. While the importance of interpersonal and inter-organizational trust is understood [14], relying on trust as a substitute for more robust scope control processes is risky, especially as projects grow beyond the physical confines of the workplace to include widely distributed personnel in other locations and firms. This was especially evident in the bank that had just merged with one of its rivals and had yet to consolidate its internal processes. One respondent from one of the merged banks described the wide variety of scope control mechanisms in place:
“Depends on the group that you’re working with” [One of the original firms] has a heavy process driven environment and they will create milestones as you move through the project structure and require approval on each of those steps. On the [other firm’s] side it is much less formal. There will be a vision/scope document that everybody agrees to in the beginning. A high level view of here is what we’re going to implement and here is how we are going to do it. Then it’s an ongoing discussion. There is a great deal of trust.”
Projects from the two original firms were run in a completely different manner with one firm having very stringent, formal procedures for most aspects of project management while the other firm is run as described above. Significant difficulties arose when personnel from the two halves of the firm were mixed on the same project. In this situation, trust becomes a scarce commodity as these people do not know each other and they come from firms that, until recently, were rivals. Utilizing trust as a project management tool in this environment proves challenging.
As with scope management, internal communications management is also a key project function. As the PMBOK points out, plans should be put in place to determine who needs what information, on what schedule, and in what format. However, much like scope management plans, many communications plans in the organizations studied were largely non-existent. None of the project managers interviewed prepared formal communications plans, even for projects being executed on another continent. Each was content with informal communication utilizing email, telephone, or possibly an electronic document repository that was accessible to other project personnel. From one of the banking respondents: “Other than email, no. There are weekly team meetings when the teams are collocated. Each team uses technology that they choose, there is nothing standardized. As for frequency of meetings, the higher the level, the less frequent the meetings.”
The last part of each interview centered on the participant’s definition of a successful project. With the exception of the electronics manufacturer, being within budget was the first criterion mentioned to define a successful project. Staying within the initial scope boundaries and within some reasonable schedule window (usually three months) were the next most often mentioned criteria. However, one of the banks even had some informal rules for when projects are expected to be delivered: “The expectation on the business side is that the technology is going to be late. We always try to be on time, but for any number of variables we rarely are. We never ever deliver at year end, although we may want to.” Only the electronics manufacturer put functionality at the top of the list along with cost and schedule. Most of the other participants did not mention functionality or meeting the needs of the system sponsor until much further into the discussion.
5. Discussion
The data presented in the previous section displays a persistent tendency for organizations to prefer homegrown PM processes, or no formal PM processes, to those outlined in sources such as the PMBOK. The reasons for these departures from the “accepted” PM methods ranged from a lack of time to complete these processes to a perceived lack of value provided by them. Whatever the cause, these departures from PMBOK-level procedures will most likely not be a revelation to many PM professionals or to PM scholars. Of more value, however, is an analysis of what could occur should an organization decide to pursue an informal PM approach.
Of primary importance is the threat to successful project completion. Each of the participants suggested that most of their projects were completed “successfully.” With the criteria reported above regarding successful project completion, it appears that even those projects labeled successes would have significant room for improvement. Would a more closely tracked scope document lead to the same results at a lower cost or at an earlier date? Would a more formal, and effective, method of inter-team communication add qualities to a project that, while not necessarily explicitly shown in a requirements document, add to or extend its value? It is impossible to quantify the value of a more closely held scope or more effective communications, but it is not too difficult to speculate that there is untapped value to be found in managing these aspects of a project in a more predictable, orderly fashion.
This issue can also be considered beyond the success or failure of an individual project, but rather in strategic terms. Projects are usually initiated in order to perform a function or provide a product that will ultimately result in a competitive advantage for the firm. This is especially true in the realm of information systems. The full acquisition of this advantage depends on many things, not the least of which is the quality of the finished product. Quality can be measured in many ways in the IT industry, but it usually revolves around the functionality of the product as well as the efficiency of the product (in terms of human and computer resources). The functionality of the product depends greatly on the accurate management of scope as well as effective intraand extra-team communication. With the loose control of these two aspects of the project, we can expect a wider variance in quality. As the quality of the finished product varies, so too will its contribution to this competitive advantage. Therefore, with the wide variance of successful projects discussed earlier, we can also expect a wide variance in the degree to which a firm grasps the strategic benefit of the system at hand. Thus, a project that is completed “successfully” might still fall short of its original intended strategic goal.
There is a risk to innovation when a project is managed without a certain level of control or formality. Scope changes, especially when scope is added to, can often benefit from innovative solutions that offer the increased functionality without added cost or other penalty. These “costless” improvements require the application of two important and valuable project resources, innovation and knowledge. Innovation, while difficult to control insofar as timing is concerned, can be focused once the target is identified. However, when scope changes occur without due consideration and are not well communicated or documented because there are few formal communication processes, the innovation cannot always be brought to bear in time to make a significant contribution. Add to this the tendency to judge project success on cost, and the probability of an innovative solution is significantly reduced.
Project knowledge faces similar obstacles to its most effective application. An analysis of the alignment necessary between how knowledge is created and applied and the project management process is found in [15]. For knowledge to reach its maximum value during the execution of a project, it must be considered during the planning process as any other resource would be. Its acquisition and application must be considered prior to project start and any changes made to the knowledge requirements of the project must be made such that whatever knowledge resources are made necessary by the changes have time to be developed, or acquired, and deployed. With an ad hoc scope control mechanism and an informal communications plan, changing knowledge requirements are likely to be missed. This, in turn, can lead to missed opportunities to make the final result more innovative, strategically valuable, and efficient.
One of the hidden problems of homegrown or nonexistent PM processes has to do with newly hired personnel. Most students who graduate with formal training in PM, whether obtained during their undergraduate or graduate college work or through a private organization such as the Project Management Institute, reasonably expect that the processes and tools they have worked so hard to master, most of which will come directly out of the PMBOK or its equivalent, will be the tools they will use on the job. Imagine their surprise and dismay when they are told that there are no or few formal scope control mechanisms or that communications occur on an asneeded basis. This requires a two step adjustment on the new hire’s part. First, they must release the methods and tools they learned in school and then embrace the methods in use at their new employer. This puts quite a burden on them, much larger than that normally associated with starting a new job. Beyond this adjustment, this sudden change in expectations will likely have a negative effect on their ability to contribute immediately to the team as well as their ability to apply their newly gained skills toward the innovative solutions to project issues, thus eliminating one of the most valuable reasons to hire new graduates.
6. Conclusion
As an exploratory study, it is premature to speculate on the scale of the problems noted in this paper. However, the evidence collected thus far points to a rather widespread phenomenon affecting firms in many industries. Future research will further investigate the reasons behind these issues, but at this point we can make some suggestions that might relieve some of them. First, software firms and academic researchers should consider the development of a next generation cache of PM tools that will remove some of the barriers to use cited by some of the participants in the study. These tools should allow more flexibility to customize displays, change resource allocations and schedules quickly and provide the option to make small perturbations in the project’s execution without sending the whole project plan “spinning into oblivion.” As the tools become more integrated into the fabric of the project, including the financial and personnel systems in use, the reasons for not using them will fade and their usage will increase. This should reduce some of the informal management processes currently being used.
Those of us who educate tomorrow’s project managers should prepare our students to thrive both in the controlled environment of the classroom but also in the often chaotic environment of business. Besides requiring a firm grounding in the traditional tools and having a firm understanding of their value, students should also be exposed to quicker, less formalized PM processes, such as those used in many firms today. They should understand the need for making on-the-spot estimates of costs and schedules because these are often needed in meetings and informal scope negotiations. They should be taught the value of communication and how to develop their own communications plan even though none exists on the project they have been assigned to. Also, we should instill in them a tolerance for change such that entering a new company with a wholly different methodology and philosophy doesn’t paralyze them and render them unable to contribute.
While on the topic of education, all project personnel, from the new hire to the project director, should understand the importance of developing, understanding, and adhering to project compliance. Project success should be based upon all important factors, not simply cost or schedule, but functionality and whatever other factors the initial statement of work detailed. The closer we can get to properly completed projects, the greater their contribution to competitive advantage, and the more value they add to the firm.