Cultivating Efficiency and Trust: Unveiling the advantages of Project Management as a Service (PMaaS) over staff augmentation

In today's dynamic business landscape organisations are compelled to navigate complex projects and initiatives. Those seeking external support for managing their programs are presented with two options: Project Management as a Service (PMaaS)  and staff augmentation. When considering an organisational  culture rooted in trust and excellence, the choice becomes crucial. Let's look at why PMaaS emerges as the superior option.

At the core of PMaaS lies an offering that stresses reliability, integrity, and scalability to an organisation's projects and programs. Unlike staff augmentation, where all individual contractors must be assessed and assigned in isolation, assigning a PMaaS provider systematically builds on established standards of execution and steering, and thus consistent delivery. In doing so, PMaaS not only cultivates efficiency but also fosters trust with stakeholders.

PMaaS providers offer a structured and proven project management methodology that serves as a blueprint for success. With standardised processes and best practices in place, clients benefit from streamlined execution and reduced risk of project derailment. This methodology instills confidence in stakeholders, knowing that projects are managed with precision and accountability.

Another advantage of PMaaS is the depth of industry expertise it brings to the table. By partnering with seasoned professionals with extensive domain knowledge, clients gain invaluable insights and guidance tailored to their specific industry challenges. This expertise empowers organisations to navigate complexities effectively and make informed decisions, driving project success.

PMaaS have a strong incentive of sharing knowledge and best practices among resources reducing risks of individual availability and building a reliable team with hands-on experience across diverse projects and industries. Unlike staff augmentation, where turnover and inconsistency may pose obstacles, PMaaS teams offer stability and continuity.

PMaaS offers inherent scalability and flexibility to meet evolving business needs. Whether ramping up resources for a large-scale project or scaling down during quieter periods, PMaaS providers adapt to fluctuating demands with agility. This scalability ensures optimal resource utilisation and cost-efficiency, aligning project management efforts with strategic objectives.

In addition to simplified and more reliable sourcing, turning to a specialised  provider enables organisations to redirect internal resources towards core competencies and strategic initiatives. This focus enables companies to concentrate on driving innovation, enhancing customer experience, and gaining a competitive edge in the market, while leaving project management responsibilities in capable hands. In this regard,  PMaaS offers a distinct advantage over staff augmentation by ensuring that the work is entrusted to a cohesive team operating according to an aligned methodology. This cohesion and standardised approach contribute to smoother project execution and increased reliability, further solidifying the benefits of choosing PMaaS over traditional staff augmentation models.

bpExperts has a long track record of offering PMaaS, with a reliable team and an extensive network of project management and industry experts. We are committed to excellence and ensure that your projects are in capable hands, delivering results that exceed expectations.

Why system quality starts with business requirements quality

Imagine walking into a large sports equipment store, telling the clerk you'd need some sports shoes. You can expect that this level of 'requirement' will not even get you to the right part of the store. Even asking more specifically for running shoes will only take you to a vast set of shelves with models ranging from sprinting spikes to cross-country trail running shoes. It is obvious that formulating specific requirements here is fundamental for being served well. Obviously, an experienced clerk will support you in formulating and refining your requirements by asking the right questions, and having you try on certain models. In the end you will be able to take an educated decision if the offer meets your needs and taste, and budget.

This is the happy path of requirements engineering. But imagine you are yourself uncertain of what you need or exaggerate on your current skill or ambition. In this case you may well end up with shoes of perfect quality but not matching your actual need at all. Likely a waste of money and not fun to run in.

You wonder why formulating and capturing high quality requirements is neglected so often in business transformation projects, especially those involving IT system implementations.

Waterfall and agile frameworks have the tool set to break down high-level user demands into more and more detailed pieces amenable for development and testing. In either case, accurately capturing the user or business need is the pivotal starting point. However, working top down from a set of starting requirements bears the risk of missing out on critical (starting) requirements or insufficient context.

Especially for complex systems, we at bpExperts GmbH believe that a process-centric approach to requirements engineering – founded on high quality process documentation – is the most robust and sustainable to address the concern above. IT systems are meant to support business processes following strategic and operative objectives. Process-centricity promotes and enforces this ensuring that the needs and expectations of all stakeholders are met, leading to higher satisfaction.

Effective Implementation

The clear association of requirements with the supported business process and objectives enables prioritization and focus on the most value-adding features and capabilities. With this it will be easier to formulate a robust, value-oriented and therefore future-proof implementation strategy, and define a development roadmap starting from a first release or minimal viable product to more mature and functionally enhanced subsequent releases.

Efficient Development

Contextualising requirements with the supported business process and anticipated business outcomes enables developer to see the bigger picture and ask the right questions in case information is missing. The more agile the development process, the more important it is to facilitate collaboration and decision making. Process-orientation provides a reliable reference for understanding dependencies and limitations and connects higher and lower level requirements comprehensibly. In a waterfall setting, this approach enables assessing the completeness or requirements (in scope and content) before the actual development start and thus avoids inefficient change requests.

Quality Assurance and Testing

Especially for complex systems, comprehensive testing of all conceivable paths and functionality combinations is hardly possible nor meaningful. Instead, the established practice is to adopt a risk-based approach to testing. For estimating the 'Severity' of a potential impact it is vitally important to connect a requirement to its contribution to the anticipated outcome. Connecting a requirement to the process supports estimating how often a requirement and the resulting capability or feature will be leveraged and thus drive establishing the 'Occurrence' likelihood. This way, well-written and –anchored requirements enable rational and effective test strategies, easily justified during audits.

In summary, just like the fish rots from the head down, low quality requirements are bound to lead to bad quality or ill-fitting systems. They should be worked out and documented as the starting point for any implementation activity. That does not rule out that requirements may need to be refined, sliced and diced on the way but make sure to not trick yourself. "Reverse engineering" requirements for an existing solution is likely not giving the benefits outlined above.

Anchoring requirements to the business process and business objectives, makes writing high quality requirements easier by supporting comprehensiveness and comprehensibility. High-quality business requirements lead to systems that are not only operationally efficient but also strategically aligned with organizational objectives, providing sustainable value.

Please get in touch if you would like to learn more on how to establish and leverage Business Process Management to support your transformation initiative.

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.