For tracking progress of the project PRINCE2® uses the “PROGRESS” theme. Progress tracking in PRINCE2® means monitoring and comparing actual achievements against those planned. Providing a forecast for the project objectives and the project’s continued viability and control any unacceptable deviations. 

PRINCE2® defines Tolerances to track deviations. Tolerances are the permissible deviation above and below a plan’s target for time and cost without escalating the deviation to the next level of management. There may also be tolerance levels defined for quality, scope, benefit and risk.

Progress control involves measuring actual progress against the performance targets of time, cost, quality, scope, benefits and risk, and then using this information to make decisions such as whether to approve a stage or Work Package, whether to escalate deviations, and whether to prematurely close the project.

So to track progress steps are:

• Setup Project Controls for Delegations and Tolerance

Project manager uses below management products to establish baselines for progress control

Project Plan – includes the project level performance targets and tolerances. 

Stage Plan –  Includes basis of the day-to-day control of the stage. 

Exception Plan – The Project Board may request an Exception Plan after having considered an Exception Report during the exception handling process. It includes the steps to overcome exceptional situations.

Work Packages – The Project Manager authorizes a Work Package. It includes the details of the piece of work required to be completed during a stage by an individual team member or a Team Manager.

Tolerances are set as below for each of the aspects of project 

• Dividing the project into management stages and authorizing the project one stage at a time.

Management stages are partitions of the project with management decision points. Project is divided into many management stages and the Project Board authorizes one management stage of the project at a time. In a PRINCE2® project minimum 2 management stages are required. Decision on number of stages is taken by Project manager in consultation with Project Board.

• Report and review progress through Time-driven reports

(Take place at predefined periodic intervals. For example, producing monthly Highlight Reports for the Project Board) and Event-driven reports (Take place when a specific event occurs. For example, the end of a stage)

• Raise exceptions whenever required.

There can be exceptions when tolerances at one or more levels exceed it’s agreed limit.

An exception is a situation where it can be forecast that there will be a deviation beyond the agreed tolerance levels 

Exceptions can happen at three levels:

• Work-Package-level exceptions 
• Stage-level exceptions 
• Project-level exceptions 

Depending on the exception level appropriate authority takes action or decision. Like in case of work package level exception Project Manager will advise of any corrective actions required. 

In case of Stage-level exceptions Project manager refers the case to Project board for decision making.

Please remember that when project tolerances are forecasted to be exceeded, the Project Board no longer has the authority to manage the project and must refer the matter to corporate or programme management 

The post How to Track Progress in a Typical PRINCE2® Project? appeared first on World Of Agile.

The Situation Context Framework (SCF) is created by Agilist Scott Ambler  and Mark Lines in 2020. This framework defines contextual factors which need to be considered when you are defining a way of working for your team. The SCF is used to provide a base framework that will help you to design a way of working – WoW which will be suitable for the work or project you are undertaking

Key Areas to Consider while creating an Agile Team

When you initiate a team you need to identify key areas that will impact of your WoW, some of the important ones are described below:

Decide Team Composition

When you are trying to design a team composition you have several issues to consider. These issues will help you decide how best to organize your teams

• Will the team be made up of  people who have mostly specialized / individual skills like Business SMEs, Technical architects, UI/UX experts  and so on or will team members be more along the lines of T-skilled generalizing specialists?  DO you really need some niche skills that cannot be easily picked by other team members? Can you start with specialized roles but have internal cross skilling plans?
• What will be the team size? Do you need large teams?
•  Will the team be located in the same place or be in multiple locations – This will also impact your tooling strategy
•  Will they work for a single organization or several?

The choices you make will be driven by the situation that you face.

Decide Team Process Framework

 Similarly, you have several process-related issues to consider.  

• What way of working is most appropriate?  For example, will you take a generic agile approach?  Or a specified framework? A lean approach?  A traditional approach?  A hybrid approach?  
• Will your team be able to follow a light, goal-driven process or a prescriptive one?
•  Will your process be constrained by compliance to frameworks such as CMMI or ISO standards? Do you need to do certain legal compliances and documentation?

What tools are you going to use? 

Usually every modern project will benefit from an underpinning of technology framework to ensure smooth operations. These days there are ample tools in the market that will help you. Some key issues to consider when choosing tools are.  

• Are you open to using open source tools? Will you adopt open source tools, commercial tools, or a combination thereof?  Are there any organizational policies that impact usage of open source tools?
•  Will your tools be integrated or stand alone? 
•  Do you prefer to obtain tools from a single source whenever possible? Tools from a single platform usually will lead to better integration and less effort on customizations. Or will you go with the best suitable tools not worrying about the vendor? 
•  Will you host your own tool environment with your own infrastructure? Or you will go for an end to end dedicated hosting by vendor? Or will it be hosted externally via a SAAS-style approach? 
•  If hosted externally, where will your intellectual property (IP), be hosted? What are the precautions you need to take to protect your IP?

The post Setting Up Agile Teams for your Project/Team appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article with cover the Scaling Conetx and Some Basic Concepts like where scaling fits and how it works.

Let’s first understand what Scaling is?

As a word, Scaling means there are multiple teams working on a Product (Value Stream). 

Scaling Agile refers to the process where the established Agile methods (Scrum/Kanban) are applied to other layers of organization.

Look at the Matrix below to understand the layers of the organization. 

In any Project organization the ratio of Product and Teams is:

• 1 Team working on 1 Product
• 1 Team working on Many Products
• Many Teams working on 1 Product
• Many Teams working on Many Products 

The Matrix above shows the context of Product v/s Teams.

• When we define a Product – here we define an Independent Value Stream which makes sense from a market perspective.
• When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
• Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts. Scaling is out of scope of Scrum.
• “Many Products – Many Team” context is defined by portfolio management, which is out of scope for most of existing scrum frameworks – SAFe is one of the most prevalent scaling framework that helps with
• “One Team – Many Product” quadrant is for Staff Pools who do heterogeneous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

Context of Scaling and De-Scaling

When we think of larger products, we can think about descaling – that is, dividing the larger products first into smaller units of independent value streams (Products).

For the above product, the Scrum Context is that for each product (an independent value stream) there has to be a single product backlog, a single product owner and a single development team. Like the below diagram, each team works as an individual Scrum Team with their own “descaled” Product Backlog. There will have to be some considerations made to co-ordinate among the various dependent product backlogs. The diagram shows how the descaled products work.- Spotify is an example of framework which works on the principle of descaling

Context of Product Backlog and Product Owner

There is always a one to one relationship between a Product and Product Backlog and Product Owner. The context of the product backlog is shown below

The following structure where one is NOT OK. The accountability on the Product will go down if the following is implemented. It is better to descale the product instead of having a structure as shown below:

Context of a Product Owner and Development Team in Scaling

A Development team will always look up to Only one Product Owner.

A Development Team looking up to multiple PO means, the accountability is not central and conflicting decisions may come to the Development Team.

The post Scaling Context – Some Basics Concepts appeared first on World Of Agile.

As a part of the Introduction to Scaled Agile Framework series, this article will explain “Why Industries are in Need to Adopt Scaled Agile?” –

Agile is exploding! As stated by the 15th State Of Agile Report, 94% of organizations state that their company is doing at least some work in Agile and over half of these organizations state that majority or all of their teams have adopted Agile.

Around 2010, the Agile way of working did not have this level of acceptance. In fact, there was a lot of skepticism around the Agile way of working. There used be heated debates around if there is actually any benefit in 15 minutes only “meeting” or if leaders in the real world lead by serving their teams.

Today such discussions are not very common and there seems to be a consensus within the IT industry that at least at team level, Agile way of working definitely helps.

The question then remains – if Agile is doing so well and organizations are reporting so many benefits – why do we need to scale Agile? Challenges That Persist – These are the driving factors causing companies to look at Scaled Agile

Why Industries are in Need to Adopt Scaled Agile? – Some Challenges in Single Team Agile

Even when the teams are working in Agile, there are some challenges that remain unsolved when you are working in Large Programs– These challenges are the ones which drive organizations to consider scaling Agile within their organizations

Lack of alignment with Business

In team-level Agile, there is no underlying structure which helps to  percolate the organization and/or portfolio vision down to each individual Agile Team. As a result, even when each team is operating in Agile, some of the benefits still remain elusive. Especially those that are achieved by business and IT synergy Going

Amount of Work in Progress makes a uniform way of working a necessity

The sheer amount of work being done in any organization means that there has to be a way to review and monitor all the projects. To enable objective decision making, it is critical that each project (whether Agile or not) has to share information in a uniform manner. When each team is working independently, having such an enterprise-wide working agreement becomes key to smooth operations. Organizations are looking to scale their Agile way of working in the hopes to establish these working agreements across teams.

Large Monolithic Architecture

Over the last few decades many organizations have developed a humongous piece of code that is essential to keep the organization running smoothly. Having such a monolithic architecture makes it very difficult to handle

Dependency Management

Most of the programs in a large organization require more than a single team to reach the goal in a competitive timeframe. Organizations need an established scaled agile framework to deal with complexities of multiple teams 

Sub Optimal Leverage for Specialized Roles

Many specialized skills like UX experts or Architects are not needed full time. Since these are rare to find/ niche skills, it is very inefficient to waste these skills. Also organization-wide uniformity is needed in most of these areas. Considering this, having a shared pool as a part of scaled agile way of working makes definite sense for most of the organizations

Co-Coordinating Release Windows

Since it can potentially disrupt day-to-day work, Software release is often a stressful event for any organization. When there are multiple teams working on small bits of improvements, it’s often wise to coordinate releases across multiple teams. Having a defined scaled Agile framework makes this coordination easy

The post Why Industries are in Need to Adopt Scaled Agile? appeared first on World Of Agile.

One of the Mandatory PRINCE2 principles is “Tailor to suit project Environment”.  So what do you mean by “Tailoring“?

Tailoring means Adapting a method or process to suit the situation in which it will be used. 

Generally the PRINCE2 project tailoring is where by Organizations adopt PRINCE2 by tailoring it to their needs, often creating their own PRINCE2-based method and then embedding its use within their working practices. So that your project will have an appropriate level of governance and control which does not overburden the project management team.

The general Guidelines on Tailoring a PRINCE2 project is provided in PRINCE2 Manual “Managing Successful Project using PRINCE2”. Read below the summary of the same.

Tailoring PRINCE2 to suit different projects

Before we start please remember that “PRINCE2’s principles should not be tailored as they are universal and always apply” 

Also tailoring does not mean “excluding any of PRINCE2’s processes or themes”

• What can be tailored?

1. Processes may be combined or adapted (e.g. by adding or combining activities).
2. Themes can be applied using techniques that are appropriate to the project.
3. Roles may be combined or split, provided that accountability is maintained and there are no conflicts of interest. 
4. Management products may be combined or split into any number of documents or data sources. 
5. Terminology may be changed to suit other standards or policies, provided it is applied consistently.

• Who is responsible and where is tailoring documented?

The project manager or Management level is responsible for identifying and documenting the level of tailoring required for the project and is approved by the project board. Both the project board and the project manager may be advised on the level of Tailoring by project assurance, project support roles or a center of excellence

• Remember – Tailoring is constrained and influenced by context

Tailoring may need to take into account policies, laws, rules, standards or regulations from within or outside the organization, including those relating to health, safety, sustainability and environment. 

The Nature of the project also can have an influence on how we tailor the project. Like Government driven, Compliance projects.

Similarly the context of the project Like is it part of Program or Portfolio? can have an influence on tailoring.

To summarize as a PRINCE2 practitioner you should consider the advantages and disadvantages of tailoring

for the specific project  and it’s circumstances. In which you should ensure that 

1. Tailoring complies with all the PRINCE2 principles 

2. Any corporate standards or policy adherence or tailoring should be analyzed.

3. Tailoring does not pose a risk of failing to meet the project’s objectives.

The post Tailoring PRINCE2 to suit your Project Environment appeared first on World Of Agile.

Service Desk serves as a Point of Contact between a Business organization (IT) and its employees, customers, as well as business partners. They provide access to users and stakeholders to report issues, questions, queries and requests, and have them acknowledged, classified, owned and actioned.

Service Desk staff handle a wide range of requests. Starting from a Simple query to technical issues faced by individuals or system outages that impact the entire organization.

Service Desk services can be availed by the users thru different channels Like: chat, email, phone calls, service portals and mobile applications, Walk-in, text and social media messaging

Service Desk staff are required to answer or resolve a wide variety of questions and queries related to the many business area’s. To handle this, they need to be skilled and knowledgeable. Particularly they need to have excellent customer service skills such as empathy, incident analysis and prioritization, effective communications, and emotional intelligence. But the most important skill they require is to be able to fully understand (business priority) and diagnose a specific incident and to take appropriate action on it. 

Different Service Desk structures are as follows:

There are a number of ways to set up a Service Desk. Few of them are listed below:

• Local Service Desk

A local Service Desk is one that is located in or near a company’s premises. In this case the Service Desk and their users are co-located at same Building or premise.

• Centralized Service Desk

Centralized Service Desk is a dedicated team working in a single location. They can cater to many different user groups. Like Service Desk team setting in Building 1 and catering to users from Building 1 , Building 2, Building 3.

You can set up a Centralized Service Desk by merging different Local Service Desks.

• Virtual Service Desk

A virtual Service Desk is set up to allow Service Desk staff to work from multiple geographically dispersed locations. Virtual Service Desk is now a days most popular type of Service Desk used by many companies these days. For a virtual Service Desk to work to it’s full efficiency, use of sophisticated supporting technology mainly internet and cloud-based is must. With that other technologies like interactive voice response, routing, automatic call distribution and escalation also are very much needed for ensuring good customer service.  

Benefits of Service Desk:

Improved the Service Experience: A good service Desk improves customer satisfaction by meeting their expectations.

Greater Visibility: Setting Service Desk allows departments to know what is happening in all areas of the business such as current technical issues, areas of concern etc.

Better Communication: A Service Desk can answer wider range of queries and questions which help to have a better communication with the users and stakeholders

The post What is Service Desk? appeared first on World Of Agile.

ITSM – ITIL : How Similar and How Different?

The post ITSM – ITIL : How Similar and How Different? appeared first on World Of Agile.

The ITIL 4 Certification Scheme comprises of the following modules:

• ITIL Foundation
• ITIL Specialist
• ITIL Strategist
• ITIL Leader
• ITIL Master

Above 5 levels have seven core modules within the ITIL 4 syllabus:

• ITIL 4 Foundation
• ITIL 4 Specialist: Create, Deliver and Support (CDS)
• ITIL 4 Specialist: Drive Stakeholder Value (DSV)
• ITIL 4 Specialist: High-velocity IT (HVIT)
• ITIL 4 Strategist: Direct, Plan and Improve (DPI)
• ITIL 4 Leader: Digital and IT Strategy
• ITIL 4 Master

• ITIL 4 Foundation

ITIL 4 Foundation is the entry level certification, offering end -learners a general awareness of the key elements, concepts and terminology used in ITIL 4

ITIL 4 Foundation is aimed at entry level IT professionals, those who need a basic understanding of ITIL, or would like to progress to higher levels within the ITIL 4 certification scheme

• ITIL Managing Professional

ITIL Managing Professional (ITIL MP) 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 Managing Professional integrates three specialist modules (Create, Deliver & Support, Drive Stakeholder Value, and High Velocity IT) and the ITIL Strategist Direct, Plan & Improve module. All modules are valuable independently but all 4 must be completed to obtain the ITIL Managing Professional designation. 

The ITIL Managing Professional modules mandates completion of ITIL 4 Foundation as a prerequisite.

• ITIL Strategic Leader

ITIL Strategic Leader recognizes the value of ITIL, not just for IT Operations, but for all digitally enabled services. Becoming an ITIL Strategic Leader (ITIL SL) demonstrates that the professional has a clear understanding of how IT influences and directs business strategy. 

ITIL Strategic Leader integrates the ITIL Strategist Direct, Plan & Improve and ITIL Leader Digital & IT Strategy module. Both modules are valuable independently but both must be completed to obtain the ITIL Strategic Leader designation. 

The ITIL Leader Digital & IT Strategy module mandates 3 years of managerial experience as a prerequisite along with completion of ITIL 4 Foundation.

• ITIL Managing Professional – Transition Module (ITIL V3 to ITIL4)

The ITIL Managing Professional Transition Module is designed for ITIL v3 candidates who are ITIL Experts or who have achieved 17 credits from across the v3 scheme. 

After achieving the ITIL Managing Professional (ITIL MP) designation, if you are interested in pursuing the ITIL Strategic Leader stream then you only need to complete the ITIL Leader Digital & Strategy module to become eligible for ITIL Master

The transition module will cover the core elements from the ITIL Managing Professional stream. It will have a mandatory training element and exam, enabling v3 candidates to transition their existing designations into the new ITIL 4 certification scheme.

• ITIL Master

The ITIL Master certification validates your ability to apply the principles, methods and techniques from ITIL in the workplace.

To achieve the ITIL Master certification, you must be able to explain and justify how you have personally selected and applied a range of knowledge, principles, methods and techniques from the ITIL Framework and supporting management techniques, to achieve desired business outcomes in one or more practical assignments.

Every ITIL Master candidate will select a different range of experiences that are personal to them, so there is no fixed syllabus for this qualification. There is also no prescribed training course since the theory being tested will vary depending on the nature of the situation each candidate will choose.

To be eligible for the ITIL Master certification, you must: have achieved the ITIL Expert certificate; and have worked in IT service management for at least five years in leadership, managerial, or higher management advisory levels.

In order to achieve your ITIL Master certificate, you must ensure you have extensive practical hands-on experience with ITIL and can demonstrate active involvement in implementation of the practices.

The post ITIL4 Certification Scheme appeared first on World Of Agile.

PRINCE2 is the most commonly used project management approach in the world, and it is increasingly being used in conjunction with Agile. As more organisations adopt agile, the need for specific guidance on how to use PRINCE2 in an agile context has grown accordingly. In simple terms, PRINCE2 and agile each have their own strengths and when combined they complement each other and create a holistic approach to managing projects in an agile way. The strength of PRINCE2 lies in the areas of project direction and project management. However, it provides little focus on the field of product delivery. Conversely, agile has a very strong focus on product delivery but relatively little on project direction and project management

PRINCE2 Agile provides governance and project management controls that are suitable for some situations but not others.

The post Blending PRINCE2 and Agile Together appeared first on World Of Agile.

When a PRINCE2 Project needs to adopt to agile context, tailoring is most important. A PRINCE2 project manager and the project board will need to monitor PRINCE2 recommended behaviours of project management team and the delivery teams. These behaviours are important to function in Agile context efficiently. Below are the PRINCE2 Agile recommended behaviours :

• Transparency
• Collaboration
• Rich communication
• Self‐organisation
• Exploration

Transparency

Transparency behaviour means everyone involved in the work knows the situation and there are no surprises. In Agile ways of working Transparency or openness is very Vital. The more information Clarity is there with in the team, the better this is. Having Transparency helps team to achieve speed, clarity and engagement. The most important driving factor behind this behaviour is the agile values of – honesty, trust, integrity and respect.

Collaboration

Collaboration means engaging with customers and working with them, rather than working for them. Working in silos has it’s own disadvantages. Having a motivated, respectful and collaborate team is better than people who work in Silos. Collaborative teams work together and provide cover for one another.

Collaboration is not always within the project teams but it involves external stakeholders as well. Collaboration with all internal as well as External stakeholders is very important to achieve shared understanding and work towards shared goals and outputs.

Rich communication

As agile way of working, mostly practiced using scrums is very fast paced. In such situations adopting to most effective way to communicate is very important. In Agile context the most effective way to communicate is face- to‐ face and/or visual communication as they are numerous times faster. 

Face- to‐ face and/or visual communication is considered to be a rich communication. Project environment should be tailored to encourage Rich Communication where team can pass information freely in a culture of commitment and trust. Documentation is still important, but by using visual communication methods prove to be more effective.

Self‐organisation

Self-organisation behaviour includes how team and team members work and behave with each other. The people who work together closely mostly know best how to get the job done. Hence people should be trusted and given liberty to work on their own. If they creates a plan, they own it and work towards achieving the plan. Self‐organising creates mutual respect with in the team. In PRINCE2 context a project manager can create trust environment by allowing team manager to focus on product delivery.

Exploration 

Projects are unique risky and challenging, and that is why experimentation is important in order to create ‘the right thing’ which a customer needs. Frequent Releases and quick feedback loops provide an opportunity to learn and adopt for Team. Learning helps to improve the products.

The post PRINCE2 Agile Behaviours appeared first on World Of Agile.