When project management worlds collide

img

Shane Zbrodoff

Managing Director, Pilot Project International Inc.

The project management practice spans both private and public organizations and industries including information technology (“IT”), construction, healthcare, and manufacturing. What happens when these different project management practices and worlds come together, merge, or otherwise collide? In other words, what if in project practices, different needs, standards, methodologies, and processes put projects and project managers at odds, particularly when these disciplines meet in large, megaprojects? This is common and evident in a project where there is a construction or renovation of a building facility.

Issues are further multiplied when one project management group must “control” processes of other professional project management groups, particularly in areas where they have little expertise. For example, conflicts occur in large, multi-year public works construction projects when there is a large dependence on information technology infrastructure, but information technology Project managers are not in charge (and construction project managers are). In this case, there is a high probability of significant issues and conflict, such as:

  • As construction planners and schedulers attempt to work in IT elements, confusion occurs as they expect a commitment to deploy elements and devices far in advance, and the quick changes in IT cause issues.
  • Architecture and construction review cycles or processes (schematic design, design development) don't match typical cycles required by technology (plan, analysis, design, implement).
  • With the lead of construction project managers, the leverage of IT project managers is reduced, with IT issues taking a back seat.
  • Technology vendor delivery criteria are evaluated and delivered per construction requirements, instead of being based on technical needs.
  • Project management technologists do not clearly articulate IT needs for construction; for example, IT professionals react to construction elements and require a large change process to deliver the correct solution.
  • Extra technological risks are created during deployment by failure to ask IT initially to participate in planning activities.
  • Hard technical commitments are requested too far in advance for IT's liking.
  • Construction project managers put technology at risk by deploying devices too early (subject to damage or theft).
  • Information technology will have several technical cycles over the term of the project, ultimately resulting in timing problems in terms of:
    • Technological refresh periods;
    • Different innovation cycles are;
    • Procurement timing;
    • Installation and warranty activations.

So how should professional project managers conduct and manage their activities and interact with each other? To fully organize, outline, and discuss the issues, this paper is divided into several parts:

  • Part One outlines the scenarios of project management cross-disciplines;
  • Part Two outlines a number of issues faced in cross-function scenarios;
  • Part Three outlines a list of tools and options to reference and consider;
  • Part Four outlines how project managers can operate and co-exist in large project and development initiatives while practicing their own disciplines.

These parts are outlined from an overall management perspective, with an attempt to provide a balanced approach. The end goal of this paper is to help all project managers identify solutions when facing these somewhat difficult cross discipline scenarios.

Part One: Scenarios of Project Management Cross-Disciplines

Managing projects requires project managers to gauge their resources, time, and quality elements based on what they require to achieve success. Using construction projects as an example, the undertaking is often easy when there is a clear customer or a single-purpose facility is being constructed, such as a technology data center. In those cases, IT project managers can simply make necessary decisions to guide the project through to completion, and it is clear it is the IT project manager is the authority, needing little coordination and consultation with others.

The situation, however, becomes a bit cloudier when the facility being constructed is a mixed-use or mega structure, such as an office tower, airport or sports venue. In these cases, there is a greater need for cooperation among construction, architecture, mechanical, electrical, IT, and specialty consultant project managers. Here, the spirit of project manager cooperation is needed as a project moves forward and disciplines interact; in many cases, it is the construction project manager who takes the lead with other disciplines being engaged when required during the construction process.

Looking at the construction/IT mix scenario, it is generally recognized and agreed that technology plays a significant role in today's business world and, as a result, plays a role in many projects. However, in complex megaprojects, many disciplines become “just like the other” (when, for example, IT mixes with mechanical, electrical, specialty consultants and so forth). As a result, the leverage of each project manager is also intermixed, reduced, and in some cases, simply “buried.” Worse, sometimes disciplines and activities are simply handed to non-discipline project managers to handle or passively absorb in other day-to-day tasks (e.g., IT is handed to electrical to handle). In these cases, although there is reduced conflict, the issues are managed marginally or simply ignored.

Part Two: Project Management Cross-Function Scenario Issues

There are many overt and covert issues when merging different project management disciplines and practices, with some stemming from differences in fundamental values. Simply put, some project management disciplines, by nature, value things like quality, innovation, and other aspects more than other project management disciplines. Further, some issues are only recognized when project managers are brought together and these individual values are revealed.

Many issues originate with the planning and execution cycles (lifecycle, funding, and innovation). For example, large mega construction projects take several years to develop primarily because of the magnitude of planning, engineering, and capital funding requirements. IT project managers have difficulties in these circumstances, primarily because the rate of technological change makes it difficult to speculate far in advance what will be needed specifically and the associated detailed planning.

Furthermore, large megaprojects are subject to conflict and a number of other issues due to their typically long duration. In these situations, IT will likely change technologies several times over the course of the program resulting in a number of formal project changes. Combine this with personnel changes, and the technology in the original requirements are declared invalid and basically “thrown out the window,” requiring a restart. This is not only risky and costly but also frustrating for non-IT project managers.

The collection and preparation of detailed specifications and information also differs among disciplines. For example, constructing a building involves very precise engineering requirements (e.g. structural components) and finishes (e.g., color). This is contrasted with technology that is often comprised of “intellectual” or current components making it more open to interpretation and definition. With that, IT projects are awarded loosely (often based on lowest cost when competing vendors understand they will make money based on changes).

Internal innovation processes and phases are also unique among project management disciplines. For example, although innovation occurs in every industry, innovation in construction is vastly different than in information technology, in healthcare, or in manufacturing. As a result, there are different interpretations of what innovation is and how it impacts, as well as strong opinions as to whether it should be pursued. Under a construction scenario, construction project managers may resist the need to incorporate innovations into construction projects in the interest of completing the job per specifications (and not putting the project at risk as a result of a change). Because of their nature however, technology project managers may not agree with a static approach and pursue the incorporation of innovation more aggressively.

It is also important to note differences in funding and financing. Specifically, construction projects are often funded and paid out based on inspections and draws (including physical materials used and installed). In many cases, the technology development is different (and the state of completion is much more difficult to determine). Further, construction projects result in a physical asset which can be mortgaged, in contrast to technology where the product is primarily intellectual and not usually valued as an appreciating asset.

Funding cycles are also considerably different. Many organizational units often understand annual funding and budget execution cycles, whereas megaprojects are funded well in advance over multiple years with a large budget tracking and reporting component. This difference takes time for project managers who are not familiar with mega funding to understand, particularly with respect to reporting processes and mechanisms.

In addition, construction loans can be financed using various models, with post-construction financing arranged by the facility owner. This process is somewhat foreign to other types of project managers, and transitioning issues can result.

Next, procurement strategies and techniques are different as well. For example, construction often plans and procures materials far in advance so that steel, concrete, and similar materials can be obtained when conditions— seasonal, economic, or market— are most favorable. This procurement approach often causes technology project managers issues since system technologies (such as LCD's) quickly go out of date from a model perspective or are no longer supported if they are purchased too far in advance. Finally, early procurement also wastes warranty time as devices are put into service before they are required.

It is also important to recognize differences in execution and delivery. For example, in construction, the deliveries of physical IT components and hardware are typically made near the end of the program. This late delivery reflects the technological cycles (as previously mentioned) but is also due to the possibility that hardware may be subject to theft and or damage from being on a construction site.

Late execution also results in construction project managers chasing IT for specific reasons as to why they haven't spent budgeted money throughout the program. This again relates to when a majority of IT (physical) components are executed and delivered (and subsequently when monies are spent).

Even if IT development must be started earlier (for example, to do programming, interfacing, and other IT software development), other issues stem from conflicts between a real-world, physical construction program versus a digital virtual, technology one. In this case construction project managers have difficulties defining milestones, and they treat information technology as primarily a physical execution of elements or a simple rollout of devices. As IT project managers recognize, technology deployment goes beyond this into a digital world, often needing a functional data center to support the rollout and project completion. These misunderstandings often result in construction project managers oversimplifying IT and ignoring some key elements required for project start-up and activation.

Looking at the opposite side, when it comes to information technology professionals, many do not see, or they misinterpret the specifications or drawings used for physical construction designs. This causes conflict as information technology project managers are unable to obtain clear definitions and IT requirements. Further confusion occurs when functional specifications are required, but technical specifications are authored. This increases the difficulty of testing and commissioning efforts.

Additional challenges occur from a schedule perspective. For example, when an IT change is introduced in a construction project, information technology professionals have difficulty recognizing why infrastructure or construction change management cannot occur quickly and must be reviewed by a number of parties (architects, engineers, construction managers, specialty consultants).

These issues come to a head when there is a material change in technology at a time when construction has already completed their activities. For example, if more devices must be installed nearing the completion of the facility, but painting and finishing are already completed, IT and construction will come in conflict—which party should pay for the retrofit costs?

The many differences outlined above mean decision conflict. Construction decisions requiring early technology commitment means IT project managers and others will likely be less committal or will wish to book future reviews to complete.

Part Three – Reference Tools and Options To Consider in Cross-Discipline Projects

When project management worlds merge and collide, a number of tools and options should be considered to “get everyone on the same page.” These tools and options, however, should be part of a much bigger project arsenal, with a focus specifically on a spirit of coordination and cooperation.

To start, it is obvious to most project managers that the modus operandi changes under cross-discipline projects. Here, the value of tools and processes that support cross-communication efforts are increased. Further, it helps when all project managers “step up” and participate in extensive planning and execution exercises.

As part of a mixed environment, project managers must also be prepared to deal with issues and conflicts (both internal and external) as their teams merge and discuss project planning and execution.

Issues can be addressed in many ways, often through the use of particular tools and options. This includes:

  • Joint reviews and determination of common project management languages and constraints;
  • An analysis of required elements and development of common toolsets such as change management tools;
  • Early joint milestone exercises;
  • Development of formal project agreements between disciplines.

Reviews of common project management languages and constraints (as joint workshops)are critical since they allow project managers to develop a common understanding of the joint effort. As shown in Exhibit 1, project time, budget, scope, risk, resources, and quality are collected and expressed from each discipline's perspective. Once complete, each cross-discipline can then contribute additional information to build each constraint to incorporate more aspects of the project.

Constraints

Exhibit 1 - Constraints

Applying this to the construction scenario, construction project managers should lay out their development scope clearly and openly with the invitation to gather, merge, and integrate additional IT project scope and language elements into the project cooperatively (rather than expecting others to merely adopt and accommodate the construction methodologies and ideologies in their program). Once complete, this scope then becomes a comprehensive reference to be used for additional reviews.

By far the biggest constraint to consider merging and integrating is project risk. In this case, independent risk exercises followed by jointly gathered collective risk meetings provide greater accuracy. If the construction teams shut out other disciplines, missed risk elements lead to misunderstanding the true, total risk.

Next, it is important to consider, to analyze, and to develop common management toolsets. For example, it was mentioned earlier that IT in a large construction project has a much shorter innovation cycle (which results in a greater amount of change). This means an efficient change management tool will be VERY critical in accommodating IT cycles into the construction program. In practical terms, as IT innovation occurs, the IT project manager can understand more easily how to introduce these changes, and the construction project manager will be able to accommodate the change. Put more simply, as changes are identified, there must be a process (understood by construction) as to how IT is to document and address change in a coordinated fashion. Further change management elements entail (at a minimum):

  • Identifying the need for IT change and elements;
  • Identifying the impact on the associated project and program (IT change on the construction program);
  • Recording decision makers and assumptions.

Another concern identified earlier was issues regarding procurement. In these cases, all parties should create and execute joint programs that achieve specific objectives. For example, a major issue relates to how IT procurement generally occurs late in a construction program. Recognizing this, both IT and construction should create and adopt programs like sweet spot procurement.

Sweet spot procurement simply means that technology equipment is obtained at a time when it allows the latest in technology to be installed, while also considering the lead time needed to deliver and install it on the construction site. This is shown in Exhibit 2 as the “sweet spot.” In this process, each discipline may need to make some concessions to accommodate delivery (or put more simply, although timing may not be optical, it is “acceptable”).

Using this technique, IT project managers would identify the optimal time to purchase their technology within a date range. The procurement would consider the time for determining specifications, contracts, and delivery (along with storage considerations).

Sweet spot procurement

Exhibit 2 - Sweet spot procurement

Similar joint exercises may result in more formal agreements between disciplines and a greater understanding of each other's needs.

Part Four – How Project Managers Can Cooperate and Co-Exist In Large Mega Projects and Developments

It is obvious a megaproject requires project managers to set a project environment where communications and cooperation are fundamental to execution. It is also obvious all must be prepared to be flexible within their own practices. To achieve this, project managers must draw from their soft skills.

Understanding the values and characteristics of other disciplines is also very helpful. Generalizing, IT project managers come from an introverted world, whereas construction project managers often come from a somewhat blue-collar upbringing. Understanding these circumstances provides greater insight into values and how communication and conflict is dealt with. For example, because of their introverted approach, IT project managers may be less inclined to speak up or challenge the construction project managers. IT project managers must therefore be brought into the conversation.

If construction project managers are in charge, it is recommended they reveal clear and concise construction plans to provide other project managers with the necessary information to analyze and insert their own requirements. For example, because procurement and innovation cycles are different, a procurement plan that accommodates a late IT purchase cycle allows an IT project manager to plan his or her purchase of better technology.

Further, it is the practice of some construction programs to plan the build execution fully and then engage specialized disciplines after the exercise is complete. This practice is not recommended. In many cases, early engagement of other disciplines and experts (IT, mechanical, electrical, commissioning) is recommended to avoid surprises and increase the quality of requirements.

Further, if permitted, it is also recommended that program co-location or co-collaboration models be established with cross-discipline project managers being integrated (or forced) to work together through project phases. This can also be achieved electronically by establishing common meeting and workshop forums and times.

As outlined earlier, a formal and accommodative change management process is essential to establish early in the process. Understanding that change will occur means that project managers will be prepared for this activity, and it will be put on agendas to periodically review, prepare for, and execute once required.

Project managers must be on top of their program and be prepared not only to negotiate but also to understand the related logic that is already in the project. Put another way, an IT project manager must also see how their project performs within the established timing and logic. This means they must not just defend their information they have within their project but attempt to understand what and how their impact is on the construction process. For this, timely negotiations are necessary from all parties.

Negotiations of elements (between project managers and disciplines) are best performed well in advance. For example, if a single procurement program is desired, project managers should understand needs and WHEN to negotiate these needs (rather than what they are procuring). In this sense, a last-minute or reactive program will add tense circumstances and additional program complexity.

Collective exercises are also recommended, wherein each program can build and use each other's strengths. For example, IT should educate construction engineers on how to adapt to change and incorporate innovation, whereas engineers can educate IT how to perform site walkthroughs and better negotiate with vendors with defined requirements.

Cross-project liaisons are a possible solution within the project. Cross liaisons are project managers with cross experience or backgrounds (e.g., construction, IT, manufacturing) who can clearly see, articulate, and translate each other's needs activities, and changes and essentially bridge the gap between disciplines and manage essential communications.

A full disclosure of plans and forecasts for resourcing, budgets and other project elements is also recommended to allow each project manager to analyze efforts independently while fostering greater prediction from their own perspective. This independent work, when merged, then permits the program to be vetted more clearly, with less influence and bias than if one program is influencing all aspects.

Further, independent bodies such as the Project Management Institute (PMI) and their practices should be considered and consulted, bringing together standard practices and practical knowledge. These solutions should include special cross-interest lessons learned, training, and presentations.

Finally, cross-education is hugely beneficial to aid understanding. This includes the use of standard practices (such as A Guide To The Project Management Body of Knowledge [PMBOK® Guide]—Fifth Edition) specialty add-ons, and white papers on project management practices. The Construction Extension to the PMBOK Guide becomes a great tool for non-construction project managers to review and understand construction elements. In this case, IT can understand overall construction processes and procedures for integration purposes.

Conclusions

Project management practices continue to evolve and become more complex, particularly as many cross-discipline and megaprojects are coming to fruition. It is clear project managers from all disciplines must also evolve and improve their practices to increase the chances of project success.

One can easily assume when a megaproject structure is established that all project management disciplines are unified in their understanding of project activities and practices; however, this isn't always the case. A mega project requires full program reviews be performed early and often to ensure a standard framework is in place.

To address these, an open, honest, coordinated effort is necessary in particular by project managers and other peers to reduce risks and project outputs. To be successful in cross-discipline project management efforts, this means:

  • Establishing a communication framework for cross discipline coordination;
  • Gaining knowledge of other disciplines and understanding of cross-practices and their needs;
  • Building an inventory of tools (e.g., the Construction Extension to the PMBOK® Guide Third Edition) and alternative tools (e.g., customized procurement schedules) should be considered.
    • This includes a review and understanding of:
      • Project constraints: budget, time, resource, procurement, resources, scope, etc.
      • Required toolsets: change management elements
      • Updated practices: merged and joint activities such as sweet spot procurement

Overall, to succeed in large and complex projects, project managers, regardless of their backgrounds or interests, must incorporate and appreciate other project management disciplines through self-discovery, education, and enhanced communication efforts.

Project Management Institute. (2013). Construction extension to the PMBOK® guide—third edition. Newtown Square, PA: Author.

Project Management Institute. (2013). Th project management body of knowledge (PMBOK® guide)—Fifth Edition. Newtown Square, PA: Author.

Zbrodoff, S. (2010). Pilot projects, making innovations and new concepts fly. Calgary, AB, Canada: Pilot Project International Inc., 14.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2014, Shane Zbrodoff, Pilot Project International Inc.
Originally published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Identifying Challenges and a Research Agenda for Flow in Software Project Management member content locked

    By Dennehy, Denis | Conboy, Kieran Flow and its associated tools and metrics are increasingly being reported as an approach used to achieve continuous deployment of software and delivery of value in software development projects. Yet…

  • PM Network

    Escaping Pilot Purgatory member content locked

    By Waity, C. J. Pilot projects can bridge the gap between a brilliant idea and a valuable product—but only if the bridge is successfully completed and built to scale. And in the age of disruption, that doesn't…

  • PM Network

    Hands-On member content locked

    By Karunaratne, Charmaine Although the software development life cycle (SDLC) is an important part of any software project, IT project managers rarely seem to raise the topic. Instead, they leave it to the development teams…

  • PM Network

    Best of Both member content locked

    By Graetsch, Ulrike Maria When leaders at rapidly growing organizations establish a project management office (PMO), they're often seeking better control over which projects are started, more oversight of projects in…

  • Project Management Journal

    How to Buffer the Family Costs of Project Citizenship Behavior member content locked

    By Zhong, Rui | Xia, Nini | Hu, Xiaowen | Wang, Xueqing | Tiong, Robert Previous studies have mainly concentrated on the desirable aspects of project citizenship behavior (PCB) but largely ignored its dark sides. We seek to fill in this gap by exploring whether and when…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.