Have you ever wondered why there is a project "org.chart" but otherwise everyone is only talking about the project "team"? I did multiple times in the last couple of years. Especially, since project managers mostly concentrate on the project team and change managers concentrate on the affected employees. The project as an organization often times does not receive sufficient attention.
Project Type
Let’s first define the type of project I am referring to, because this is one of these topics where context matters. Let's think about larger projects with following characteristics:
30-40 core team members,
selection of experts on various subjects,
mix of internal and external resources,
working remotely or within on-site workshops,
sub-project leads to work self-reliant with their streams.
All involved will spend for many months at least a large part of their working day in the project. For the internals the parallel daily business on top of project work is a common challenge. This double strain is impacting their motivation, especially since their contribution to the project might not be entirely their choice.
ERP implementation projects could be an example for these kinds of projects.
From my perspective, it would be beneficial to really consider these projects as a temporary organization. So, why not use organization development approaches to support the project?
Helpful elements of OD in projects
To be successful companies and projects require:
a compass - The compass for a large project will typically be quite specific. We are talking about strategic targets, guardrails such as in scope vs. out of scope and a vision ("where to") on the situation after the successful project. Only a congruent "why” will allow you to take the project members aboard. Combining the "why" with the "where to" and adding important limitations will provide a lot of guidance to the project organization.
a way-of-working - In line organizations of corporations you will find documented processes, with standard operating procedures and work instructions. We, as bpExperts, know that very well :-) from many years of implementing Business Process Management solutions and BPM organizations with our customers. In projects you typically do not find the way of working documented although it is crucial to success. The general project approach and work-breakdown with sequence of activities would be comparable to detailed process descriptions in line organizations. Some procedures might be important enough to even sketch them out in a project handbook or project wiki. For example, the required collaboration with internal development teams and how to raise the requirements into their direction. Most important for the way-of-working are the roles and responsibilities. Clarity on roles and responsibilities is a key efficiency driver both for projects and line organizations as it is a key to the enablement of involved persons.
enablement of individuals and teams - Starting point for the enablement of individuals and teams are both above mentioned topics. Involved persons, require the compass and clarity on the way-of-working and their role in it. In a project setting an alignment on these topics should be mandatory during onboarding of project members. Kick-off meetings for projects but also for specific streams and work packages should always plan sufficient time for these clarifications. The importance in projects is higher than in line organizations due to higher fluctuation and due to more differences in culture brought in by externals.
rules on decision-making and escalation routes - Another topic connected to roles & responsibilities is the decision-making. Efficient decision-making is not just about the speed, but about the quality. A lot of fast decisions that have to be revoked again and again, will slow down the project and also risk the motivation of all involved. Hence, it is crucial to define a sound decision-making process for the project which includes required stakeholders without overloading it. Typically, you see steering boards to take a lot of decisions in projects. For ERP implementations, which are heavily impacting the business processes, a second decision body consisting of global process owners can be an option. Delegating process related decisions with a certain threshold with regards to project budget impact, would leave the steering board with the big-ticket decisions, e.g., impacting timeline.
some solution on information flow - Also common to both project and line organization, is the need to ensure information flow and capture knowledge. Well defined communication channels, that the recipients are aware of, are one part of this. Another part definitely is a meeting structure with the right sequence of meetings to allow the information to be cascaded as required. In projects with their faster pace, there might be a higher frequency of meetings. But in the end, the idea is the same. With regards to knowledge management, I would say, it starts with the very basics. You need some rules on where to store certain information and documents, which channels to use to make others aware. Many times, these rules are defined in corporate wide project management playbooks or in the specific project handbook. Long-term knowledge management approaches within projects are rather rare. However, a very important knowledge management aspect is always part of ERP implementations: Training. From train-the-trainer, via end-user trainings to the handover to support organizations, are all crucial to not lose the knowledge built during the project.
So what
Reflecting on above aspects the similarities of large projects and line organization in terms of need of organization development are obvious. I don't deny that most projects try to address these topics. From my perspective, however, most fall short on the scope; Not necessarily the scope of activities, but the scope of persons included and addressed by these. Focusing on the core project team only, is neglecting the rest of the project organization.
For a successful project, however, the entire project organization should be considered. This might require organization development approaches instead of team building efforts only.
Looking forward to your thoughts and comments!