News

The current crisis has helped us appreciate the skills and flexibility of the great staff.

To pivot and adapt to a changing environment is crucially important in this difficult time.

So, what happens when you bring new staff into your team, either through recruitment or by moving them from another part of the organisation? How long does it take to get them up to speed? How quickly can they adapt to the agile way of working?

 

What Onboarding means?

Onboarding is the term used to describe new employees joining and integrating into an organisation or team.

Onboarding isn’t just about induction and orientation it’s about how you manage the whole process of embedding new staff from the interview to the point at which they’re truly part of the team. It is about them moving from being outsiders to being insiders.

Because agile teams are autonomous, cross-functional and self-improving, newcomers into agile environments can face challenges in becoming fully integrated. Agile team members are expected to manage their own tasks and often take on several different roles.

In project teams, the work each team member does might differ substantially from day-to-day. Established team members often know each other very well and are confident of their own skills. All these factors can make it difficult for newcomers to join in.

We found from our research with a co-located team that agile techniques, as well as more traditional approaches, can help with onboarding. Traditional onboarding includes running an induction programme, providing a new staff pack, offering formal training, and allocating a mentor.

The table below shows some of the agile-related techniques used by the agile software development team we researched. These complemented the traditional techniques they also used. This team changed regularly and frequently had to onboard new members of staff.

 

3 Techniques for Onboarding onto an Agile Team:

Pairing

Pairing involves two people working synchronously on one task.

Pair programming is commonly used in IT teams, but pairing can be used for all types of work and is a great way of exchanging knowledge. Usually, one person deals with the detail while the other thinks more strategically and every now and then they swap roles.

In newcomer pairing, try pairing your newbie with an experienced member of staff for the first few weeks. During this time the newcomer will pick up lots of formal and informal knowledge. Although it is not possible for the two to swap roles, the newcomer will gradually become more independent.

If a new staff member starts while the team is working remotely, pairing can be a particularly useful way to help the newcomer stay connected while learning their new role.

 

Small tasks

Give your newcomer small tasks that they can complete in a day and vary the type of tasks you give them in the first few weeks. They’ll get a sense of progress from regularly completing tasks and get used to delivering chunks of work in short time periods.

As a result, they’ll be able to contribute to daily stand-ups immediately and learn from regular feedback. While working remotely, getting feedback is particularly important for new team members. Doubts can quickly set in without it.

 

Signal availability

At various points in the day, an agile team may work together in small groups or as a whole team to solve a problem. At other times individuals need to have uninterrupted time to concentrate on completing a task.

Find a way for team members to signal their availability throughout the day so newcomers can understand who can be interrupted and who prefers to focus on their own work. This is particularly important when working online.

Use an ‘available to be interrupted’ signal in your virtual environment so everyone in the team knows who they can ask for help. For instance, in Microsoft Teams you can set your status to ‘Available’ or ‘Do not disturb’ as an indicator.

Finally, don’t forget the social aspect of being in a team. Having a coffee break together - either virtually or in-person - and getting to know your new team member informally is important too.

Agile working is about people and culture as much as processes and practices, so spending time welcoming and getting to know newcomers is time well spent.

 

This article was originally published in June 2020 and reproduces by kind permission of the Agile Business Consortium.

Agile Research Network

The ARN is a collaboration between researchers at two UK universities, The Open University (OU) and The University of Central Lancashire (UCLan), at the forefront of investigating Agile methodologies.

Further reading Gregory, P., Strode, D., Barroca, L., Sharp, H. & Taylor, K. (2020) Onboarding: How Newcomers Integrate into an Agile Project Team. To be published. Proceedings of the 21st International Conference on Agile Software Development, XP 2020 https://www.springerprofessional.de/en/onboarding-how-newcomers-integrate-into-an-agile-project-team/18021556 Plonka, L., Sharp, H., Van der Linden, J., & Dittrich, Y. (2015). Knowledge Transfer in Pair Programming: An In-depth Analysis. International Journal of Human-Computer Studies, 73, 66-78.

The abbreviation PMO is most generally used for the Project Management Office. The Project Management Office is a group or department within an organisation whose job it is to maintain the standards for project management and programme management within the structure. The PMO is the backbone of a successful project or programme. The PMO offers guidance to projects and programmes by trying to standardize the practices and increase efficiency. It focuses on standards and offers help by implementing different methodologies. The PMO also develops and maintains metrics to follow the execution of projects and programmes. A best practice PMO has a problem-focused purpose, with its functions and services aligned with the purpose, function and services of the other PMO within the organisation.  

Different types of PMO

The term PMO is mainly used to describe a Project Management Office, however, some organisations use the term to describe either a Programme Management Office or Portfolio Management Office.

• The Project Management Office supports individual projects.
• The Programme Management Office coordinates identify dependencies of projects and supports the transition of outputs to Business as Usual.
• The Portfolio Management Office functions at a corporate level where all change initiatives within an organisation are managed.

All different types of PMO will provide the organisation with the capability to deliver change initiatives in a consistent way and ensure these are constantly aligned with its strategic objectives.   Zooming in on the Project Management Office, there are three different types to be defined:

The Supportive PMO

The Supportive PMO provides support in the form of on-demand expertise, templates, best practices and lessons learned. This is a great solution for organisations where projects are done successfully in a loosely controlled manner.

The Controlling PMO

The Controlling PMO provides support but also requires that the support is used. The PMO sets requirements of specific methodologies, templates and governance guidelines. Projects are also closely monitored by this type of PMO. The Controlling PMO is a solution for an organisation that seeks to align activities, practices and documentation.

The Directive PMO

The Directive PMO provides Project Management experience and resources to manage a project. This type of PMO creates a high level of consistency of practise across all projects and is especially effective in large organisations.  

Purpose of the PMO

The PMO, whatever type, offers guidance and information. It helps the organisation make sure that the right projects are done and that the right decisions are made by the right people, with the right information at the right moment. It helps the organisation govern and deliver projects in line with the organisation's values and organisational goals.

The PMO

• Seeks to implement appropriate project selection and prioritise criteria that assess the contribution to strategy, along with validation of the business case.
• Services to support the management of dependencies between delivery, deliverables, business changes and benefits across the projects and programmes.
• Can imply the use of appropriately tailored methodology like PRINCE2 and MSP or other Project/Programme Management methodologies in order to ensure projects and programmes are delivered well, efficiently and effectively.
• Provides a benefits framework and support for Project and Programme sponsors in order to deliver the benefits aligned with the organisation’s goal.
• Designs and implements functions and services that address the current or prospective problem/question that is recognised and acknowledged within the organisation.
• Listens to the decision-makers in the organisation and designs functions and services accordingly.
• Adapts to the maturity of the organisation, the culture, structure and level of sponsorship. Based on this it determines the value of the services to the organisation.
• Keeps an overview of all ongoing, previous and future projects and programmes and serves as a repository for all documentation.
• Creates quality reports that can be used for decision making by executives and boards with up to date, reliable and credible data.
• Demonstrates the value of the services it provides.

Organisations are not static, they constantly adapt and change to reflect the changing business environment. This means that also the challenges and questions to be answered will constantly change. It is the responsibility of a well-organized PMO to keep its eyes and ears open and be aware of the changing environment. The PMO is always looking for the new challenges and questions to be answered along with a continuous evaluation of the current functions and services provided by the PMO so they can be adapted as required. The PMO directly reflects the organisation and therefore neither the PMO is static. This means that the PMO can also decide to stop some services or introduce new services, with appropriately skilled resources. The PMO is very dynamic.  

Capabilities within the PMO

The set of capabilities and fulfilled roles will be different for every PMO, depending on size, complexity and many external factors. However, for a good functioning PMO, there are some obvious areas that should be covered.

• Stakeholder engagement: to ensure the right people are receiving the right messages in the right way – avoiding any misinterpretation
• Project management: to be able to support and/or challenge with credibility
• Analysis: to be able to collate, interpret and analyze often complex data
• Communication: to listen to and be able to present the right messages in the right way so that they will be accepted – even the difficult ones
• Negotiation: to act as a broker between the sponsor, business and PMO. Not usually a daily demand but potentially an invaluable skill at the enterprise level.

 

PMO Roles

The PMO is essentially providing services to an organization, but what this actually entails can differ between organizations. It is a complex and ever-changing environment and roles and the context of projects and programs highly influence the PMO. The PMO related roles are: . PMO Manager, who has the daily responsibility of the PMO. The Project Management Office Manager is to ensure that their company’s standards are upheld and clearly defined throughout the entire process of each project’s development and execution. PMO Managers are responsible for overseeing the work of all project management office personnel, and thus must take ownership of the resulting quality of each project. . PMO director is a senior level role and is most definitely concerned with taking ownership and accountability for change activities within a business. They are there to make sure an organization has everything in place for strategic initiatives to be delivered successfully. They are often focusing on creating the right environment with strong capability and capacity for delivery to succeed. . PMO administrators help to keep all those things organized. These administrators control documents, facilitate communication between the project office and stakeholders, and collect data to meet reporting requirements. . PMO Analysts hold a managerial position, but they work with employees from all levels who touch on the projects they are assigned to. As both analyst and manager, a successful PMO analyst is a talented multitasker. . Coach, who is responsible for providing ad hoc assistance to individual project managers or project teams. . Communication Specialist is the figure responsible for the communication plan and ensuring that all stakeholders receive timely communications regarding their projects. . Methodologist is this figure is responsible for the methodological content chosen for project management processes. It manages the evolution of templates and best practices, as well as for instructions on their use. Other probable roles within a well organized PMO can be defined into four different levels:

• Project Support roles: Project administrator, Project Co-ordinator, Project Support Officer.
• Portfolio, Programme and Project Support roles: Project Management Officer, PMO Officer, PMO Specialist roles (Project Planner, Project Scheduler, Project Controller).
• Leading and Managing PMO’s roles: PMO Manager, PMO Lead.
• Directing PMO’s roles: Head of PMO, PMO Director, Portfolio Director, e-PMO (enterprise PMO).

 

P3O - Portfolio, Programme and Project Offices

For the higher-level roles within the PMO, a P3O (Portfolio, Programme and Project Offices) certificate is often requested. P3O is a methodology that helps organisations build support structures that enable the successful delivery of their portfolios of change management programmes and projects.   Source: Axelos: Value of the PMO  Axelos: Implementing and leading a best practice PMO

Our way of working is under constant change. That automatically implies that also our Project Management is under constant change. Project Management has become one of the most important pillars within any company as it has been recognized as one of the fundamental factors for the success of the organisation. This is why organisations are looking for technologies, systems, and processes that help them to customize and optimize Project Management. There is a need for growth, which often goes hand in hand with an increase in clients/customers. Project Management needs to be able to adapt to these needs and continue to serve the organisation at all stages of growth. This is why the Agile methodology was born, which seeks to bring that flexibility into the world of Project Management by completely detaching itself from traditional frameworks. A traditional Project Management framework is defined as the ‘Waterfall Methodology’. The Agile framework and the Waterfall Methodology differ in obvious and less obvious ways. Both have their benefits and drawbacks and there is no ‘bad’ way of Project Management. What works best for your organisation depends on your situation and strategic objectives. In this blog post, we will analyze the differences, benefits and drawbacks of the Agile methodology and the Waterfall Methodology (traditional).  

Waterfall Methodology

The Waterfall approach is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. At the start of the project, the output, outcome and benefits are defined. The Waterfall model originated in the manufacturing and construction industries, where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process. When first adopted for software development, there were no recognized alternatives for knowledge-based creative work. The Waterfall model has a set team working in a linear fashion towards a clearly defined end goal. It makes use of standard documentation of which the format is predefined by the organisation. Examples of this documentation are the PID and the Business Case.  

Waterfall Methodology: Benefits vs Drawbacks

 

Agile

The major difference between agile vs. waterfall might be summarized by saying that the waterfall approach values planning ahead, while the agile approach values adaptability and involvement. However, there is not just one Agile approach: Agile is a combination of multiple frameworks. The agile methodology has two core elements: teamwork and time. Instead of creating a timeline for one large software development project, agile breaks the project into individual deliverable pieces. These ‘time-boxed’ phases are called ‘sprints’ and last just a few weeks. Once each sprint is completed, the feedback from the previous phase is used to plan the next one. An Agile team starts every day with a short meeting where they discuss the status and objectives of the project they are working on. This is called a daily stand-up meeting, which is beneficial for all team members, regardless of their position in the team. Read here why the daily stand up meetings are being held and how to optimize them.  

Agile Framework: Benefits vs Drawbacks

 

Waterfall vs Agile: Comparison

  Which development methodology you go with depends very much on several key factors. For example the structure of the organisation, the sector, the strategic goals and the role of Project Management in the organisation. There is no bad choice, for some organisations, the Agile framework will better fit the objectives, for others the Waterfall approach is a more obvious choice. However, it also absolutely possible to create a mix of approaches, depending on the project.

In Scrum, team members work together to achieve shared goals, in an environment of collective responsibility and continuous progress. In our webinar ''Scrum Master by APMG'', we discussed the role of Scrum Master within the Scrum Team with the expert Kim Delgadillo. Ever since we have been receiving many questions about the role of the Scrum Master and the Scrum Team in general. This blogpost, written by one of our Scrum experts, is aimed to take away all doubts about the Scrum Team and answer all your questions.  

How important is the technological competence of the Scrum Master? At times it may seem like the Scrum Master is a simple motivator with management skills rather than IT, or is it the link between the product owner and the team?

By carefully reading the guide to Scrum by Ken Schwaber and Jeff Sutherland we find no reference to “Technological” competencies of the Scrum Master. But it is absolutely possible that the Scrum Master is also part of the Development Team.  

Do customers easily accept to pay a Scrum team for a specific period without however being certain of the final result?

If you are used to procurement through “Fixed Scope” contracts, it can be difficult to change even if the goal is to seize an opportunity. Remember, Agile is a mindset. Therefore it is necessary for everyone (Customer / Supplier) to evolve; from a “closed” approach, with low external sharing, it is necessary to gradually move to an “open” approach, based on a cycle of learn-share-collaborate-improve, to encourage the exchange and transfer of knowledge in unconventional ways.  

What responsibility does the Scrum Master usually have in the context of cost and time control of a project?

The Scrum Master has many responsibilities (that you can discover here), but among these, there are no items that specifically concern the management of Time & Cost project constraints. It is a shared responsibility of the entire Scrum Team. Remember that Time & Costs are fixed and that the Scrum Team must be “Good” in setting the Sprint Goal. Here you can discover the responsibilities of the other Scrum Team members; the Scrum Developer and the Scrum Product Owner.  

If after multiple sprints the sprint goal is not reached, is this a failure for the Scrum Master? And what approach should the Scrum Master take in this circumstance?

The situation described is not a failure for the Scrum Master but certainly is a reason for reflection for the entire Scrum Team; issues to reflect on could be:

• What did we not understand about the project/product?
• Is there a technical knowledge gap to fill?
• Internal/external changes to the client that make the sprint goal systematically obsolete?

Have you already downloaded our free article “Discovery of Scrum: the foundation”? Some of the topics covered in the article: Sprint, review meeting, retrospective meeting, user story, roles in Scrum.  

But if the objectives are not reached during the sprints, does that mean that the time of the project is prolonged? If so, how does that work with the costs?

When the approach is Predictive in the early stages of the project, the focus is on detailing the planning by basing the estimates on the Scope defined in the formal documents (plan-driven approach). During the life cycle of the project, the project plan will be the work management guide and the reference for calculating progress. Changes are managed through a formal system and the value is generated at the end of the project, upon delivery of the final product. When, on the other hand, the requirements are unstable it is advised to focus on making decisions that give priority, and therefore time precedence, to activities with greater added value and actions for greater risk reduction (value-driven approach). It is advised to set budgets and create a plan in advance and to make the project scope negotiable. This rather than trying to fix the characteristics of the product, which will consequently determine the times and costs of implementation (plan-driven approach). When the approach is adaptive, therefore, the planning is carried out iteratively before each Sprint/Iteration, you are able to respond quickly and effectively to change. This results in a reduction in costs and, ultimately, an increase in profitability and Return on Investment (ROI). In more general terms, we move from an “inside-out” model, where you make and sell your product on the market, to an “outside-in” model, where you iteratively build the product/service together with your customer. Here the focus is on the Minimal Viable Product (MVP).  

Does the Scrum Product Owner also participate in the Sprint Retrospective phase? If so, what role does he/she play in the development team?

The Agile Business Consortium “strongly recommends” the presence of the Scrum Product Owner during the Sprint Retrospective meeting; like all members of the Scrum Team, he/she introspects and actively participates with the goal of continuous improvement.  

What does the Scrum Product Owner have to say during the daily? Isn’t that an obstacle to the Scrum Master in facilitating the ease of the team?

The Scrum Product Owner may be a member of the Development Team. This is a perfectly viable situation and in such circumstances, the Product Owner can obviously participate and participate fully in the Daily Scrums. If the Product Owner is not part of the Development Team, there are different schools of thought. Eg. Agile Alliance suggests keeping the Product Owner out of the Daily Meeting, Agile Business Consortium instead recommends the participation of the Product Owner and suggests the Development Team invite the Product Owner (it’s a good idea to share the choices and the commitment).    

Antonietta-Fiorentino

Antonietta Fiorentino is an entrepreneur and Transformation Leader. Bi-modal PMO in digital transformation and for the innovation of large and medium-sized enterprises. For QRP she is a trainer and agile business consultant.  

Holders of the Certified Associate in Project Management (CAPM) will no longer need to reapply and pay ($225 for members and $300 for non-members) to rewrite the CAPM certification exam at the end of their certification cycle. From now on, in order for certification to remain active, CAPM certification holders will simply have to earn Professional Development Units (PDUs) over a shorter certification cycle through the PMI's Continuing Certification Program (CCR). CAPM certification holders will be required to earn 15 PDUs over the new three-year certification cycle and pay the recertification fee ($60 for members and $150 for non-members).  

Why such a change?

The latest PMI market research shows that CAPM certification holders believe that PDUs represent a more valuable investment of their time and effort, as they allow them to keep abreast of new developments and trends in project management. This new process is easier and less costly for CAPM certification holders as there are many ways to earn PDUs. If CAPM certifiers obtain other PMI certifications, the PDUs they earn with the other certifications can be applied to the CAPM PDU requirements. They will simply have to pay the recertification fee. Thus, if the professional becomes certified (PMP), they can count 15 of the 60 PDUs they earn for the PMP towards their CAPM PDU requirements.  

Limited time renewal offer

To facilitate the transition from PDU acquisition to maintaining CAPM certification, the following limited-time renewal offer is available: Active CAPM certification holders who renew at the member and non-member price of USD 60 by 31 March 2021 will have an additional three years to their certification cycle. This will give certification holders more time to adjust to obtain the 15 PDUs needed to maintain certification. In addition, regardless of when individuals pass the CAPM certification exam, they can take advantage of this offer. However, those who do not renew by March 31 2021, will need to earn the newly required 15 PDUs before their certification expires, log on to the CLS and pay the renewal fee ($60 member / $150 non-member) to maintain their certification. Holders of expired CAPM certification who take advantage of the member and non-member renewal price offer of $60 USD by March 31 2021 will have their CAPM certification reinstated for three years. For more information, contact our team at switzerland@qrpinternational.com   Source: https://www.pmi.org/

MSP (Managing Successful Programs) is a globally recognized Good Practice Guide for Program Management that is used by organizations to direct change investments. Axelos recently published the 5th edition of the MSP guide, which had not been updated since 2011. This new edition responds to a number of changes that have occurred in the world of program and project management since then. Indeed, a great deal of research has been published over the last few years, showing the high failure rate of programs, whether they are transformation programs or large-scale programs. The digital revolution, the speed of change, the rise of agile ways of working, and the increased volatility and uncertainty in all markets have led program management to evolve to meet these demands. This new edition will help current and future program managers, and many other roles, to design, plan, lead and execute their programs and help organizations make their transformation program a real success.  

MSP 4 vs MSP 5

The essence of what a program remains the same as it was with the 4th edition: it is temporary, it is focused on results and benefits, and it is concerned with leading several projects and other work. The basic concepts (principles, themes, and processes) also still form the overall structure of the guide. However, these have been revised with the following principles in mind:

• Ensure that MSP remains adaptable and flexible and can be used in a wide range of organizations and environments. There are many different drivers of change, and the MSP approach to program management must ensure that the organization's investment in change is managed wisely.
• Provide guidance for a wide range of investments that benefit from program management, recognizing that the word "program" has many different meanings for organizations and that terms other than "programs" may be used by these organizations.
• Emphasize the incremental nature of a program and show how MSP allows cyclical progression to the desired future state. Organizations are complex, the external context is emergent, and the delivery of benefits and value creation generally cannot be achieved through a series of linear steps.
• Enable program teams to recognize the many ways in which outputs and changes can be delivered, including iterative (Agile), traditional, and hybrid approaches.

 

Key Elements of MSP 5

The MSP 5th edition emphasizes greater flexibility, adaptability, and responsiveness by taking an incremental approach to the program lifecycle and enabling organizational agility. The MSP 5th edition consists of a set of principles, themes, and processes that provide a clear roadmap for the program life cycle and ensure successful organizational results. The MSP guide offers 3 lenses:

• 7 universal principles
• 7 themes facilitating governance and essential controls
• 7 processes representing the incremental life cycle which, if flexible and adaptable, allows an orderly cyclical progression with clear decision criteria.

Source: webinar “OVERVIEW MSP 5th EDITION” - Axelos 2020   The overview of the revised key elements is as follows:

. Vision

An updated approach to the structure of a vision statement.

. Benefits

A reinforced vision of a key principle of SHP throughout the guide.

. Risks

A broader discussion of risks and risk mitigation across the program.

. Organizational Structure and Roles

Well-established roles within the MSP have been reviewed and updated, and new roles are being introduced and discussed.

. Business Case

One of the main challenges is to obtain funding for a program. In the updated basic guide, this topic is discussed and provides a new approach to its development.

. Blueprint

A key element of MSP has evolved into the target operating model, and the MSP 5th edition explains its use and benefits in more detail.

. Stakeholder Engagement and Communications Planning

Key elements of the new working methods, responding to the main challenges of today's program management.  

Agile Program Management Integration

The MSP 5th edition offers the multimodal delivery mode, which allows multiple ways of working, depending on what suits you best during delivery. The same program or project can combine different approaches to work, its components, with projects using iterative (agile), traditional or hybrid life cycles, or continuous improvement activities. Leaders need to decide when to invest in addressing change drivers, for example:

• adopt disruptions and emerging technologies and trends,
• build new physical infrastructure,
• respond to societal expectations and policy changes,
• establish more effective working partnerships across supply chains,
• using scarce resources as efficiently as possible.

MSP is the perfect answer to multiple common challenges such as insufficient support from the board of directors, unclear decision making, unsustainable focus on benefits, lack of a clear idea of where the company is and wants to be, unrealistic expectations about the ability to bring about change, stakeholder engagement. MSP has been designed both for any form of organization that needs to respond to changes in its sector to survive and thrive and for individuals (PRINCE2 certification holders, project managers, program managers, change managers).  

Main Differences between Exams

The MSP 5th edition certification scheme includes only two levels: MSP Foundation and MSP Practitioner. In addition to a completely redesigned program, there are several differences between the MSP 4th and 5th edition exams that will bring new benefits to candidates :

• The MSP Foundation exam has been streamlined so that candidates can now focus on learning MSP content, rather than learning to answer complex questions.
• The MSP Practitioner exam has also been simplified to give the candidate more time on the exam to focus on the questions and reduce the reading load.
• Both exams have seen a reduction in the number of questions for each level: the MSP Foundation exam has been reduced from 75 to 60 questions, and the MSP Practitioner exam has been reduced from 80 partial questions to 70 questions. Despite the reduction in complexity and number of questions, the time allocated to write the exams remains at 60 minutes and 150 minutes respectively for MSP Foundation and MSP Practitioner. This is to ensure that candidates have sufficient time to be able to answer each question to the best of their ability.
• Both exams have been refocused based on the cognitive ability (Bloom level) required. The MSP Foundation exam covers all key concepts at the level of knowledge and understanding (Bloom's 1 and 2). There are no new concepts introduced at the MSP Practitioner level; the exam simply assesses the same concepts at a higher cognitive level (Bloom's 3 and 4), where the candidate is asked to apply and analyze the concepts in context.

The MSP 5th edition guide is much more focused on key concepts. As a result, the candidate will benefit from a product and an assessment method that focuses on what is really crucial for a program manager.  

Benefits of the MSP 5th Edition Method

• It aligns projects and programs with organizational strategy.
• It provides a disciplined approach to profit management that facilitates business changes.
• It ensures an appropriate division of responsibilities and obligations.
• It facilitates organizational agility.
• It helps to understand the risks associated with a program.
• It is a proven best practice in the successful implementation of organizational change through the application of program management.

Source: webinars, blog, and Axelos white paper.  

Would you like to follow an MSP training course?

Our training is once again available in face-to-face and distance learning. QRP is ISO 9001:2015 certified. Contact our team at +41 (0)43 588 10 36 or switzerland@qrpinternational.com to learn more about our virtual classroom, face-to-face, or intra-company offers!