News

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!  

We now know that innovation is the key: innovation in products, services, in the way of working; we no longer accept phrases like "we do as we always have" and "Agile" seems the magic word that can help us. Especially in the world we live in today, with a ongoing global pandemic, we are living in a fast-changing business world. Traditional approaches do not improve flexibility and are limited in offering help to current uncertainties. Is Agile the answer?  

What is Agile?

As the volatility of our business environment increases, organizations seek to respond to these changes effectively. One of the answers is the introduction of Agile methods. This approach is considered more suitable for uncertainty and change than traditional approaches.

Agile is not a ‘one size fits all’ and offers you different frameworks to apply to different situations.

Agile has its roots in the world of software but has now developed far beyond, involving the world of project and service management. Agile is more than a set of methods, practices and behaviors. Agile is transforming the world of project management and is radically changing the way in which business and IT work together to successfully face change. It is increasingly accepted that businesses need to be Agile to succeed, and that Agile approaches are best suited to today’s fast-changing world. Innovation requires a change in culture for many organisations as embracing new ways introduces high risk, including the risk of failure. Agile is about delivering value for an organisation, however that value might be defined.  

Agile project management

Agile project management provides that projects can be managed and implemented in small work packages. Agile projects bring value to the business through frequent product deliveries called ‘features’. In a traditional waterfall methodology the requirements for the project should be documented in advance. Only later (the design) is the design of the entire solution completed, followed by product development, testing and finally implementation. If this whole process takes a year to complete, the business sees no tangible value until the end of the project. Within an Agile project, however, the items are created in small work packages called sprints. Agile is an excellent method to use when the business needs frequent changes or wants to receive the benefits of the product (s) first. With Agile you can focus on the needs of the business at the present moment and, if the requests change, they can be easily inserted in the next sprint. Any project can use Agile if deliverables can be produced and implemented in a short period of time. Do Agile projects create build capabilities? One-piece or a few pieces at a time.    

5 features of a successful Agile project

1. Sprints (or iterations) last from 4 to 12 weeks
2. Direct communication has greater weight than documentation - you want to produce a product, not the product documentation
3. Team members work in the same environment or use virtual tools to be together
4. A sponsor 100% dedicated to the Agile process is necessary
5. The changes to the requirements are expected and accepted

There are other features necessary for the operation of Agile projects that do not differ from traditional projects:

• Have a vision for the end game
• Follow a universally accepted project life cycle
• Requirements must be understood
• Use a shared and managed program
• A dedicated team
• Communication with stakeholders is essential

  Ready to go Agile but not sure how? QRP organises a FREE webinar with expert Kim Delgadillo to explain you about the different Agile Frameworks. Register here.

Agile has become mainstream on a global level and across all industries. Although it started in IT development, Agile is now being used far outside the initial scope. Today we can talk about Agile companies, as the Agile mindset has entered all enterprise layers. Some companies are leading the way for many years now but even more, are currently going through or embarking on the Agile transformation. As these Agile transformations also mean massive investment, it is good to understand why organizations decide to invest. And next to ‘why’, the first fundamental question is: what is Agile? Agile has many meanings, and if you would ask ten professionals, you would probably get ten different answers. On top of that, there is the Agile lingo and a myriad of Agile frameworks out there, which is only adding to the confusion that some people and companies experience.  

Agile definitions

Agile is a broad concept, which can make it challenging to identify and understand the real meaning of Agile. Agile is best described by a number of definitions. The different definitions show different perspectives on what Agile is, and each of them answers the question partially. A lookup in the dictionary will give you: “the ability to move quickly and easily”. On an enterprise level, this is reflected by being able to change direction if the set destination suddenly changes. The level of agility is currently being tested by a terrible global virus attack. It is forcing organizations to change and adapt quickly. We see that Agile companies are clearly taking a head position.  

The Agile Manifesto

The Agile Manifesto, published in 2001, the kickstart (or acceleration) for a number of Agile frameworks to evolve and become more popular. The Agile Manifesto contains 4 values and 12 principles. The values are key and are defined as follows:

• Individuals and interactions over processes and tools
• Working solutions over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

According to the Agile Manifesto, being Agile means respecting the values and following the 12 principles. Easier said than done, as many companies have embedded blocking factors to an Agile way of working as part of how they do things. Meaning that even when you are very motivated as an individual to work in an Agile way, you cannot remove company constraints and culture barriers by yourself.  

Agile mindset

A mindset based on the Agile Manifesto, not well known but very essential. This mindset enables faster and better decision making. Speed on the decision side means a better flow of activities, which means faster delivery of business value. Ultimately that is what agile is all about. In business, you need to make decisions based on incomplete information. Waiting until we have 90% of the info probably means waiting too long. Being able to decide with for instance 70% of the info, will improve cycle times of operations and projects. And even if this might increase the number of errors, the Agile mindset will enable smoother corrections in case of wrong decisions.  

Agile as an umbrella term

Agile is NOT a framework or methodology but instead an umbrella for a wide range of frameworks. All of these frameworks have their origin and scope and are based on the same values and principles. The frameworks are all different. Organizations can adopt a framework based on their unique context and needs. One of the key questions to be answered in an early phase is: what framework or combination of frameworks is best suited for our company? Curious to know more about this? We zoom in into this question in our webinar: The Agile Transformation. How to start?  

Why Agile?

Once we have a better idea of what Agile is about, we can ask ourselves why companies embark massively on the Agile transformation. Agile is everywhere and is difficult to find an executive that does not claim his/her organization should become more Agile. However what this exactly means, is not always crystal clear. At the same time, when asking employees why the company wants to become (more) agile, the answer sometimes indicates there is no real strategy behind the Agile transformation, or at least not fully communicated. The ‘why’ should, in my opinion, always be linked to increased business value. More business value can mean many things and is often related to one or a combination of the following items:

• Higher customer or employee satisfaction
• Revenue growth or cost reduction
• Quality and efficiency improvement or risk reduction
• Specific business problem solving or a contribution to a strategic objective of any kind

The answer to the question ‘why’ should be clear and consistent throughout the enterprise from the floor to the executive level. Proper change management helps a lot for realizing a successful Agile transformation, and this always starts with a clearly articulated ‘what’ and ‘why’.  

When does Agile work?

• Once you start your Agile transformation, how do you prove it is contributing to for instance higher customer satisfaction and revenue as other factors will also influence these?
• And how do you ensure your Agile transformation benefits outweigh the cost without going too fast or too slow?

Both are key questions for a successful transformation. But, as in all transformations, going step by step remains key: understanding the ‘what’ and ‘why’, building skills & expertise, visiting other companies to see & learn, defining the transformation approach and choosing the right framework are part of the first big step. And don’t forget an experienced coach who has learned from making mistakes and taking wrong decisions!    

Kim Delgadillo

Kim Delgadillo is a Lean & Agile coach that provides training and coaching. His goal is to improve performance. He is still active in his respective field and has a lot of experience at multinationals throughout Europe. LinkedIn

In a virtual project, your team works from different locations. We have seen project teams becoming more virtual for many years - flexible work conditions, external vendors or partners, outsourced teams - and communication is the most important hurdle that keeps popping up. Effectively communicating within your project team is more cumbersome when your project team is not co-located. A lot of the difficulties lie in the soft aspects of communication: you often lack the visual cues on how a spoken message is received. In written communication, the sender has the tendency to be more negative in communicating the message and the receiver has the tendency to interpret the message more negatively than intended. The hardest part in remote communication is to create that feedback loop that ensures a message is received as it was intended. When it comes to the mechanics of communication, however, your approach in a virtual environment should actually be quite similar to a situation where everybody is working from the same place. The problem is that many inefficiencies do not surface as much when you are working in the same building, as you often run into each other or can quickly swing by someone’s desk. But as usual: time spent in preparation is time gained in execution. What your project needs - virtual or classic - is a Communication Management Approach.  

PRINCE2 the Communication Management Approach 

As in many project management challenges, PRINCE2 gives guidance on how to tackle communication challenges. PRINCE2 is the de facto standard project management method in many parts of the world. And on the topic of communication, it provides guidance in the form of the Communication Management Approach, as well as on how to use it throughout the project life-cycle. PRINCE2 is often considered document-heavy or bureaucratic, but that is a misinterpretation. I rather use PRINCE2 as a checklist of things I need to clarify and agree upon with my project stakeholders. My favourite quote from the PRINCE2 manual (p. 27) states that “it is important to remember that effective project management requires information (not necessarily documents) and decisions (not necessarily meetings).” The situation will determine how well documented this information should be, and whether decisions should be taken in a meeting or not. So let’s have a look at the Communication Management Approach PRINCE2 proposes and how it helps in managing virtual projects. Strictly speaking, the Communication Management Approach deals with the means and frequency of communication with parties both internal and external to the project. I will not go into detail on the external stakeholder identification, analysis, and engagement, but rather focus on internal communication, i.e. with the project team.  

Tools & Techniques

PRINCE2 is agnostic of tools, so there are no recommendations in the guidance. My advice typically boils down to “do not overthink it”. After all, a fool with a tool is still a fool. So look at the tools that your organisation already uses first. Don’t rely too heavily on email; email is a bad medium in general, but a bad habit is hard to kill. The email has a tendency to lead to communication overload. It is far more useful to use chat tools for written communication, it’s more informal so lowers the effort people spend on the format. That leaves more time for content. Next to a chat, it is also good to have a tool for online meetings, typically videoconferencing, that everyone can easily access from different devices. A screen sharing option is mostly included and very useful.  It’s important to have good agreements on how the tools will be used. As a project manager, you should make the guidelines explicit and lead by example. Things to consider are the use of webcams or the mute button for the videoconferences, or the topic structure and use of mentions in the chat. Also, make sure that it is clear which tool will serve what purpose - this is especially important when there are several tools at hand that can do more or less the same.  

Records

You should keep track of communication records: decisions taken, actions agreed, topics that need to be discussed… Again, email is a bad medium. But you do not necessarily need fancy tools: a lot can be done with a simple document on a shared location that everybody can access. Make sure that everybody knows where they can find what information. Also here it is probably easier and safer to use the technology that your organisation already provides, rather than shopping for new solutions.  

Timing

Agree when you or others should communicate. That includes the meetings you will have. Online meetings tend to be much more exhausting than offline discussions, and people working from home sometimes have other distractions, like children. So, in a virtual setting even more so than in a classic situation, it is important to keep the number of meetings to the strict minimum! Clear roles and responsibilities and well-defined deliverables will help to reduce the number of synchronous sessions with several people online.  

Roles & Responsibilities

Make sure to clarify who is responsible for what communication. This means organizing meetings or administering chat groups, but also who should respond to what type of questions. The more you clarify these things upfront, the smoother your project will run.  

Informal communication

Finally, the above is mainly dealing with formal communications. When I am coaching project managers, I tend to advise them to choose a desk close to the coffee machine. However, it won’t make sense, when working from home, to sit close to your own coffee machine. In an organisation, the coffee machine has the informal function of eliciting real conversations: here you get the real status, the real issues and risks and the real learnings from project team members. So, do not forget these informal moments - try to include them in your routine. That means inviting people for a one-to-one video chat just to have a chat, or organizing a virtual apéro where everyone shares a drink. The drawback of virtual projects is that you need to force some formalization in informal encounters.    

Stijn Janssens

Written by: Stijn Janssens is a trainer and consultant. He is PMP, PRINCE2, MSP, MoP, P3O and ITIL certified. He has a lot of experience in strategic innovation and the ‘change’ part of organizations. He is not religious about PRINCE2, but very convinced!

Managing virtual projects is nothing new. The world has been becoming flattered for many years and most project managers will have had teams working from different locations. For example companies with different office locations or vendors that were not on customer premises. The difference in the current COVID-19 situation is mainly that from a few locations where teams were still working physically together, we have been all of a sudden thrown into a setup where everybody is literally on his own. When confronted with a project management challenge, I typically first look at PRINCE2. PRINCE2 is one of the most widely used methods for managing projects worldwide. As always, PRINCE2 is only part of the solution. There is a lot of leadership and soft skills involved in managing virtual projects, and PRINCE2 cannot help in that respect. This is because - although extremely important - it is impossible to codify soft skills and leadership in a method. Managing virtual projects from home also includes a proper work/life balance, however, that is not a subject I like to cover in this post.  

PRINCE2 principles

PRINCE2 approaches project management with 7 principles, 7 themes and 7 processes. The principles are non-negotiable guidelines and practices that apply to every project, no matter its size, type or industry. The seven principles are:

• Continued Business Justification
• Learn from Experience
• Defined Roles and Responsibilities
• Manage by Stages
• Manage by Exception
• Focus on Products
• Tailor to suit the project 

While all principles remain applicable to a virtual project, I want to highlight 5 of these principles that are particularly important when moving to a virtual setting. While working remotely it is of importance to be aware of not creating an overkill of synchronous moments. These are often in the form of videoconferencing and can take a lot of your time, especially when the audience grows larger. Several principles will help to reduce the number of meetings, and to keep the remaining meetings short and to the point.  

Focus on Products

The Focus on Products principle requires projects to be output-oriented rather than work-oriented. For a project, this means that success is driven by having a common understanding of what the project will produce and the characteristics of these products. In everyday speech: the requirements need to be clear, as well as the criteria against which they will be evaluated. The same goes for the work of your project’s teams or individual team members: it is important to agree on what everyone will deliver rather than on what everyone will do. As a project manager, you want to remain in control whilst not micro-managing. That is why it is important to agree with your teams on concrete outputs - deliverables - they will produce by a certain moment. If you manage individual team members directly, it makes sense to have a quick daily check-in. If you deal with teams you probably decrease the frequency to (semi-)weekly. It requires for some a shift in mindset to ask not “what will you do today?” but rather “what will you deliver tomorrow?”. It is a small change, however, it results in both a better alignment of expectations and reassures the project manager that the work contributes to the delivery of the project.   

Defined Roles and Responsibilities

The Defined Roles and Responsibilities principle means that projects should have an explicit structure that provides everyone involved in the project an answer to the question: What is expected of me? If such a structure is absent you risk that more meetings will be needed to raise hurdles and to determine who will deal with it. In a situation where the team members are co-located, the absence of this explicit understanding of who will do what can be more forgiving as the team members can easier speak up and get help right away. However, this is also suboptimal because everybody in the team will be pulled out of their concentration for a moment and it takes some time to get back to the concentration levels from before. So, make sure that all team members know who is responsible for what, so they can address issues directly with the right person. But also make sure that everyone knows what responsibilities they have themselves so they can make the decisions they are empowered to.   

Manage by Exception

Manage by Exception principle provides for efficient use of management time as it ensures that decisions are made at the right level in the organisation without losing control. This is done by delegating authority and specifying ‘tolerances’, i.e. performance targets and permissible deviations from those targets. Then you should also specify an escalation mechanism in case the tolerances are (to be) exceeded. If you do this well, reporting progress is a lot easier and does not need a meeting. We all know the feeling of being in a meeting that should have been an email; having clear targets and deviation boundaries allows you to clearly communicate the status of your work or project in short writing. This way, you will only need a meeting when a decision is needed. This means: when someone will exceed tolerance and a higher level of management should step in.   

Learning from Experience

The Learning from Experience principle requires everyone in the project to actively look for lessons that can be learned from experiences in the project and act upon them to continuously improve. If you are suddenly thrown into this new situation whereby everything happens remotely, it is particularly important to often reflect on how you are handling things. It might be useful to ask all your team members to keep a lessons log, a list of their experiences, and foresee a regular moment to discuss the lessons from the team. By implementing the positive experiences more structurally in your way of working and by resolving negative experiences to avoid these from happening again, you will continuously improve the management of your virtual project.   

Tailor to Suit the Project

The Tailor to Suit the Project principle ensures that the method used to manage the project is appropriate for the project and that the level of control is appropriate to the project’s scale, complexity, importance, and risk. If your situation suddenly changes, as it has with the whole project team working remotely, it is of utmost importance to check whether your standard way of managing projects is still the most appropriate way of doing so. Every project is unique and hence for every project, you will deviate from the standard in some respects. So take some time to think about how your standard project method should be adapted to your virtual environment. 

Stijn Janssens

Stijn Janssens is a trainer and consultant. He is PMP, PRINCE2, MSP, MoP, P3O and ITIL certified. He has a lot of experience in strategic innovation and the ‘change’ part of organizations. He is not religious about PRINCE2, but very convinced! LinkedIn