News

The seven guiding principles are the most practical parts of ITIL. If you use these principles as your base, share them with your colleagues and use them to make decisions, then you will make great use of them. Following ITIL’s guiding principles, you will create bigger value for all stakeholders involved in your organization. When ITIL updated from v3 to ITIL 4 (the current methodology), also the 7 guiding principles have been updated. They are now the core part of the ITIL architecture. The 7 guiding principles provide guidance, encourage decision making and promote continual improvements at all levels. The seven ITIL guiding principles are:

• Focus on value
• Start where you are
• Progress iteratively with feedback
• Collaborate and promote visibility
• Think and work holistically
• Keep it simple and practical
• Optimize and automate

 

The 7 ITIL guiding principles are universal

Altogether, the guiding principles embody the core messages of ITIL and service management in general. They can be used to guide organizations as they ‘adopt’ a service management approach and ‘adapt’ ITIL guidance tailored to the organization’s specific needs and circumstances. The 7 ITIL guiding principles are recommendations that guide an organization, regardless of changes in its goals, strategies, type of work or management structure. The 7 ITIL guiding principles are universal and enduring.  

1. Focus on value

Everything that the organization does needs to deliver, directly or indirectly, value for the stakeholders. Therefore it is important that the organization has a clear understanding of who the stakeholders are. It is also key that the organization understands what is true of value to the service consumer. This is something that changes over time and circumstances. Last but not least the organization needs to understand the customer experience, whether subjective or objective, in order to offer the best service.  

2. Start where you are

ITIL does not request that you build something new. The guiding principle ‘start where you are’ is there to remind you that it is not wise to start over without considering what is already available. It is important to have a clear view of the current situation in order to build something new. So with this guiding principle, organizations are advised to assess where they are. This includes a clear overview of available data and measurements.  

3. Progress iteratively with feedback

This guiding principle is there to remind organizations not to do everything at once. Instead, ITIL recommends using improvement iterations. Hereby work is organized in smaller, manageable sections that can be executed in a timely manner. Important is that these iterations are continually reevaluated and potentially revised. This to reflect any changes and to make sure the focus on value is still there.  

4. Collaborate and promote visibility

Key for all initiatives is collaboration and trust. Therefore it is important to inform, understand and trust. Organizations have to be transparent and share as much as possible. They also have to keep track of the flow of work in progress, identify bottlenecks and uncover waste. To create the best output, organizations also have to make sure that the right employees have the right roles and responsibilities. Collaboration and communications is important, but can be different in every situation depending on the stakeholders.  

5. Think and work holistically

To create the best service, it needs to be clear that all is connected. No service, practice, process, department or supplier stands alone. All activities should be aligned with the same focus on the delivery of value. This is done by clear communication, automation and a clear view of patterns.  

6. Keep it simple and practical

This guiding principle is there to make sure things are not over-complicated. To do this, exceptions need to be defined and rules need to be put into place. Another activity is to judge what to keep, done by asking the question: ‘Does this practice/process/service really contribute to value creation?’ To keep things simple, sometimes it is better to do fewer things, but to do them better. In the end, simplicity is the ultimate sophistication!  

7. Optimize and automate

This principle is put into place to make sure there is a focus to maximize the value of work carried out by both human and technical resources. Automation can help the work on frequent and repetitive tasks, freeing human resources. These human resources can then be put into place for more complex tasks that contribute to the value. Important is, that automation is not done for automation sake. It needs to be clear beforehand how the automation will help the complete organization to increase value.  

How to use the 7 guiding principles

As an organization you do not choose one or two principles to apply, you should consider the relevance of each of them and how they apply together. The 7 guiding principles interact and depend upon each other. None are critical, but all could be useful. The guiding principles should be reviewed on each occasion to assess how appropriate they are. The 7 ITIL guiding principles are universally applicable to practically any initiative and to all relationships with stakeholders. It is important to refer to the principles at every decision making process or plan of improvement. But also when you are stuck, face some challenges or need some help. You might even consider to print them out and hang them somewhere where you can see them multiple times a day!  

The 7 ITIL guiding principles do not stand alone

These principles are not just connected to ITIL but are reflected in many other frameworks, methods, standards, philosophies and/or bodies of knowledge. This allows organizations to effectively integrate the use of multiple methods into an overall approach to service management. Do you want your list of guiding principles to print out? We made a clear overview for you. Download it now!  

For those who are approaching an Agile environment for the first time, the role of “Scrum Master” and the role of “Project Manager” could appear very similar. However, that is not the case. The Scrum Master and the Project Manager are two different professional figures. In this post, we will analyze both in order to catch all the peculiarities of both professionals.  

Role of Scrum Master vs Project Manager

The Project Manager is a leader, he/she owns the responsibility of reaching all the project goals. This is done by coordinating business and technical delivery aspects of the projects throughout its duration.  The Project Manager provides management direction and coordination. The Scrum Master, on the other hand, is a servant-leader for the Scrum Team. This Scrum professional helps everyone to understand Scrum theory, practices, rules, and values inside and outside the Scrum Team. A Scrum Master is more like a coach than a manager. In fact, a Scrum Master:

• does not manage the team but is responsible for promoting and supporting Scrum and the Agile principles
• supports the Product Owner
• is responsible for Scrum processes and their correct implementation with and within the Scrum Team.
• is devoted to maximizing the value created by the Scrum Team.

In a few words, the Project Manager manages all the planning for the project execution. The Scrum Master, on the other hand, supports the Scrum Team by working side by side with its members. The Scrum Master also verifies that the Agile principles are implemented correctly. The Scrum Master, contrarily to the Project Manager, does not assign tasks to the team members. The Scrum Master is a process facilitator by leading the team to achieve efficient self-management and self-organization. The self-organization is a core principle of the Scrum Team: the Scrum Team is not managed by a hierarchical structure. Every member of the Scrum Team knows what to do and how to do it, no external direction is involved. In an Agile project, the responsibilities that a Project Manager has in a traditional project, are shared among several figures:

• Product Owner
• Scrum Master
• Development Team

The activities of a Scrum Master change on a daily basis depending on the exigencies of the team. The Scrum Master has the responsibility of the correct functioning of the team by protecting it from external dangers. The Scrum Master is a fundamental role because he/she supports the team towards project success. The main focus of a Project Manager is on the overall project while the Scrum Master focuses on the team and its team members. The aim of the Project Manager is to ensure the success of the project whereas, the scope of the Scrum Master is the success of the team.  

The Project Manager in an Agile environment The PM and the Scrum Team

When an organization switches from traditional to Agile methods, the Project Manager might feel uncomfortable with the Agile processes. This is due to the differences in the functioning between an Agile self-organized and a traditional, externally managed team. In an Agile context, the Project Manager has to delegate the detailed planning to the Scrum Teams. The relationship between the Project Manager and the Development Team is more of an informal kind. The Project Manager will not constantly check on the team performance, he/she will instead verify that the teams work in the right context. The Project Manager has to collaborate with the Development Teams, he/she offers guidance and helps to handle issues. The responsibility of a Project Manager is to ensure that the Development Team understands the objectives agreed at the beginning of a timebox. He/she is also responsible for on-time delivery. Finally, the Project Manager and the Scrum Master can coexist but they are two distinguished professionals. Thinking that the Project Manager should become a Scrum Master is a mistake. In fact, several Project Managers are unable to fit the Scrum Master role perfectly. This because they are likely to enact the “command and control” style within the Scrum Team. This is not the aim. A successful Scrum Master is a professional that is passionate about Agile. He/she wants to share their knowledge through the servant leadership, disregarding the technical or managerial background one could have. Curious to learn more about the role of the Scrum Master? We hosted a webinar about the role with our expert Kim Delgadillo.     Source:

• Schwaber and Sutherland, The Scrum Guide;
• DSDM Agile Project Management Handbook v2;
• Agile Project Management and Scrum v2, DSDM Consortium

Liza Andersson is a Project Manager Global Sales Operations at FLIR Systems Trading Belgium. She is passionate about Agile, never gives up and can tackle any type of Project Management challenge.  

What's your current job title? What is it you actually do?

My current job title is Global Sales Operations Project Manager. I drive our global efficiency and standardization projects. I also oversee numerous local initiatives that are divided into two continents and five FLIR facilities.  

How did you arrive to follow a project management career?

I like to get things done. I don’t want to waste any time in the current when the future is where we want to go. I have strong execution skills, no patience and value teamwork as the only way to accomplish something. This is how I came to feel right at home in the project management role. I began my career with FLIR six years ago in the order processing department, where I valued supporting our customers and improving minor work procedures around me to ease my day. First, when we had a change in management in my local office I got the chance to start participating in projects. This gave me and other colleagues the opportunity to display other talents than only our daily skills. The new local management changed the view on how we work within my local office, promoting what you are good at and finding others that are good at the things where you lack skills. The combination became a very fertile ground for self-development leading to new job opportunities. For some of my colleagues, this led to new positions bordering Global Trade Compliance, some took the path of Business excellence and quality. But for me, this meant an introduction to project management. I always worked organized and in structures so for me to take this path was a natural step.  

FLIR considers itself an Agile organization, how does that mirror in your daily work?

Yes, we truly work Agile in the deeper sense of the word. FLIR doesn’t just say it works Agile, we really have it as our core principle of work methods. I notice our Agile way of work through our TFM (the FLIR method), lean project improvements and our IT Scrum Masters that run projects. The Scrum Masters focus on training business teams on how to work Agile and how to utilize it efficiently in Project Management. To us at FLIR iterations, sprints and small deployments of deliverables are part of our core as we say we want to “move at the speed of heat” as we are ready to take on change at any form. The world is not static and if you chose to deploy solutions at its end game you might have missed the need of the customer. Needs shift and change so fast today that the ability to move with it requires agile teams and solutions.  

You have an AgilePM Certificate, how did that help you reach your goals?

In 2018 I got promoted from being a customer support agent to a project coordinator role. By doing so the doors opened up to global initiatives and working with our colleagues around the globe both in Asia and in America. After a year in this role, I felt the need to start training. I couldn’t rely on my standard toolbox anymore so I took a course of Agile PM at QRP Belgium. When my local manager, who is extremely Agile and Lean Six Sigma oriented, got promoted to become our global management I became global as well. This made the need for a larger toolbox inevitable. I completed my Agile PM course, organised by QRP Belgium, in September 2019 and achieved my promotion to Project Manager thanks to this. Today I am looking at PMI courses to enhance my toolbox even further. I am also leaning towards Scrum Master certification to broaden my Agile toolbox even more.  

What type of Agile frameworks are you currently using and/or planning on using at FLIR?

We are currently using SCRUM, Lean and Agile PM. I am not planning to review any other at this time.  

What about Agile and remote work, how did FLIR handle the current situation in regards to COVID?

As mentioned above Agility is one of our core mindsets. It took us just four days to shift from office work to remote and this for our entire business (excluding production and service). By leveraging tools such as ADO, ZOOM, MS Teams and Skype we easily moved from face to face meetings into daily scrum sessions etc through MS teams and Zoom. Tools such as Mindmanager with joined editing efforts made it possible to brainstorming remotely and agree on areas of focus without the need of meeting in person.  

What is the biggest issue/change you see in your network at the moment regarding PM?

Currently, I am struggling with the ability to enable resources as not many of the team members work on projects full time. However, ADO seems to have solved this issue and this is something I am seeking more information regarding setting up a good process to tackle resource requests.  

What's your advice on how to solve/face the above-mentioned issue/change?

Stay connected to other Project Managers around the globe. If we can leverage each other’s experience we will build a better project organization within our own organization too.  

What are three things you’ve told yourself that you would like to learn in the near future to develop yourself as a professional?

Personally I have set three topics that I am going to tackle in 2020

1. Do a 360 feedback review to enhance my leadership skills
2. Shift my focus from operational to transformational and framework (PMI)
3. Improve my skills in the tool ADO and get a certification

 

Liza Andersson

Liza Andersson is a Project Manager Global Sales Operations at FLIR Systems Trading Belgium. She is passionate about Agile, never gives up and can tackle any type of Project Management challenge.    

The DevOps Fundamentals qualification is a professional qualification and strongly connected to the Agile methodology. This qualification provides you with an understanding of the DevOps Fundamentals. There are no mandatory requirements for the DevOps Fundamentals certification process, however, work experience in IT is recommended.  

Examination Target

• Management, operations, developers & QA and testing professionals.
• IT professionals working within, or about to enter, an Agile Service Design environment.
• Different IT professionals; IT development, IT operations or IT service management.
• Individuals that require an understanding of DevOps.

 

PeopleCert DevOps Fundamentals Exam Format

The PeopleCert DevOps Fundamentals exam look like this:

• Language: English
• Duration: 60 minutes, 75 for non-native speakers
• Materials: none, this is a closed book exam
• Questions: 40
• Type of questions: multiple choice
• Provisional pass mark: 70% or higher (28 questions correct)
• Exam format: Online or on paper
• Certificate format: Online, paper upon request

The PeopleCert DevOps Fundamentals exam requires Bloom’s 1&2 level of thinking. This means that it is required to remember and recall the materials (level 1) and comprehend the actual meaning (level 2). The exam is made up out of 40% level 1 questions and 60% level 2 questions.  

PeopleCert DevOps Fundamentals Exam Questions examples

The PeopleCert DevOps Fundamentals exam questions are all multiple choice. The DevOps Fundamentals exam includes different multiple choice question type: list, missing word, negative and true/false.   Example ‘standard’ OTQ: Which of the following statements BEST describes Knowledge according to the DIKW Model? A. Statement W B. Statement X C. Statement Y D. Statement Z   Example ‘list’ OTQ: Consider the following statements: 1. Organizational structures encourage a silo mentality and discourage collaboration 2. Local optimization creates process and integration challenges 3. Simple processes result in waste 4. The reduction in the use of public cloud-based delivery options Which two of the above are examples of an IT value delivery problem that DevOps seeks to address? 1. 1 and 3 only 2. 2 and 4 only 3. 1 and 2 only 4. 3 and 4 NOTE: Two of the list items are correct. List style questions are never negative.   Example ‘missing word’ OTQ Identify the missing word(s) in the following sentence: [?] are the three layers of the full stack of DevOps. a) a, b, c b) d, e, f c) g, h, i d) j, k, l   Example ‘negative’ standard OTQ: Which of the following options describes or characterizes what DevOps is NOT? a) Option K b) Option L c) Option M d) Option N NOTE: Negative questions are only used, as an exception, where part of the learning outcome is to know that something is not done or should not occur.

PeopleCert DevOps Fundamentals Objectives

The DevOps Fundamentals certificate is aimed at anyone who wishes to become an active member of a DevOps environment. It will provide its certification holders with a fundamental level of knowledge and will certify that they have a solid understanding of DevOps using a variety of tools. The learning objectives are:

• History and need of DevOps
• Key concepts DevOps and their explanation
• The business value of DevOps
• DevOps culture, transformational leadership and DevOps structure and teaming
• 15 Essential DevOps practices
• Basis knowledge on Agile PM and Scrum methodology
• Key concepts of cloud technology and virtualization, automation for deployment pipeline and architecting for continuous delivery

 

PeopleCert DevOps Fundamentals Certificate

The validity of the DevOps Fundamentals certificate is lifelong; this certificate will never expire.

QRP International is a DevOps Accredited Training Organization (ATO) by PeopleCert on behalf of Axelos, is authorized to deliver DevOps Fundamentals courses and can prepare you for the examination leading to the DevOps Fundamentals certificate in Project Management.

User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.  

What is a User Story? The definition

The User Story represents an Agile practice, especially used in Scrum, that "captures" the needs of users. It does this by expressing characteristics, functions and requirements for the product to be made in a general and non-detailed way. The User Story is part of the Product Backlog. In Scrum, the Product Backlog includes a "list" of all the things that need to be integrated into the project. The User Story looks simple but is truly effective. It requires to focus on the needs and needs of the user (and/or customer) and on the value to be achieved. The user's history is often written on cardboard or post-it and is attached to the wall or on tables in order to facilitate planning and discussion. In this way, the User Story manages to control the attention from the writing of the functionalities to the comparison regarding the functionalities. The User Story demonstrates the importance of the affirmation of the Agile Manifesto "the software working rather than the exhaustive documentation".  

What is a User Story used for?

User Stories are a great way to clearly define what a user wants from a product/service. A set of well written and prioritized user stories can certainly help the team to express and share the product features without going into technical details. A user story allows you to understand the importance and impact of a feature on the business. It also helps to make the customer understand the usefulness of the feature and its priority. If well written, a user story provides a solid basis for communication and collaboration, bringing the user to the centre of attention. The Use of User Stories facilitates discussions on the product, both within the development team and with external stakeholders.  

What is the User Story made of?

Each User Story describes why & what to do in a simple, understandable way for the customer and developers. The point of view is that of the user, who requires the new functionality. The amount of information is that which is essential to allow the development team to make a rough estimate of the work required for the realization. There are several ways of writing a user story. Usually, the User Story contains a name, a brief description and the specific acceptance criteria and conditions for which the story can be considered complete. A model can be: As a <type of user>, I want <some goal> so that <some reason>. Here are two examples:

• As a customer, I want to cancel my hotel reservation in order to get a refund
• As an online customer, I want to be able to log in to access my account securely.

The User Story makes dialogue with the customer and/or user necessary because it is thanks to the dialogue that we are able to understand all the various aspects of the story. Because of the User Story, we can have a good understanding of what and why we have to develop that specific functionality.  

Fundamental characteristics of the User Story

User stories should always contain 6 characteristics, represented by the acronym INVEST, created by Bill Wake *: Independent: they must be independent of each other. Negotiable: they must be "negotiable" and open to everyone's contributions. Valuable: they must bring added value to the customer. Estimable: they must be estimable, not exactly, but enough to allow rough planning for implementation. Small: they must be small, in order to be able to realize the functionality in a couple of weeks of work. They must be small because in this way the estimates are more precise. If the story is too complex, I break it down into multiple stories. Testable: they must be able to be tested and must-have information on how to carry out the tests. See here an example of how to break down a user story into simpler user stories.   Who writes the user story? User stories can be written by anyone with the skills necessary to write them. Most often they are written by the Product Owner (link to the future post). But they can also be written in collaboration with the entire team.   Acceptance criteria Together with user stories, it is important to develop acceptance criteria, that is, criteria that must be used to evaluate whether a story has been correctly and fully implemented. These criteria are the conditions that the software product must comply with in order to be accepted by the user and / or customer. Acceptance criteria are essential to understand when the goal of the user story is achieved.   Format The user story is often written on an A6 paper. The small format obliges you not to use too much information. The card is useful because it is easy to use and makes it possible to group the cards on the wall or on the table. Grouping them makes it easier to evaluate the consistency, completeness and connections between different stories. Even if you have electronic stories, it can be helpful to use cardstock. Another important factor is visibility: the stories must be visible to the whole team. Basically they represent the unit of work that the team is committed to achieving in a sprint. What are the key features of an agile sprint? Read the blog post the 5 characteristics of a successful agile sprint! *INVEST in Good Stories, and SMART Tasks Copyright ©  2019 Agile Business Consortium all rights reserved

Marisa Silva is a passionate advocate of the value of PMOs as business partners and enabling strategic change delivery. She is is an experienced PMO and PPM adviser, educator, author, and international speaker.  

I read in your headline on LinkedIn: Making PMOs critical to the business. How do you do it?

PMOs are an interesting species in the Project Management universe because they face an underlying paradox in their 'raison d’ être': while they exist to meet the needs of the business, if all projects were successful, in principle, then you would assume that there would be no need for PMOs. So, asking how to make PMOs critical to business is indeed a key question that should be ever-present in the mind of PMO professionals. My view is that PMOs can become critical if they adopt three key imperatives. . First, the Imperative of the Business. PMOs which are critical in the organization are business-centric, a trusted partner which enables project delivery, that is, all their functions are designed to serve the business. PMOs need to start thinking of themselves as a service. Their service catalog can then cover a variety of activities, from ensuring that projects are delivered in the right way (project management) but also that the right projects are carried out (portfolio management) and with the appropriate level of competency.   . Second, the Imperative of Agility. While different methodologies and approaches have been developed for projects and project teams to embrace agility, not much is being said about PMOs. However, PMOs are probably the organizational entities that need them the most; not only do they inform and centralize project management practices, but they also have a bad reputation as bureaucratic, slow supportive bodies. PMOs need to embrace Agile too! They need to change their role from a top-down, command and control function, to one of a PMO on the sidelines, providing support and focusing on capability rather than control, and empowering teams to define and to work with the joy of minimum viable bureaucracy.   . Finally, the Imperative of Value, the cornerstone of PMOs. You will certainly find this buzzword in the PMO mandate, in the PMO roadmap, or any presentation about the purpose of the PMO. PMOs are created to enable the creation of value, helping the business to maximize its bang for the buck. At their core, PMOs are all about value. However, value is a subjective concept and what is valuable to me might not have any value to you. The value lies in the eyes of the beholder. Thus, it is fundamental that PMOs start to look at their stakeholders as customers instead and that they ask what these customers want if they are to deliver to their value expectations. Also, we need to start measuring our own delivery of value – we demand it from project teams, so why not be transparent about our performance ourselves? – and communicating more. I know plenty of PMOs who are fantastic in what they do, yet few know where they sit in the office or who they are! In a nutshell, critical-to-business PMOs are servant leaders, passionate about what they do, and able to adapt to the needs of the business with agility.  

How did your passion for projects start? What's the thing you love the most about your job?

My career was born in a project management consulting company; thus I was, in a way, infected by the energy and passion for projects of my colleagues and mentors. I was lucky enough to learn from individuals who are very experienced and knowledgeable and invested in my professional and personal development. If there is advice I can give to anyone starting in the project management world: get a mentor. It is an enriching life experience. Working as a project lead, consultant, and trainer in project management, what I love the most is the diversity of industries, project types, and dimensions I get to work with. I am always learning something new every day, and I love it. One day I’m doing a PMO maturity assessment to a company dealing with nuclear waste in the North of England, the next day I’m delivering a workshop to a Council in a remote location, and next flying to Germany to train a company on using a PPM tool. Yes, it can be tiring, but I would be lying if I said I didn’t like this busyness. I’m very lucky to be able to work in an industry I love, and to have learned and worked with so many amazing companies and people to date. It’s no coincidence that I call myself The Lucky PM!  

What's the biggest issue you see in the PM community at the moment?

There are many aspects that are worth mentioning but I’d like to stress three of them which are not exclusive to the PM community but are still very visible amongst us. One is our resistance to think beyond the status quo, the norm. We need to start thinking more critically in project management, challenge more, question more. In a time where there are information overload and a growing body of knowledge, we shouldn’t just accept solutions “prêt-a-porter”, fast-thinking and oversimplifying the reality but instead, explore different perspectives and not rush into solution-mode when, sometimes, not even the problem is clear or when there is no simple solution. The second one has to do with a view of project management as a “just-do-it” discipline and project practitioners as doers. I think there is much to lose for the profession if we remove our responsibility from the front-end and legacy of our projects. Projects change the world, literally, and as the saying goes “with great power comes great responsibility”. Unfortunately, I often see the power but not always the responsibility. To this end, my third rant of the day relates to the missed opportunity for more projects for humanity with a global impact. With our competencies, we are in a privileged position to make a difference and to start driving a consciousness for project management. With the recent pandemic, some good examples start to show but we still need more sustainable, responsible project management. After all, our projects are our future. We should ensure that we are making it a good one.    

What's in your opinion the impact of the COVID 19 pandemic on projects? How is this situation changing the community?

There is no question that COVID 19 changed the world as we knew it to the point that we can talk of a BC (before COVID) and AC (after COVID) time. Projects were no exception. Some were canceled, postponed, portfolios of work and budgets had to quickly be reviewed. This is not entirely a bad thing though. For a long, we have heard about the necessary revolution in working practices, with digital nomads, self-learning solutions, flexible working, remote teams, etc. Whether organizations like it or not and were prepared or not, the time has come for us to trial the concept. And surprise: for many organizations, it’s working! We didn’t need all those meetings, all that office space, all the structure after all. Work still gets done if done from home. The same happened with digital transformation. After years of preaching about it, companies were “forced” to finally do something about it. And projects for humanity are being born out of crisis too, such as Tech4COVID19 or PMOsHackingCovid, which makes me proud of working in project management, with people at heart, as it should be. I think that, as a community, we will become more flexible, aware, antifragile, and, above all, more human and conscious of one another from COVID 19.  

What's your advice on how to solve/face this situation?

I don’t want to romanticize the problem and I’m not even sure if there is a solution. For the time being, I think COVID will remain a situation to cope with rather than to solve, at least until a vaccine is available. But I also believe that we are not defined by the challenges we might face but by how we respond to them. Therefore, I think this crisis gives us a chance to decide to look at its positive impact. The crisis can unite people. Over the past weeks, particularly in the countries more impacted by the virus, we have seen a multitude of gestures of kindness, collaboration, and solidarity (such as to thank the tireless work of healthcare professionals), that remind us that we are just one big family. We share the same concerns, the same anxiety, the same dreams, and fears. We learn, suffer, and are inspired by each other, no matter where in the world. We are more resilient than we think. We are all in this together. The fact is that COVID 19 is still out there so we might as well do something of value with it, even if it is just about providing encouragement, assurance, and support to others. Let us use this opportunity to reflect and review our priorities, including in our PMOs! To acknowledge our fragility and to value what matters most. To say “thank you”, “I’ve got your back”, and “great job!” more often. To use our time more wisely and to re-invent ourselves. Together. Let’s not ask what would happen if the world ended with this crisis but what can we do differently in our projects and lives if the world re-started. This is our wake-up call. An opportunity not to be wasted.  

Marisa Silva

Marisa Silva, also known as 'The Lucky PM', is an experienced PMO and PPM adviser, educator, author, and international speaker. She is a passionate advocate of the value of PMOs as business partners and enabling strategic change delivery!