News

The most recent version of ITIL, ITIL 4 introduced a lot of new concepts. In particular the concepts Service Value System, Service Value Chain and Value Stream. All these are fundamental in ITIL 4.  The Service Value System (SVS) is a model that shows how all components and activities of an organization work together to create value. The Service Value System can help create a unique and strong direction for the organization. It defines the activities, workflows, controls and procedures needed to achieve the agreed objectives.   On the other hand, the value stream is a series of steps an organization undertakes to create and deliver services and products to consumers. The Value Stream is different for every organization and needs to be specified.  The new version of ITIL provides a generic reference model to be able to create value streams: this model is called Service Value Chain.  

Service Value Chain

The Service Value Chain is an operating model, which outlines the key activities required to respond to demand and facilitate value realization through the creation and management of products and services. Each organization will allocate the Service Value Chain according to their business needs. The SVC responds to the trigger, the question and the need for an organization. The six main activities of the ITIL Service Value Chain are;

• Plan
• Engage
• Design & Transition
• Obtain & Build
• Delivery & Support
• Improve.

In reality, the SVC needs other elements to be completed. Even if these elements are not part of the chain: the trigger, or the question, the need that the SVC responds to. Every organization will be able to define its specific Value Stream starting from the referenced Service Value Chain.

Value stream

Different factors are included while creating the value stream, like: 

• Structure of the organization
• The team
• The competences
• The organizational culture

All the above-mentioned elements either influence or determine how the Value Stream is defined. Specific roles and responsibilities, resources and tools will be defined within the value stream. The Value Stream will represent how the organizational model will be used to respond to a specific trigger, need or question. While creating a Value Stream with the Service Value Chain as a base, it is advisable to start from the demand. That way the end result is always a Value, regardless of the Value Stream that we are going to identify. Other important facts about the Value Stream:

• The order of activities is not pre-established and can be different every time
• The Value Stream does not concern a single group but involves several teams
• The Value Stream activities do not only involve IT staff but also includes stakeholders
• Each activity of the value stream has specific support and stakeholder practices.

In order to create Value Streams, it is necessary to know the activities, define their priority and manage the possible involvement of external companies.

ITIL provides the Service Value Chain to identify the Value Streams. The organization always starts from the Service Value Chain and uses this model to identify the specific Value Stream. Once an organization has defined its Value Streams, it is easy to follow the activities and practices. It recognizes the stakeholders involved and the activities required to transform the need into something that generates value for everyone. The ITIL4 Managing Professional module of ITIL 4 Create, Deliver & Support provides an understanding of how to integrate value streams. Activities to create, deliver and support IT products and services and related practices, methods and tools. Find out more! QRP International also organized a webinar about the ITIL 4 module Create, Deliver & Support. Our trainer and ITIL 4 expert Kais Albassir explains clearly how this course can be helpful. Watch the recording for free by clicking here. ITIL® is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

Davina Leysen works as an Attaché project beheer at Belnet (Programme and Project Officer). Davina has created a support base for the implementation and use of the P3O structure at Belnet.  

What's your current job title and what does that mean in practice?

My official title in Crescendo: Attaché project beheer at Belnet. When looking at the P3O definitions, my function can be described as a Project and Programme Officer. I support not only our Programme Manager (Head of the Project Management department) but also our Project Managers. In practice, this means keeping our portfolio database up-to-date, organization of the project board, resource management and overall support to all programme and project managers. If needed, I can also perform some Project Management activities.  

How did you end up in the world of Project, Programme and Portfolio management?

I was originally hired as a member of our purchasing department. As soon as I started working at Belnet, I was detached to work on a big project. My job in that project was to follow up on the delivery of all the orders. This big project was the catalyst to create an official Project Management Office within Belnet. Being able to witness the approach to this major project and the creation of the PMO firsthand, and simply liking the work I was doing, I asked if I could remain on as a permanent member of the new Project Management department.  

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

Project Management is sometimes (too often) seen as a ‘last resort’. Requests to start up a project often originate from an issue with planning and coordinated action. Due to this, projects have to be started very quickly and there is not always the opportunity to plan and document everything as it should. This then results in unexpected turns and possible delays during the course of the project.  

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

The PMO has picked up some slack in the past years, with an overall positive outcome. Our work was appreciated as we got things done, which lead to a more positive view of the work we do. Overall, the positive aspects and added value of project management are becoming more and more known within Belnet. For important and large-scale changes, PMO is consulted in early stages, so the benefits of adopting the project approach are high, and acknowledged. We really see a change in the perception of the project management approach. We’ve noticed that, after the creation of the PMO, the other departments thought project management was ‘too much administration’, and that it slowed down the work that needed to be done. This was a perception, coming from just not knowing what we were doing, why we were working the way we did and how this would add value to the outcomes.  

How did you get everybody involved to create a common approach?

We worked on being transparent and communicating to the whole company. HR gave us the possibility to create our own page on the intranet, that is accessible to everyone. We publish our procedures, approved documentation (Project Briefs, PID’s,…), MOM of the Project Board,… Communication and transparency are key in our day-to-day work, we are always open to receive feedback from our colleagues and take measures to respond adequately to their questions.  

How do you apply P3O and what does the structure look like?

Every quarter, we organize a Project Information Session, where we announce new and closed projects, any major changes and we present between 2 and 4 projects more in-depth. Our newest communication ‘tool’ we introduced is the Project Information Sheet. This is a 2-page document that explains the project in a way that is comprehensible for everyone – from the Purchase department to the technicians of the Networks department. In the last couple of months, we also have installed a consultation group, where different departments are involved, called the Customer Demand Meeting. During this meeting, different upcoming or recently received customer requests are discussed, and the best approach (Project or Business as Usual) is agreed upon. We can anticipate better what is coming our way, and the transversal collaboration between the teams is strengthening our mandate to execute the projects.  

What are three things you’ve told yourself that you would like to learn in the near future to develop yourself and your team?

• Change Management As mentioned earlier, we have started our first Programme. This will cause a great change for a large part of the company – almost everybody will have to adapt their way of working in one way or another. I’ve seen some bad and some good examples of change management over the last three years. Well-organized change management has the ability to lift the positive outcomes of a project even higher.

 

• Improve Excel knowledge Specialized tools for Project/Portfolio Management (used for reporting, budget, timesheets,…) are often very expensive. We try to push the limits of Excel as much as possible, as long as we can. This causes the need for training to write macro’s, create pivot tables and many more.

 

• Resource Management At the moment, we have a Resource Forecast and Resource Actuals (timesheets) for projects. For operational tasks, there is no company-wide system. At the moment, this remains a manually executed task of copy-pasting individual data into a consolidated file, with quite some room for human error. To minimize these errors, I’ve worked together with our ICT department to automate the consolidation.A next step will be to introduce a resource pool system for the whole company. This should enable us to plan out all the projects in our portfolio. If we know how much time employees will be needed for their operation tasks, we will know the capacity that remains for projects, and we can estimate the duration of each project. On the other hand, if a project has a high priority, we can see where adaptations in the division of the operational work are possible.

 

Davina Leysen

Davina Leysen works as an Attaché project beheer at Belnet (Programme and Project Officer). Davina has created a support base for the implementation and use of the P3O structure at Belnet. She is P3O and PRINCE2 certified and plans on getting her MSP certification soon.

The current pandemic is challenging all of us in many different ways. One big challenge is that almost everybody works remotely. Meetings are cancelled, plans have changed and business, as usual, is interrupted. Also, we as QRP International have to alter the planning of our courses. However, the pandemic was also the last push we needed to finally execute the plan we have had for a long time; Virtual Classrooms. As of now, we can offer all of our courses virtually. We have the same teachers, the same challenging learning methods and the same energy. The only difference, you and the other participants are all in different locations.  

Our Virtual Classroom solution

We do our utmost to make our clients happy. It is with this core value in the back of our heads that we developed the Virtual Classrooms. We thought about giving you the best possible learning experience. In this light, we decided not to just copy the on-site classroom courses, but we shuffled it up. Our Virtual Classroom courses are made out of a mix of live training and homework. This is because we do not think you will be happy to sit behind your webcam for eight hours straight. The morning or afternoon sessions are taught live and that is where the trainer explains the methodology. This is your opportunity to ask questions to the trainer and engage with the other participants. The other part of the day, you will actively apply all that you learned while doing the homework. To do this homework we use tools that will make it easier for you to study and that have AI-driven exam simulations. After finishing the course you will be more than ready to complete the exam!  

High-quality solution

The Q in QRP stands for Quality, so quality is what we deliver. We use a state of the art e-learning software and provide you with a course that is in line with our quality standards. As you expect, the course is provided in all local languages. The Virtual Classroom courses are taught by our trainers, experienced and still active in their respective field. The courses include examples of real-life situations and are adapted to the group of participants in order to offer them the best possible experience.  

Why now?

The changes in your business, as usual, might leave you with some time left on your hands. Once everything will go back to normal you will probably be challenged with an overload of new projects, programmes and software development. Now is the time to build up the expertise to face these coming changes so why not follow a course, get a certificate and change your business downtime into business uptime? QRP develops professionals to facilitate change. So we have been able to provide you with a solution during this challenging time for all of us. We offer our Virtual Classrooms next to our e-learning solutions and also hope to start providing you again with classroom courses on-site soon. If you want to know more, download our Virtual Classroom brochure here. Or contact us directly.

PRINCE2 Foundation - Virtual Training

AgilePM Foundation - Virtual Training

ITIL4 Foundation - Virtual Training

Virtual/Classroom Course Calendar

The Scrum Developer is the professional responsible for creating the project deliverables, together with the rest of the Scrum team. As described in the Scrum Guide, there are three core roles in Scrum, responsible for meeting the project objectives:

• the Product Owner,
• the Scrum Master
• the Development Team.

The Development Team is made up by professionals who work to deliver a potentially releasable increment of “Done” products at the end of each Sprint. These professionals are Scrum developers. The Development Team is responsible for:

• understanding the business requirements specified by the Product Owner
• estimating the user stories in the sprint backlog
• developing the product/service (deliverables).

Each Scrum Developer is responsible for delivering a functional element (also known as a chunk) of the product at the end of each sprint.  

Scrum Developer responsibilities 

When working for a Scrum project, Scrum Developers have the following responsibilities:

• Achieve the goals defined for each sprint
• Attend daily scrum meetings reporting the planned tasks for each day
• Assure to Product Owner and Scrum Master that the allocated work is being performed as planned
• Ensure a clear understanding of epics and personas
• Provide inputs on the creation of User Stories to the Product Owner
• Understand the User Stories
• Estimate User Stories approved by the Product Owner
• Commit User Stories to be done in a sprint and develop the list of tasks based on the User Story
• Report to the Scrum Master impediments to the progress of the project, if any
• Agree on the length of the sprint with the other Scrum Team members
• Develop the Sprint Backlog and the Sprint Burndown Chart
• Create the deliverables
• Update Burndown Chart, Scrum Board, and Impediment Log
• Submit Change Requests, if any
• Participate in Prioritized Product Backlog Review Meetings
• Identify improvement opportunities, if any, from the current Sprint and agree on any possible improvements for the next Sprint
• Participate in the Retrospect Project Meeting.

   

The necessary skills for a Scrum Developer

A Scrum Developer should have:

• technical knowledge and skills (software analysis, coding, software programming or testing)
• deep knowledge of the Scrum framework and an understanding of how to implement it effectively for any software project
• excellent team skills, necessary for the collaboration with the other team members.

Other important soft skills, highlighted by the Scrum Guide are:

• Highly Motivated
• Proactive
• Self-organized
• Independent
• Responsible
• Intuitive
• Goal-Oriented

Sources: Schwaber and Sutherland, The Scrum Guide; © 2017 SCRUMstudy™. A Guide to the Scrum Body of Knowledge (SBOK™ Guide).

A portfolio is defined as a set of projects and programmes that are managed by an organization. A portfolio can consist of multiple programmes and/or multiple projects. The projects within a portfolio can also be different from each other. However, the programmes within a portfolio are formed by related projects. The portfolio represents the implementation of an organization’s strategy. Portfolio Management is the coordinated management of the projects and programmes that help achieve specific business objectives. Portfolio management defines priorities based on business objectives. Projects and programmes that are to be implemented are based on these priorities. The selected projects and programmes will together enable the most effective balance of creating business value, the risk level and resources to be used. Where project management serves to correctly manage projects, portfolio management serves to choose the right projects. In the MoP (Management of Portfolios) guide, Axelos defines portfolio management as; “a coordinated collection of strategic processes and decisions that together enable the most effective balance of organizational change and business as usual.” Portfolio management characteristics:

• Portfolio management is focused on the return of investment (ROI) and the effective implementation of change through both programmes and projects.
• Portfolio management is used to ensure an excellent allocation of resources (human resources, assets, materials, funds and services), to achieve the key strategic objectives.
• Portfolio management supports organizations to choose the suited future projects and programs by providing structured information to managers.
• Portfolio management is used to ensure that the priority of projects and programmes is periodically reviewed in order to invest resources according to the strategic objectives of the organization.

 

Differences between Program and Portfolio management

In the blog post ‘What is Programme Management,’ we explained the meaning of a Programme and Programme management. According to Axelos a Programme consists of one or multiple projects and serves to meet one or more strategic objectives while focusing on enabling change. Programme Management is the management of all related projects that together form the Programme. The main difference between Programme and Portfolio management is that Programme management is about similar projects. Portfolio management, on the other hand, manages projects and programmes within a wide range and even different fields.  

Portfolio management: why it matters

Portfolio management can allow organizations to:

• Better allocation and use of resources between projects or programmes
• Better communication between projects and programmes
• Better coordination between projects and programmes

According to Axelos, "in an ever faster and more demanding world like today, portfolio management can help organizations successfully implement change and achieve their strategic goals." * Today more than ever organizations that want to keep up with changes and innovations need an approach that focuses not just on projects and programmes but on the portfolio. The challenge is to find the balance between managing business as usual and change while ensuring that the business and the whole organization are willing, ready, and capable of supporting and assimilating change. *Axelos: What is Portfolio Management

During the interview with Mélanie Franklin, Co-Chair of the Change Management Institute UK, she highlighted how important it is to manage change in an Agile environment. The changes in Agile are complex and continuous. In an Agile environment, innovation is continuous which will take other processes out of practice. Due to this, changes are complex and become more frequent as time passes. Past changes soon become part of the ‘business as usual’. In this post, we will provide you with the expert’s advice and techniques to help you plan your change in Agile.  

How to plan Agile?

Agile talks about evolving solutions, which basically means that within Agile you constantly have to re-plan. Instead of planning just the next step, in Agile planning is done looking at the final goal. It is important to understand the destination so one can orient the route to get there. In this way, it becomes easier to define the things that will really help to achieve the final goal. The work to be done is decomposed in a decomposition scheme, where the final goal is divided into small components. Decomposing the work to be done, means to look at the project from a bottom-up approach. Seeing these small components, it becomes easier to prioritise, identify the timespan, resources and communicate to the business. In Agile planning is a team responsibility, all resources are involved so that they can actively contribute to the planning. The driving question to Agile planning is ‘are we really doing the most relevant thing to achieve our final goal’? Planning in Agile is something extremely difficult and constantly changing. The planning starts high-level, by defining the desired destination. Step by step, by questioning the usefulness of undertaken actions, Agile takes you to plan more and more detailed. With Agile the level of detail grows progressively.  

Behavioural change: what is it and why is it important?

One of the biggest challenges in Agile planning is taking into account behavioral change. Resources are not robots and any type of change will impact their way of working. For example, employees can lose familiarity with their work or need time to understand new techniques and/or systems. The transition activities take time and there needs to be room to make mistakes and to practice new ways of working. This means that while planning, not only emotional effects must be taken into consideration, but also the overall change acceptance. Together with project activities, it must be made sure that the resources are ready for new activities, new ways of working and that they understand the final goal. However, it often happens that technical activities develop much faster than behavioural change. Melanie Franklin identifies the three elements of behavioural change; test new ways of working, understand how to do things and create new habits. Attention should be both on the project activities as well as on the behavioural change. These two should be synced in order to avoid resources not being able to use new features or practices. Therefore at the end of each iteration phase, there must be an agreement on how the current and upcoming change will be managed. This is a collaborative activity because it involves both those responsible for the outcome as well as the users.  

The importance of punctual delivery

Respecting the set timeframe for product deliveries means knowing when change can be expected and when improvements should start being visible. Sharing the activities and meeting deadlines also means answering the expectancies of the resources on the new way of working. It is important to respect delivery promises because change is always a source of stress; delay could increase the emotional impact of the change. Respecting the set timeframe is therefore fundamental. But how to decompose the total timeframe? M. Franklin suggests different levels of planning, see the image below.   The first element is the timeline exists of different iterations and at the end of each the outcome is identified. In order to achieve these milestones, M. Franklin has identified the following steps to follow;

1. Getting started
2. Making progress
3. Realising benefits

  1 Getting started This step is more or less a brainstorming session about all the activities that need to be done. In a real Agile environment, this would be called the ‘user story’. It is essential to cover both the ‘delivery’ and the ‘transition’ parts of the change management activities. This activity is collaborative and therefore an opportunity for everyone involved to understand the approach to work and timing. 2 Making progress It includes all the changes in the working procedures, both technical and changes in ways of working. At the end of this step, the parts of work are reviewed and the elements of change are assessed on their quality and effectiveness. 3 Realising benefits The final step is used to analyse the output so far. Benefits are taken into use and all that is no longer needed is eliminated. This step is also important to include all resources and to make room to thank them for the work that has been done. This creates a motivating environment for all team members. These steps offer a repeatable structure for each iteration that can be used to plan the elements of your Agile changes. Curious to know more? Read the article: “Change and opportunities in Agile Change Management: Interview with Melanie Franklin” SOURCE: How to plan and Agile change initiative, APMG International