Organization Development in Projects

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!

Organization Development in projects - continued

Why not use organization development (OD) approaches to support projects? That was the question of my initial text on OD elements in projects in which I’ve touched on a required compass, a way of working, enablement of individuals and teams, decision making rules and information flows.

In this post, I will share some thoughts on Culture Development and Personal Development. When I started thinking about it, these were aspects of OD, which I thought would not be easily transferrable from line organizations to projects.

But when giving it a bit more consideration, this initial evaluation might not even be true. Hence, you might want to see this as a continuation of my last text.

Let's dive into it:

Culture Development

In projects you barely get to actively shape a culture. When a project is pre-dominantly run in a fixed organization huge parts of the organization’s culture will also show in the project culture. On top the project culture will be influenced by the cultures other members of the project organization bring into it. Visible stakeholders will act as role models influencing the project culture – independent of whether they intend to do so. As do external project members, which is why a cultural fit might be an underestimated criterion during selection of project partners.

Experience shows, that it is possible to positively influence a project culture as external consultants – even if you do not have the official mandate to develop culture. I have witnessed multiple times how bpExperts’ open-minded, action-oriented, and communication-based culture has washed into project organizations, influencing other actors.

On top of role models, small activities can help to formalize parts of a project culture. For example, project team workshops on ground rules or on sharing and agreeing on preferred ways of communication and collaboration will be helpful.

For ground rules, communication and collaboration alignments the company’s values could be a starting point. Why not discuss how the values would reflect in daily project work and which rules to be deducted from that? That would anchor the value in the project work and would probably allow internal project members to feel “at home”. It might improve their confidence in otherwise unknown project environments.

Personal Development

The limited time horizon and the tremendous pressure to deliver results are certainly playing against extensive personal development as part of projects. In addition, leading roles in projects typically do not have development of people set as their priority. I would even bet, that they do not even see it as their responsibility at all.

Nonetheless, there is a link you can't deny: Many line managers use the participation in projects as development measures for their employees.

Projects provide the opportunity to work in a different role, to pick-up a lot of new knowledge, to build a network in the company, to interact with a variety of people with different backgrounds, to learn about yourself and your ability to cope with time pressure and often uncertainty. So much development potential!

It is great, that line managers try to utilize projects for personal development. However, it won’t work without the employees. Unfortunately, from my experience, the employees do not really feel responsible for their own development or do not see, that projects provide them the chance for development.

To maximize the effect making the development potentials more explicit can be helpful. It can be as easy as sitting with your superior, mentor, coach or colleague before a project reflecting on what you could and want to learn in a specific project. Occasionally review it and remind yourself on your individual targets.

OD in projects and change facilitation

OD elements in projects naturally focus on the involved individuals in the project organization. Saying this, it is obvious, how OD in projects is different from classic change management. In classic change management, the focus lies on the affected individuals.

My thoughts on OD in projects are directed towards taking care of the anyways actively involved stakeholders. Enabling and empowering them will also help with the Change Facilitation, though. The project team is a key multiplier due to their many touchpoints with affected individuals throughout the project duration.

bpExperts has developed a Business Readiness concept integrated into a process-driven ERP implementation approach. This concept efficiently combines both project organization development and change facilitation in a holistic way.

Looking forward to hear about your ideas and experiences on Organization Development in projects!

As you might have noted, I’ve switched from using “change management” to “change facilitation” in the last paragraph. A decisive difference for several reasons… I might share some thoughts another time.

Organization development in projects – roles and responsibilities deep dive

Challenges around distributed responsibilities can be found in many different environments - being it line or project organizations each with hierarchical settings or settings with little to no formal hierarchy. The less formal an organization is or the more dynamic the environment, the more important is clarity on responsibilities to stay efficient.

This efficiency comes from avoiding irritations due to overlapping responsibilities of roles as much as from avoiding gaps in between responsibilities of roles. And honestly, it starts with clarity on who is having which role and who is going to take which decisions. To define the decision-making processes and responsibilities is one of the crucial parts in complex environments with highly independent teams working together.

Decision-making can be as easy as: “Everyone decides on their own but needs to align with everyone who is affected by the decision.” Nice and simple rule. Very efficient. Very lean. Unfortunately, in dynamic environments it is terribly difficult to just know “who is going to be affected” or “who feels affected”.

The same decision-need raised to different people will most probably end in different decisions. Why? The individual confronted with the decision-need, might involve the obviously affected stakeholders. So far so good. But for alignment they will turn to their trusted individual network. The biggest challenge from this is not necessarily the different result. But, how to communicate taken decisions in a way that ensures all relevant stakeholders learn about it? In addition, how to learn from mistakes?

Yet another difficulty - if responsibilities around decisions are not clearly defined - is the cluster risk. Decisions tend to end up on the desks of persons with special gravity. These are often people either confident or bold enough to take decisions with less people involved. Or it is people high up in the hierarchy. By the way, in organizations on their way to self-organization even former hierarchies will do the trick.

Both mentioned mechanisms can be fine, if it is a conscious decision. But many times, the idea of more self-organization, fast and decentralized decision-making is rather one of delegation. The target is to take decisions where the actual information and expertise is anyways available. Falling back to these gravity persons most often contradicts this intention.

What are the options?

Defining and agreeing on roles and how these collaborate would be my immediate answer. It works very well both in line and project organizations.

Once the overall direction - the compass - is clear, role definitions can help a great deal in clarity on responsibilities including empowerment on decision-making. In classical line organizations you will typically find standard roles which very much sound alike across different companies. There are accountants, customer service representatives, planners, production foremen - you name it. As soon as you start talking about the detailed distribution of responsibilities these roles will show tremendous differences. Do not assume roles are congruent just because the name of the role seems to be clear. And do not trust in it just because everybody confirms that they know what their role is about. You can save yourself (and all involved) a lot of frustration by spending time on clarifying the roles anyways.

Role clarifications and dimensions of responsibility

So, be persistent! Overcome the initial push-back and individually talk to involved persons about their roles. Later, you can summarize the insights and raise clarification needs. You could think of different structures both for the conversations as well as for the documentation of roles.

In projects, I tend to go for clarification of the “R&A” of “RACI” and have a one-page summary of each role. Leaving out the “C&I” only works, if the project meeting structures ensure that the entire team is kept informed and bring in their perspectives via this channel. But for me, that is anyways part of sound project management. To mitigate the risk of missing out on that, our one-page summary includes a section on which other roles the respective role is collaborating with, is supporting or receives support from. In this way, the interconnection of different roles can be made transparent. For the “R&A” part, we like to set up a list of topics per work package or phase of the project. This list clearly states the role’s responsibilities and accountabilities.

In ERP projects we have good experience in accelerating the role clarification by starting off with “template roles” (e.g. for integration manager or test manager). Hopefully 90% should already fit and the specifics of the project can be added as required. Template roles could be derived from former projects in similar environments, or you fall back on standard project management frameworks, like PMI, Prince2, Scrum.

This is how such a one-pager could look like. Nothing fancy, but it does the job:

Outside of projects, I really like the model of 4-dimensions of response-ability. I got to know it during my organizational development and change management qualification at the systemic training institutes of ISB Wiesloch. Using this model is really helpful to nail down the details of a specific role and clarify individual requirements of the person holding the role.

In a “conversation about response-ability” you touch base on 4 dimensions related to the individual and the team/organization:

Note: The model originally was designed to discuss individual responsibilities and to clarify the distribution of responsibilities between individuals. But we have successfully used it for general clarification of roles.

Loose ends?

What are your thoughts on using the 4 dimensions of responsibility in project teams? Or maybe during project staffing or hiring?

With having the single roles clarified, how can you achieve a comprehensive overview on their interdependencies?

Do you have experiences on how to combine it with agile task management?

Do you have experience in using delegation poker in projects to negotiate responsibilities? Maybe there are situations where this can work?

Summing it up, by clarifying the roles you ensure that the project approach is understood by everyone incl. their individual contributions. In line organizations it helps to ensure that everybody has understood the processes they are involved in.

Clarity on roles and responsibilities is key for efficient collaboration of teams. Due to this, it is an essential part of organizational development independent from the environment.

Feel free to comment and share your thoughts.

Change facilitation – stakeholder group specific change journeys

I have never believed in "one-size-fits-all" change management approaches. Many initiatives have tried and failed. Listening to voices on reasons for failure of large IT-related transformation initiatives, such as ERP implementations, will tell you that change management topics are key success factors. Nonetheless, companies seem to not be willing or not able to learn from other's and their own experiences.

Stakeholder group specific approach

My strong belief is to use stakeholder group specific approaches to allow for tailored information, involvement, and enablement activities. I am convinced about this, considering the different timing and information requirements of various stakeholder groups.

Just as one example, process owners in ERP initiatives will need to understand, accept and actively support the to-be situation much earlier than the end-users. Why?

Because process owners will need to be involved in decision making during design phase and might play an important change agent role during implementation phase.

In contrast, end users will need to understand the to-be situation during the final weeks before go-live and it is to be expected, that some will accept but never really actively support the to-be situation.

Typically, end-users will have some weeks of training plus some weeks of hypercare to reach this understanding and acceptance.

Process Owners, however, will need to get to the active support stage within a much shorter time.

Change Journeys

Defining stakeholder group specific change journeys can help to tailor fitting change facilitation activities.

The idea of change journey and to connect them to phases of process-driven Business Transformation projects, I've elaborated back in 2019 and 2020 together with Dr. Russell Gomersall. The similarity to Customer Journeys is not a coincidence.

Just like customers have touch points with a company, employees are having touchpoints with transformation initiatives.

Fig1. Defining touchpoints of the change journey and linking them to work packages of transformation projects (Customer Journey Map modeled with Signavio)

The idea is that each individual involved or affected by a transformation is somehow traveling along the change curve. The classic Kübler-Ross change curve consists of seven steps. However, using the curve not for individuals but rather stakeholder groups, we found it easier to use and explain when summarizing these steps into three stages: (1) become aware, (2) understand & accept and (3) actively support.

In the last stage of that journey, some will start actively supporting the transformation not just because they need to, but because they are convinced of the objectives and benefits.

Coming back to the Change Journey, you could ask yourself the following questions to start with:

• What should be the first "touchpoints", which make them aware?

• How do the next touch points need to be designed to give them the chance to understand?

• Can certain information, involvement or enablement activities increase the likelyhood for them to accept required changes?

• How can we create the opportunity for those who not just accept but actually support the changes to actively support the transformation?

Same as for Customer Journey Maps, you can design the stages of the Change Journey best by putting yourself into the shoes of the different stakeholder groups. Using personas could be a way to ease the switch of perspectives while trying to foresee:

• how certain touchpoints will be perceived,

• how these could be designed to address the needs and,

• whether additional touchpoints for specific stakeholder groups should be planned for.

Let's be honest: You will never satisfy every individual's need during a transformation. But, by planning the change journeys of various stakeholder groups and tailor them to their needs, you can get closer to it.

Looking forward to your thoughts and comments.

Unveiling the Power of Process Due Diligence: Unlocking Potential in Business Transformation and Mergers

In the dynamic landscape of business, two scenarios stand out as pivotal moments for any organisation: embarking on a journey of business transformation with an ERP focus and navigating the complexities of mergers. In both cases, the path to success is laden with challenges and uncertainties. However, there is a powerful tool capable of illuminating the way forward: Process Due Diligence.

Process Due Diligence is not merely a checklist to be ticked off before major organisational shifts; it's a strategic imperative that can drive informed decision-making, optimise operational efficiency, and unlock hidden synergies. Let's delve into two compelling use cases where Process Due Diligence plays a transformative role.

Business Transformation with an ERP Focus

Implementing an ERP system is akin to rewiring the nervous system of an organization. It promises streamlined processes, enhanced visibility, and improved decision-making. However, the journey is fraught with risks ranging from cost overruns to resistance from stakeholders. Here's where Process Due Diligence steps in as a guiding light. By meticulously analysing existing processes, identifying pain points, and aligning them with the capabilities of the chosen ERP solution, organisations can mitigate risks associated with the transformation undertaking and maximize ROI. Process Due Diligence provides a roadmap for seamless transition from old to new ways of working, ensuring that the transformation doesn't disrupt day-to-day operations but rather enhances them.

Mergers: Finding Synergies and Gaps

When two companies merge, it's not just a union of assets and resources; it's a convergence of cultures, ideologies and processes. Amidst the euphoria of consolidation, lies the challenge of harmonising disparate processes and extracting synergies while bridging gaps. Process Due Diligence  offers neutral ground for both entities to assess their respective methodologies objectively. This facilitates a smooth integration by fostering transparency, collaboration, and a shared vision for the future.

A major challenge in conducting Process Due Diligence  is that the input provided by the parties being assessed  (e.g. two companies undergoing a merger)  can vary considerable for instance  different taxonomy, granularity, and scope coverage. This makes the assessment very difficult and time consuming. Therefore we at bpExperts provide a normalised point of reference and a structure approach for conducting a Process Due Diligence.

The anchor points for conducting the assessment are Business drivers and Value drivers based on SCOR strategy framework, Operating Models and E2E scenarios, a functional process library, and capability maps.

As you embark on the transformative journey of business evolution, remember that you're not alone. bpExperts stands ready to support you through every phase of the Process Due Diligence journey. From meticulously analysing your current processes to identifying fits and gaps, designing harmonized processes, and embedding new processes and roles into your organization, we are your trusted partner every step of the way. But our commitment doesn't end there. 

We remain by your side to monitor performance, establish controls, and optimise processes continuously. With our expertise and dedication, we ensure that your organization not only adapts to change but thrives in it.