Abstract
Among the recipes to increase the probability of project success, the contribution of the project organization is so subtle that it could be neglected. In this paper the main sources of objectives misalignment originated in the project organization are described as risks, to decide the most suitable strategy to turn troublesome circumstances into positive contribution from the main players. The first part of the paper addresses general definitions of organization, teams and project objectives, as an introduction to the large section on root causes of misalignment; quite a few different scenarios are described and the positive and negative impacts are analyzed; this description paves the way to the final part in which possible solutions are recommended to either align the organization or cope with it and mitigate the negative impacts.
Introduction
By following the precepts of methodological theories, you should be more confident that the project you’re managing is moving into the right direction towards the stated goals. Unless you hope for favourable fate, these rules are necessary for project success, but might not be sufficient. Rules refer to hard factors, which have a higher impact on the project when combined with the soft factors.
Dealing with the soft factors leads into the human side of the project. Although the project objectives are clearly stated and unambiguous, in terms of scope, time, cost and quality, these objectives have to be accomplished by people playing different roles in the project. If these people are not aligned toward the common goal, not even the full set of rules is enough.
Analysing the project organization to identify sources of misalignment can be run similarly as risk identification. There can be hidden agendas or other conflicting objectives among the business units or individual people involved in the project. The degree of impact from these sources of misalignment should be analysed and prioritized and a strategy should be planned for from fully fixing the issue (Avoid) down to living with it if few or no changes are allowed (Mitigate and Accept).
Last but not least, some sources of misalignment could have a positive impact on the project as they provide different perspectives. Therefore look for opportunities, not just threats!
General definitions
Organizational chart
The organizational chart is one of the first deliverable of a project. It is defined before the project starts (e.g. in pre-sales talks between a buyer and a supplier) and is included in contractual documentation.
Since project inception all stakeholders should be aware of who’s playing the Sponsor roles, who’s in charge of the project and is ultimately responsible for it (the Project Manager) and who are the business units mainly involved. The roles and mutual responsibilities are clearly defined from day one. Some refinements are allowed, for instance individual names in the lower level of the hierarchy can be later stated or replaced.
Generally speaking both the buyer and the supplier appoint a sponsor and a project manager, since responsibilities can be assigned on each party. An example of a simple organizational chart is depicted in Exhibit 1. On each side a couple of Team Leaders are responsible for the business and for the technical side of the project respectfully. The Team leaders in both organizations can belong to different business units.
Technical responsibilities can be on Buyer Technical Leader (e.g. provide the infrastructure) or on Supplier Technical Leader (e.g. setup the infrastructure).
In medium to large projects there can be several boxes below the Project Manager.
Exhibit 1 – Organization chart sample
Team and Project Objectives
Regardless of which box they belong to, all project team members should focus on the project objectives, as in the well known team’s definition (Katzenbach & Smith, 1994, p. 45):
A team is a small group of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.
This definition refers to “small group of people”. Considering all project team members as a unique team would be utopian; however trying to share the same objectives as much as possible is beneficial.
The concept of team should not be limited to single supplier team or functionals vs techies. The organization chart can be regarded as a team of boxes, or a team of teams, which share the same high level objectives of the project.
Sharing the main (or high level) objectives of a project is a powerful way to foster a partnership approach between all players in the project, so that all people are aligned, while keeping their local (or low level) objectives in mind.
The Team concept is different from a mere group of people working together, as goals and approach are shared.
There is one factor not to forget: the organizational structure does influence how projects are managed (PMI, 2008, p. 28). The more the sponsors and the project managers can influence how objectives are shared, the higher chance the organizational structure will support the team approach.
Scenarios of misalignment
The sources of objectives misalignment can be numerous. In the following paragraphs a few significant and most frequent are described.
Individual needs Vs Team needs
Robbins & Finley (2000) suggest that teaming is a social need (p. 25). However they warn that “a conflict exists between individual team members’ goals and the overarching goal of the team itself” (p. 29) and that social and personal needs prevail on team needs. That brings about personal or hidden agendas.
Detecting this mismatch is difficult and the impact might be as high as the level of involvement of individuals in the project. It should be identified not later than the Storming stage of team development (PMI, 2008, p. 233).
This conflict is similar to the objectives mismatch from different business units involved in a project, which is described below.
Project vs Operations
The end users dilemma
A project aims to provide a product, service or results that in the long term should improve the ongoing operations activities. From the perspective of the end users, there would be a transition from a stable status to a new hopefully stable status.
End users are rarely involved when the Project Charter or the Project Management Plan is outlined. Some representatives are invited to project kick-off and are said that the new solution will improve their operations and reduce their workload. In some cases the project champion might even say that business processes will not change at all (“It is only a technology improvement!”).
Then the project starts and the end users disappear, only to be summoned at the user acceptance test before Go-Live, when they find out that the new solution is there and they are in charge of saying it is ok. Sometimes they are not even involved during the project life-cycle and are handed over the new system after Go-Live.
A project is a change for the people involved in daily operations; those in the lower levels of the organization are more likely to miss the long term strategic view and focus only on the short term burden. Unsurprisingly the final phase of the project is when the resistance to change occurs. The later end user involvement the higher probability and more negative impact on the project; moreover, if this risk is not anticipated, there is almost no time for risk response.
Implementation Vs Maintenance
A conflict similar to the end user dilemma may arise from another Project-Vs-Operations scenario.
The client and the supplier cooperatively work together with small frictions, playing as a perfect team. Then after Go-Live the supplier is engaged in the Production Support, with a different team. Another client team is appointed to provide first level support to end users. On both client and supplier side, at project closure the new system is handed over from the implementation team to the maintenance team. In Exhibit 2 this transition is downward.
Exhibit 2 – Implementation Vs Maintenance cooperation
The conflict arises when the new solution is perceived as not bullet-proof (it may be perfect, but perception drives people actions). The two maintenance teams would prefer the project to delay in order to reduce the likelihood of serious defects, while the two implementation teams aims to complete the project in time and on budget.
The two maintenance teams are prone to cooperate against the two implementation teams. Therefore paradoxically the two “vertical” cooperating teams of colleagues (Client on the left and Supplier on the right) are superseded by two new “horizontal” cooperating teams.
This scenario can have lower probability and less negative impact than the previous end user dilemma, but the risk might be identified late as well.
Business units with conflicting objectives
The two previous cases are examples of a more generic scenario in which business units with conflicting or prevailing objectives are involved in a project. “Prevailing” here means that the individual objectives at the business units (low) level drives actions more than the objectives at the project (high) level.
In the case of an organization shaped by a functional structure, in which projects are managed by staff belonging to a unique business unit, the risk of conflict is low. However large projects typically involve staff from different business units (or “silos”) even in functional structure based organization. A matrix or projectized structure may help reducing the likelihood and the negative impact when different business units have different objectives, if the project authority enforces the shared objectives (but negative feelings remain).
The effect from risk response strategy can be limited as the faithfulness to business units is deeply rooted.
Different business units may have also different perspectives, which are not always negative. They can be a source of enrichment for the project, i.e. opportunities (positive effect) to be exploited or enhanced.
Multi-suppliers contract
Companies in Public Administration sector frequently rely on a multi-supplier approach in awarding contract, in order to avoid dependence on a single provider and to increase their negotiation power; lower prices can be bargained even with many suppliers if framework agreements are in place.
There are two further options to split the work among different suppliers: independent projects or different phases of the same project. In the latter case project governance is paramount and might be performed by the client or by an additional supplier. Whoever is in charge of governance, can follow the Divide & Conquer approach in managing the suppliers.
Exhibit 3 – Different phases to different suppliers
In the example shown in Exhibit 3 conflicts are likely to arise. Supplier B could make an innuendo that the analysis is incomplete; a similar friction will oppose suppliers B and C when it’s test time.
Whether it is about weak governance or the intentional Divide & Conquer approach, the organization misalignment is very likely.
Different contract types
Another source of misalignment with multiple suppliers is the case of different contract types to different suppliers. Let’s assume for instance that the supplier X is already awarded a cost-reimbursable contract before the scope can be detailed (e.g. long term partnership or teaming agreements). Then the client awards a Fixed Price contract to supplier Y with a clear Statement of Work, while using the supplier X for some activities in the same project. The objective of supplier Y is to complete the work on schedule without incurring in additional costs; the more the project lasts, the more costs it is likely to incur. Conversely the supplier X is willing to be involved as long as possible in the project, to allocate its resources. There is a clear mismatch on time objectives between the two suppliers, with the client being the arbiter in between. The impact on time and budget can be high.
Consider, as an example, the construction of a power plant with the prime contractor exploiting local workforce from other sub-contractors. If the latter are employed on a Cost-reimbursable contract without incentive fee they are less interested in the project being on schedule.
Poor or missing governance
In the previous cases a strong lead from sponsor and management may overcome the issues coming from objectives misalignment.
However in large companies the organization chart is usually more complex, especially in the upmost part of the project hierarchy. The leadership might be shared among many players or the chief-commander might have to daily negotiate with resources coming from different departments. More players will require more communications channels (PMI, 2008, p. 253).
Even if the context is non-troublesome, weak or unclear governance will have a strongly negative effect on the project, unless the project team shows self-organized attitude toward shared objectives (the lowest level in maturity models; counting on self-organization is close to throwing dice).
Irrational Organization Chart
Project governance can be weakened by an organizational structure with weird logic in it. Three examples are:
Intertwined reporting lines in the chart
Mr Adams of business unit A reports to a Team Leader of business unit B, while Mr Black of business unit B reports to a Team leader belonging to business unit A. There are fair chances that faithfulness at business unit level will make reporting lines and responsibilities ineffective.
Duplicated roles in the chart
Mr Smith is playing the role of Project Manager, while playing the SME role under one of his Team Leader who belongs to a different business unit. Besides the possible overload for Mr Smith, his roles and responsibilities might be mixed up when he is wearing simultaneously different hats.
Chart Vs Real roles
Mr Green is appointed as the Project Manager, but Mr White is actually playing this role. They belong to different business units.
Ambiguous scope
Not well defined scope is a typical source of project failure. Most activities described in A Guide to the Project Management Body of Knowledge (PMBOK Guide®) (PMI, 2008) are influenced by the collection of requirements and the subsequent definition of scope at the beginning of Planning. Inputs to these activities are the Project Charter and the Stakeholder Register in the Initiating Process Group. Therefore missing to clarify the scope of the project means ignoring the needs of the stakeholders and their expectations. Since these needs are linked to their objectives, the definition of the scope is the first opportunity to verify and align the objectives of the main players in the organization chart.
A well defined scope will not assure the objectives alignment, as some individual objectives might be hidden or not truly stated. Small creaks in the scope definition can be exploited by players not aligned with project objectives (see other paragraphs above).
However the effort in these activities will reduce the risk that misalignment happens. Moreover the earlier you act in preventing the risk the lower probability and less negative impact you will experience later in the project life cycle.
In Public Administration contracts the scope might be vaguely mentioned, when the contract is about specialist services provided in a certain business area or technology. In this case details of each work are agreed from time to time, as the needs require, as small Fixed Price tasks.
In Cost-reimbursable contracts the definition of project scope is important too.
Building an effective organization
Some recommendations to address misalignment are already suggested in descriptions above. In following paragraphs more suggestions are given.
The scenarios described share some common features, can overlap and synergize each other. Recommendations given below are either applicable for all sources of objectives misalignment or are specifically targeted for one or more risks.
It’s almost always late to fix
As for all risk response strategies, the earlier you plan and act the most benefit you get, both to increase positive impacts from opportunities or to reduce negative impacts from likely issues. This is especially true since the organization chart and project objectives are defined in the early stage of the project.
Any action to fix an inadequate organization chart or to strengthen governance or to plan early involvement of end users and maintenance team should be planned for and played in advance, the way risks are handled… Always look for ticking time bombs!
This should not prevent to plan and act during the project life cycle too, as some risks might be identified later. If, for instance, the scope has some ambiguities, it’s never too late to clarify it.
Communicate, communicate, communicate
In the Communication Knowledge Area the process “Manage Stakeholder expectations” (PMI, 2008, p. 261) is apparently simple. Fed by other Communications processes, its outputs are mainly updates to other documents. But the effect of this action is paramount. While other processes in the same knowledge area provide periodically tangible reports on project status, this process aims to address issues with stakeholders “as they occur” (and possibly also preventing occurrence).
Conflicting objectives might be only apparent if one team member makes the wrong assumption on the aim of other team members; “We are just different enough to create misunderstanding” (Robbins & Finley, 2000, p. 64). Models of communications show how messages are transformed (PMI, 2008, p. 255). In cross-functional teams different language can build barriers.
Communications undermine misunderstandings and help sharing a common language. Conflict management includes communications as a powerful technique to negotiate, ease, and finally come to an agreement. Remember that if there are real conflicts, there are opportunities too.
Finally objectives are linked to expectations. If you manage expectations, you’re more likely aware of objectives within the project organization. As far as expectations are regarded, end users and Post Go-Live support team are key stakeholders not to be neglected.
Once and for all a good recipe is: Communicate, communicate, communicate… and then communicate again (without indulging in spamming).
Exploit complementary objectives
If different objectives exist within the organization, whatever is their root cause, aiming to a Win-Win solution is always a good strategy; or, if individual objectives prevail on team objectives, teamwork benefits from balancing team needs and individual needs (Robbins & Finley, 2000, p. 31).
Different perspectives help and nurture creativity in problem solution. End users who are asked to use the new solution in their daily operations are a rich source of fresh ideas. Therefore by their early involvement the project can benefit by both preventing misalignments and getting input for improvement.
Objectives, although different, might be complementary and not necessarily in conflict. Planning for additional testing to smooth resistance to change could detect more defects before the new solution is in production, thus providing additional preventive quality control.
Soft skills
As organization is about humans, almost all soft skills come in handy to manage the risks and opportunities described above. Some of them are worth mentioning explicitly:
Listen – Communications is bidirectional and listening is more important than talking (if you’re in a meeting with 3 people, you are on average listening twice as much time as talking, not to mention that you might be willing to listen yourself talking).
Be patient – Dealing with different objectives requires time for negotiation.
Influence – Leadership is perhaps the most renowned soft skill. It is about having charisma and being influential.
Ally – Different objectives and perspectives are not from just two positions. There can be several different ones. Collaborating with other parties is more supportive than fighting against the party which opposes you most.
Be firm but flexible – A good balance should be kept between stubbornly adhering to objective facts or documentation and looking for changes and adaptation. Changes are always opportunities to catch, if they are worthwhile.
How to live with a badly designed organization
Not all risks can be fully avoided nor all opportunities can be fully exploited. As a matter of fact some issues cannot be entirely solved, but you have to live with it. There might be political reasons and tradeoffs behind a weird organization chart (As for soft skills, managing a project is not about application of hard precise rules only). Thus, if need be, the risk response strategy is likely only limited to mitigate/enhance or accept (PMI, 2008, p.303-305).
The “Accept” option is actually more than waiting for risks or opportunities to happen. By realizing that there are no shared objectives, the best solution is to behave accordingly. The project team is not a team, but a group, and therefore it should be managed as a group, i.e. a set of people working together. It will be not easy, but less utopia-based.
“Mitigate/Enhance” is a more proactive approach and should be followed if circumstances allow. If end users are biased against the new system, they should be carefully managed so that resistance to change is reduced and that an extreme reaction (sabotage) is unlikely. End user champions can be single out. Managing frictions implies fully documenting all cases which can trigger arguments. It is certainly costly, as you may be for example requested to minute all meetings. As for communications, cost benefit analysis will help deciding which degree of recording is the most appropriate.
Any opportunity to better clarify an ambiguous scope should be pursued as well.
Terminating the project happens… and sometimes it might even be a positive event, rather than a project which scrapes a living until the budget burns out.
In most projects with objectives misalignment, however, there are fair chances to improve a difficult position; even a partial move towards alignment is better than doing nothing and waiting for good fate. Surviving a troublesome project and reaching project objectives is fully rewarding.
