News

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

We all know that DevOps is a transformation of both people and culture. Breaking down the so-called 'wall of confusion' between Dev and Ops means collaboration and DevOps encourages a culture of collaboration and learning. DevOps wants to build cross-functional teams and, of course, it requires practical specialists. However, DevOps is not a specific job title or team.  

Is DevOps Team really necessary?

Talking about the 'DevOps team', the industry is divided on whether a DevOps team should exist or not. The article “The Industry Just Can’t Decide about DevOps Teams” * showcases different opinions. The most popular opinion is that DevOps teams are an antipattern: they can create additional silos and, more in general, all people in an organization should subscribe to the DevOps culture. Theresa Naete, in “Break down DevOps team roles so you can actually get to DevOps” ** says:

“The point is that we are not achieving DevOps if we are still siloing teams. (…) In this world, Dev and Ops are now on the same team. Let me repeat that: it’s the same team. What some of us don’t understand is that culture is paramount and primary to tools. This culture includes breaking down the DevOps team roles, silos and working barriers so any chosen tools can then be optimized to achieve our desired results.”

But there are also supporters of the idea that DevOps teams are an effective way of transitioning to a new way of working and, despite the fact that the majority of the industry thinks teams are not the right approach to evolving DevOps capabilities across an organization, the DevOps teams are on the rise. The goal of DevOps within an organization is to improve the delivery of value for customers and the business; different organizations could need different team structures in order to create an effective Dev and Ops collaboration. This means that the ideal organizational structure for implementing DevOps depends on many variables.  

DevOps roles

As we said before, there is no one-size-fits-all structure for a DevOps team (or we could say there is no such thing as a DevOps team). Roles and responsibilities will vary according to your organisation: the most important thing is to identify key roles and responsibilities and have the right-skilled member to cover them. According to TechBeacon*** the most common DevOps roles, that are pivotal for any organisation that wants to adopt a successful DevOps approach, are:

• DevOps Evangelist: the person who promotes the benefits of DevOps across the organization. He/she is passionate about DevOps and his/her role is to ensure the back-up from development and operational teams. The DevOps Evangelist is your DevOps Leader.
• Release Manager: sometimes known as the Release Engineer or Product Stability Manager; responsible for overall progress, he/she coordinates and manages the product from development all the way to production.
• Automation Architect: also called Automation Engineer/Expert or Integration Specialist; he/she analyzes, designs and implements various strategies for the product’s continuous deployment. This role is critical because it ensures a reliable environment that is fully automated and free from obstacles.
• Software Developer/Tester: of course this role is at the heart of a DevOps organization (the Dev of DevOps!). But in a DevOps environment, the developers are responsible not only for turning new requirements into code but also for unit testing, deployment and ongoing monitoring.
• Experience assurance (XA) professional: if in the 'classical' software development Quality Assurance (QA) has a vital role for the successful delivery of the final product, in DevOps it evolves in Experience assurance because this role also needs to ensure that all new features and functions are released with the end-user experience in mind.
• Security Engineer: he/she works side by side with developers, making the under development product secure.
• Utility technology player: traditional IT operations or systems administration professional who focuses on keeping the servers running; he/she operates effectively across development platforms, networks, databases, servers and tools.

 

DevOps Culture

DevOps is about sharing and learning so as important as having a skilled team member, is having an ambitious and open-minded team member that is constantly looking to change and learn. These are the three key characteristics for a DevOps professional:

• a good team player, who fits well in your organization’s culture;
• a curious person, who wants to experiment over and over and keeps on trying and failing until he/she learns what will work: DevOps encourages responsible failure;
• an adaptive professional, who can embrace change with a positive mindset.

    Copyright 2017-2019 PeopleCert International Ltd. Other sources: * Helen Beal, The Industry Just Can’t Decide about DevOps Teams ** Theresa Naete, Break down DevOps team roles so you can actually get to DevOps *** 7 key DevOps roles you need to succeed What Team Structure is Right for DevOps to Flourish?

QRP International is pleased to announce its partnership with TempTraining, the continuing education fund for temporary workers.

If you work on a temporary basis and would like to take training in Project or IT Management, you can take advantage of subsidised training through Temptraining.

Who can benefit from it and which courses can be subsidised?

Temporary workers who are subject to the Collective Labour Agreement (CCL) for the loan of personnel are eligible. You can receive up to CHF 5,000 for further training and up to CHF 2,250 for compensation for loss of earnings.

Temporary workers thus have the opportunity to update their skills or specialise in their professional field.

Temptraining supports continuing education in various fields, including IT and economics. Our Hermes, ITIL and PRINCE2 courses fall within these two areas. You can choose between virtual or on-site courses in Geneva and Zurich in English, French or German.

If you would like to follow one of these trainings, you can submit an application before the training takes place on the TempTraining portal.

The calendar of our QRP courses on Temptraining can be consulted from the TempTraining site, filtering by training institute and selecting QRP CH Sagl.

What are the requirements to get access?

If you have worked on a temporary basis for at least 88 hours in the previous 12 months you can benefit from Temptraining. Certain additional conditions must be met for your continuing education application to be approved.

Why choose QRP for your Temptraining funded training

• Over 20 years of experience
• More than 30,000 certified professionals
• Only accredited courses
• Our trainers have an average rating of 9/10
• Leaders in Best Practice
• Specialists in IT and PPM

Would you like to receive support in choosing your funded training? Write to us: switzerland@qrpinternational.com.

AXELOS has just launched the last two modules of ITIL 4 Managing Professional Stream: ITIL 4 Specialist: High Velocity IT (HVIT) and ITIL 4 Specialist: Drive Stakeholder Value (DSV). With the publication of these last two modules, the ITIL 4 Managing Professional Stream is now completely open to the public! ITIL Managing Professional targets IT practitioners working within technology and digital teams across businesses. The Managing Professional (MP) stream provides practical and technical knowledge about how to run successful IT projects, teams and workflows.  

ITIL 4 Specialist: High Velocity IT (HVIT)

The module ITIL 4 Specialist: High Velocity IT is aimed at practitioners who are now confronted with a world of more digitally-enabled organizations and who want to become more valuable and remain relevant in this new era. The way digital technology contributes to enterprises today requires a different way of thinking, working and a new concept of high-velocity IT. HVIT means professionals should be able to make faster decisions about IT changes. It’s not about speed alone: it’s also about what you need when you need it, which is more dynamic and tailored to the user/customer. Working with complex adaptive systems, practitioners can’t rely on pre-determined processes; rather, it’s about taking small, experimental steps to see what works. This needs both a mindset change and a decision to move away from traditional root cause analysis. The High-velocity IT approach in ITIL 4 is a radical rethink of how to operate in ITSM: it means reconstructing service management – by taking it to bits and putting it back together to improve the ways of working. Looking for a way for making your organization digitally-enabled? ITIL 4 Specialist High Velocity IT training    

ITIL 4 Specialist: Drive Stakeholder Value (DSV)

The ITIL 4 Specialist Drive Stakeholder Value module is about the engagement and interaction between service providers and stakeholders and the conversion of demand to value via IT-enabled services. ITIL 4 also encourages the service provider to help the consumer to improve: the “consumer” is encouraged to adopt service management best practices as part of the product development relationship to elevate mutual capabilities and thereby increasing the co-created value. As ITIL now includes consumers and producers together in multi-dependent workflows and systems, this module is focused on helping practitioners increase stakeholder satisfaction via the best service offerings; something that is essential to business success in today’s highly competitive landscape. ITIL 4 Drive Stakeholder Value takes a higher-level view of what needs to happen across all four dimensions of service management to create and manage effective and streamlined services. Interested in maximizing the consumer experience? Find out more now about QRP's ITIL 4 specialist Drive Stakeholder Value (DSV)     With digital products and services, value is only realized when the users act on decisions that have been improved by the information they have derived from the digital products. The latest iteration of ITIL responds to the fast pace of technological change that organizations are now experiencing. It allows practitioners to progress their existing expertise in ITIL and capitalise on the opportunities that are arising from technological advances. Furthermore, ITIL 4 supports practitioners in carrying out best practice with these services and gives them the tools to take part in this global digital transformation.   Would you like to know more about the other two modules of ITIL 4 Managing Professional Stream? Here you find the pages on these topics!

• ITIL 4 Strategist Direct, Plan & Improve
• ITIL 4 Specialist Create, Deliver & Support

A Business Case describes the reasoning behind starting a project or activity. It is often presented in the form of a well-structured written document, but sometimes it can take the form of a presentation or a simple verbal agreement. The logic of the business case is that whenever economic, tangible or intangible resources are consumed, this should be in support of a specific business need.  

What is a Business Case?

A Business Case represents the justification of a project and includes timescales, costs, benefits and risks. The continuing viability of a project is tested against the Business Case. It offers useful information that helps to determine whether a project is (and continues to be) desirable, feasible and achievable.  

What is Business Case in Project Management?

Often during the course of a project, the focus is on what is being done and how losing sight of the ‘why’. Business Case is an essential element because it defines why it is worthwhile to continue the project. The Business Case is used to document the justification for the execution of a project based on the estimated costs and benefits, taking in consideration the possible related risks. Within the PRINCE2 approach the Business Case is seen as a test for the viability of the project; answering the question ‘is the investment still valid?” The Business Case is not static: it is maintained for the complete course of the project and constantly adjusted for new information on costs, risks and benefits. Within the PRINCE2 approach, the Business Case is usually developed at the beginning of a project and maintained for the complete lifecycle of the project. The Business Case is subjected to formal verification by the Project Committee at each key decision-making moment and confirmed during the period in which the benefits are confirmed.    

Composition of the Business Case

The Business Case has to describe the motive to undertake the project. It has to contain the following elements:

• Executive summary: highlights the key-points of the Business case and must include the benefits and the ROI (return of investment).
• Reason: elaborates the reasons why it is necessary to undertake the project and how the business strategies and objectives are included.
• Business options: analysis of the possible options; no initiative, minimum action or take action.
• Expected benefits: the benefits that will be delivered by the project, expressed in measurable terms. Both qualitative and quantitative benefits are mentioned, in line with the defined business benefits. It is important to establish the current state of the benefit in measurable terms in order to be able to evaluate progress after completion of the project. Measurable benefits are also used to establish the methods and moments for measuring improvements.
• Expected dis-benefits: The measurable decline resulting from an outcome perceived as negative by one or more stakeholders. Dis-benefits are consequential effects that reduce one or more organizational objective. Dis-benefits have to be assessed and incorporated in the investment assessment. The difference between dis-benefit and risk is that the latter has a level of uncertainty, the dis-benefit has not.
• Timescale: Execution times of the project in which the benefits should be realized.
• Costs: Summary of the costs, including the current operating costs and the maintenance costs of the project in respect to the financial plan.
• Evaluation of the investment: compares benefits and dis-benefits with the costs of the project and the ongoing costs of operation and maintenance.
• Main risks: assessment and summary of all main risks related to the project, their probable impact and action to undertake when the risks materialize.

   

Where can I find more data/sources to elaborate on the Business Case?

The executive is the one accountable for the Business Case. This does not mean that he/she is the one that actually writes it; however, he/she is responsible for the creation and the approval. Within the PRINCE2 the Business Case primarily derives from the project mandate and is developed in the pre-planning phase to obtain the approval of the Project Committee. The final Business Case takes it to shape by the information from the project plan and risk assessment. The Business Case contains elements of:

• Project Mandate and Project Brief - the project’s motives.
• Project plan - costs and planning.
• Expected benefits - in line with business benefits.
• Economic analysis - elaborated information of the economic environment.
• Risk register - information related to identified risk, including their status and history.
• Issue log - all information related to possible issues.

 

Format

The Business Case can be delivered in several formats, of which:

• The document, spreadsheet or presentation slide.
• File within a project management tool.

The Business Case is the base of all decision making processes and ensures that the project maintains its justifications, that business goals are met and that expected benefits are realized. Download here your copy of the customized Business Case PRINCE2 2017, provided by QRP International!   PRINCE2® is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QRP International has a core purpose: "Developing professionals to facilitate change". We believe in change as a tool for growth and improvement, not only professionally, but also in our society. This is the reason why every year we choose to support a cause. This year we chose to support Kibarè Onlus. Kibarè was founded in Como in 2013 and its founder members boast 20 years of experience in international cooperation in India and Africa, especially in Burkina Faso. What are they doing? We asked a member of Kibarè to introduce their project in Burkina Faso:

“Going to school is a privilege in Burkina Faso. Many parents think that children should rather help the family to grow crops; some also think that girls should wed and move out when they are barely in their teens. Issa Yelemou has dedicated his life to give these children a chance. In 2006, when he retired from being a teacher, he invested his life's savings to build his own primary school in the outskirts of Ouagadougou, the capital of Burkina Faso. He called the school Millennium and he became its headmaster. His vision attracted talented and motivated teachers, which have made the school a centre of excellence in the area. Over the years though, heavy rain seasons have taken their toll on the school buildings. Water has infiltrated the cheap cement and large cracks have appeared on the walls. Families have started to pull their children from school, fearing for their safety. Since 2016, we have been helping Issa Yelemou to rebuild the school. Some classes have already moved into the safe and dry rooms of a new wing, but many others still hope for the construction project to finish on time for the next school year.”

QRP International decided to support the organization with a donation that will enable Issa Yelemou to finish the construction project on time. Because all children need to study in a safe and stable environment to grow and develop their potential. Visit their website to know their mission, stories and beautiful achievements: Kibarè Onlus or follow their account: Instagram, Facebook