Project management is a broad and complex subject that covers a multitude of a project’s aspects. These aspects include interface management and change management; each of these is a complex subject by itself that requires a thorough understanding of relevant questions and matters. As mismanagement in these areas can cause significant performance losses or delays in a project, the specialists assigned to these roles are critical parts of a project.
Interface Management
Interface management is the management of interactions that occur between different entities in a project. It operates from the crucial definition of an interface as a “common boundary between two (or more) independent projects, systems/subsystems, contract scopes of work, organizations, or project phases that require an exchange of data or information to obtain agreement between entities to prevent interface problems when the common boundaries are developed and integrated” (Bible & Bivins, 2018, p. 235). Interface management includes identifying, documenting, communicating, monitoring, controlling, and resolving issues across interfaces (Bible & Bivins, 2018). Thus, the purpose of interface management is to ensure effective and efficient communication and cooperation between entities that share an interface, as well as effectively resolve interface problems or prevent them altogether. This is a crucial part of projects to remain within budget, scope, and schedule.
The broadness of an interface’s definition allows it to encompass a variety of subjects. Interfaces can be broadly divided into two categories: internal and external interfaces. Internal interfaces are ones that appear within the project itself, while external ones appear between the project and external entities (Stretton, 2016). Examples of internal interfaces include time, geographic, technical, and social interfaces, concerning situations where work must be undertaken in a particular order, moved off-site, utilize specific technology, or include multiple work groups (Stretton, 2016). Other internal interfaces include change of responsibility interfaces, where a task is transferred between two managers, information interfaces where information from one task must be transferred to another, and physical interfaces, where physical objects must be moved to accomplish tasks (Stretton, 2016). External interfaces, meanwhile, concern interfaces with the government, media, competitors, external suppliers as well as external stakeholders in general (Stretton, 2016). Furthermore, external interfaces extend to other disciplines, and cultural interfaces, particularly in cases of international projects (Stretton, 2016b). These definitions are true for the majority of projects and organizations; however, interfaces that are normally external may be internal.
Interface Examples
An organizational interface is an interface between different organizational units. These units have functional or geographic boundaries and can be both internal and external (Liu, Liang, & Shi, 2018; Keerthanaa & Shanmugapriya, 2017). Generally, organizational interfaces describe the interfaces between a general contractor and subcontractors, suppliers, and owners in a construction project (Eray, Sanchez, & Haas, 2019). A more specific example where both of these boundaries are relevant is the case of research and development (R&D) units in multinational corporations (Liu, Liang, & Shi, 2018).
Interfaces can also be described as tangible, or hard, and intangible, or soft. Tangible interfaces are interfaces between specific technical objects and, therefore, they can be clearly defined. Soft, or intangible, interfaces are not physical, which makes them more challenging to define, describe, and document. A significant portion of intangible interfaces are organizational, existing between different organizational units. Such interfaces can exist between contractors, suppliers and customers.
A technical interface is one where a technological component is involved. Such interfaces are can be physical devices at the boundaries of two areas of responsibility, such as doors (Chua & Godinot, 2006). However, they can also relate to interfaces where the communication is largely automatic, such as in communication systems or between databases (Chua & Godinot, 2006). Finally, parts of a project that primarily consist of primarily technical or digital systems, such as signaling systems or power supplies, are also technical interfaces (Chua & Godinot, 2006). As such, technical interfaces possess significant importance in modern project management.
Critical Interfaces and the Interface Manager’s Role
Interfaces can be graded by their importance to the project and the consequences of issues occurring to them. Critical interfaces are ones that may result in the most significant consequences to the project if they are not managed correctly (Kelly & Berger, 2006). Therefore, when planning a project’s interfaces, it is crucial to identify such interfaces and ensure that they are designed and documented to be as resistant to problems and resilient as possible. This is a major part of a project interface manager’s role. A project interface manager is a specialist in interface management, whose responsibilities include identifying interfaces in a project and designing new ones as necessary. Furthermore, an interface manager is responsible for monitoring existing interfaces and adapting them to adapt to changes in the project’s needs or its environment.
Change Management
Changes in projects can happen for a variety of reasons, which may not be under the project manager’s control. Some of these changes are related to changes in a project’s environment. For example, a crucial stakeholder can change his or her mind regarding the project (Harrin, 2016). Depending on how significant this stakeholder is, the changes required can be minor or critical in scope. Potentially related to this, the project’s funding can change, necessitating a redesign of its tasks, units, or interfaces. Similarly, a project’s sponsorship can change, causing similar changes to the project’s funding or priorities (Harrin, 2016). Business strategy is always subject to change, due to internal or external factors such as changes due to competition or shifts in the business environment (Harrin, 2016). These changes are primarily internal to the organization or the project.
On a broader scale, changes in legislation or regulations can prompt changes to a project (Harrin, 2016). Changes in available technology can mean a project needs to pivot to adapt to new opportunities or abandon obsolete technology (Harrin, 2016). Finally, a project can run out of resources, such as time, money, or specialists; whether this happens due to poor initial planning, mismanagement, or external forces, this inevitably requires reducing the project’s scope (Harrin, 2016). While these changes can be predicted or prevented to some extent, a project manager should be able to pivot his or her available resources to prevent negative consequences to the project.
Project managers have a variety of tools at their disposal to effectively manage change. However, preparing for the eventuality of change and monitoring changes as they occur are necessary components of any strategy. A solid project management plan is necessary, which must be updated often for the project’s performance and any changes and issues that occur (Project Management Institute, 2017). This allows the project manager to better analyse the situation, understanding what causes changes in a particular project, how each change affects the project, and whether there are any relationship between changes. In turn, this improves his or her ability to predict changes and take action to prevent it or reduce its negative effects.
One specific aspect of change management is change management strategy or change management plan. This document outlines an expected change and the steps necessary to take in response to this change or, if the change is planned, to enact it (Turner, 2019). Explicitly describing the change in terms of objectives, measurable operational definitions, and clearly describing the dependencies, risks, expected benefits and outcomes can allow the project team to operate with particular goals and steps in mind, making the change process more predictable and easier to analyse (Turner, 2019). As such, maintaining a change management plan is a critical component of change management.
Furthermore, general strategies can to be followed that improve a project’s flexibility, resistance to change, and resilience. These strategies include constantly monitoring the project’s performance, timing, and detecting any issues (Arefazar et al., 2019). Detecting issues in these fields early allows one to initiate change early to improve a project’s performance while saving resources and preventing negative consequences of unforeseen change. Additionally, communication between the project’s work units and stakeholders must be facilitated to ensure that any change-related instructions are formulated, conveyed, and followed quickly and effectively. This aspect of change management is closely related to interface management.
Project Delays
Delays in projects can be inevitable, but they are always associated with negative outcomes and reduced performance. As such, a project manager should be able to predict them and avoid the conditions that are likely to cause them. Some changes are related to interfaces and resource management, such as those occurring with suppliers. For instance, a critical supplier can cause a significant delay by failing to deliver on time (Project Management Institute [PMI], 2017). The time it will take to wait for the delivery or source a new supplier can cause the project significant losses or, if the supplier is both critical and irreplaceable, force it to be cancelled entirely. Similar errors on a supplier’s part can include delivering low-quality material or mishandling the delivery. Because of this, external interfaces with the project’s suppliers can be a major vulnerability and need to be managed effectively.
Some delays can be caused by poor planning or execution of a project. Such causes include financial issues, general management problems, issues with clients, issues with regulations and legislation (Ageykum-Menash & Knight, 2017). These issues can also be the consequences of external changes, such as regulatory changes, business strategy changes due to competition, or similar. Although they can be predicted, it is not always possible to prevent such changes.
Finally, completely external natural factors can cause delays in projects. Construction projects, for instance, can be delayed by adverse weather conditions that render on-site work impossible (Ageykum-Menash & Knight, 2017). Some natural conditions specific to the construction industry include ground condition, which can significantly affect a project (Ageykum-Menash & Knight, 2017). Some industries are more prone to such causes for delays than others; furthermore, due to their unpredictability, one should always plan for these delays.
Concluding Remarks
In effective project management, all aspects of the management must come together to ensure a project’s performance, efficiency, and timeliness. Interface management is a critical part of larger projects, whereas effective change management is necessary in any project, especially ones with an extended duration. Delays due to various reasons can further hamper a project. To compensate for any issues arising in a project, communication and forward planning are critical.
References
AGYEKUM-MENSAH, G., & KNIGHT, a. D. (2017). “The Professionals’ Perspective on the Causes of Project Delay in the Construction Industry” Engineering, Construction and Architectural Management, 24(5), pp. 828-841.
BIBLE, M., & BIVINS, s. (2018). Project interface management: reducing risk on major projects. Plantation, FL: J. Ross Publishing.
CHUA, D. K., & GODINOT, M. (2006). “Use of a WBS Matrix to Improve Interface Management in Projects” Journal of Construction Engineering and Management 132 (1), pp. 67-79.
ERAY, E., SANCHEZ, B., & HAAS, C. (2019). “Usage of Interface Management System in Adaptive Reuse of Buildings” Buildings 9 (5), p. 105
HARRIN, E. (2020). 7 Causes of Project Change. Web.
KELLY, B., & BERGER, S. (2006). Interface management: Effective communication to improve process safety. Journal of Hazardous Materials, 130(3), 321–325. Web.
LIU, Y., LIANG, X., & SHI, Y. (2018). “Brokerage and Balance: Creating an Effective Organizational Interface for Product Modularization in Multinational R&D” Research Policy 47 (6), pp. 1133-1146.
Project Management Institute. (2017). A guide to the project management body of knowledge (6th ed.). Project Management Institute.
STRETTON, A. (2016). “Project Interfaces and Their Management” PM World Journal 5 (7).
AREFAZAR, Y., NAZARI, A., HAFEZI, M. R., & MAGHOOL, S. A. H. (2019). “Prioritizing Agile Project Management Strategies as a Change Management Tool in Construction Projects” International Journal of Construction Management, pp. 1-12.
Appendix 1
7 Causes of Project Change
You know that nice neat project schedule you created? The one that you’ve saved in a fancy graphical format and turned into a PDF for your stakeholders? I’ve got news for you: tomorrow it will be in the recycling bin because it will be out of date.
Project plans change daily as work gets done and you adjust what’s happening to meet the challenges of the tasks but sometimes we’re also hit with bigger changes.
Here are 7 causes of change on projects – things that will make you review that schedule again (and again).
Stakeholder Changes Their Mind
A stakeholder could change their mind at any point in the project. And they frequently do! If their new opinion relates to the format or quality of the output of the project then you’ll be making a change to incorporate their new ideas. Essentially, this is a change to requirements.
The earlier you can get these out of your stakeholders the less impact they will have on the project overall. While you are still at the requirements elicitation phase they can pretty much change their minds as often as they like. When you are into build, that’s when it is going to incur rework and an associated increase in cost and time to make any changes.
Regulatory Change
When new regulations or legislation is introduced this can result in a change to project scope or requirements. You need to make sure that your business remains compliant and legally allowed to trade. This could happen at any point in the project life cycle so the earlier you can be aware of upcoming changes the better, as generally you will get some notice before new rules come into effect.
A legislative or regulatory change might even make your project redundant so you could be faced with closing it down.
Poorly Defined Requirements
I’m sure your projects never have poorly defined requirements, do they? Well, over here in the real world we face that challenge all the time.
If your requirements are poorly set out during the definition phase of your project then it’s going to impact you later when you move into the development and build stages.
As the uncertainty around requirements is probed by the team doing the work, assumptions will be challenges and this is likely to result in a change to scope as you define what your key users actually want.
Change in Sponsorship
A new sponsor brings new ideas. Whether your project is changed voluntarily because it’s of benefit to the project or replaced through resignation or redundancy, whoever is now in charge will have their own approaches for doing things.
A different leader isn’t always going to mean project changes, but it is something you should watch out for. And you’ll have to put your managing up skills to the test as you bring them up to speed with what’s happening on the project.
Business Strategy Change
A change in direction could result in changes to the scope or requirements on your project. this could happen at any point in the project: business strategies are often under constant review for competitive threats, even if in principle the organisation has published a three- or five-year strategic plan.
Ultimately, a change to the strategy could result in a major change: your project being closed down prematurely. This could happen if the project no longer supports the strategic direction and objectives of the company but more often you’ll be expected to pivot the work to align with a change in direction.
Updated Technology
We all know that technology moves on. During a long project, or a programme of work, you may find that the tech solutions you put in place at the beginning are out of date by the planned end. I’ve worked on a project like this: cutting edge tech was welcomed by the teams who got it at the beginning of the roll out but 18 months later when we were still installing it in other places those first teams were clambering for the upgrades and new features.
Technical updates can introduce changes to your project. in the case of my project, we shifted our approach to deploy the latest version of the software for the teams who came later in the deployment schedule and then went back and upgraded the ones who had it first. This resulted in a change to scope and it made the overall project longer as there was effectively rework to do. But we all agreed it was a sensible approach and one that we had seen coming.
Not Enough Resources
If you don’t have enough people (or money, or equipment) to do everything you want to then you might be forced to change the project to get by. For example, if you’re building an estate of new houses and you run out of time or money towards the end, you might finish off the last few to a lower spec than the first ones. Top of the range taps? No thanks, just the basic ones will do fine.
Of course, if you end up compromising on quality then you’ll have to adjust the end price accordingly. In this example, you couldn’t sell the last house for the same price as the first one as the finish would be different. This is where a change can have potentially far-reaching effects: you should be looking forward and factoring in all of the impacts so that you can make the right decision about whether to go ahead with the change.
Bonus: Bugs and Defects
A defect is where a particular deliverable has failed to meet the specification set out. In software projects they are often called bugs; in building this could be your snagging list. If you’ve delivered something, or are on your way to delivering something that won’t meet your quality targets, you might have to change something somewhere along the line so that the next deliverables you do are of the right quality.
These causes of change may well cause you to go back to that schedule and wish you hadn’t spent so much time making a beautiful summary in a graphics package, because now you are going to have to do it again…
Watch out for them, anticipate where you can and work through a change management process so that you can control and monitor changes to the project as you move through the life cycle.