News
View the latest inspiring and positive news and information about what's going on in the PM and IT world.
Date: 17/02/2021
As we all know, the end of the 1980s did not only see the Guns N’ Roses reach stardom, the first world tours of Madonna and Michael Jackson but, (arguably) more importantly, the appearance of ITIL.
Thanks to this new framework, IT is now providing Services (instead of technology) to their users and customers, and everybody agrees that disruptions of Service are bad and should be resolved as soon as possible.
We will come back later on these two aspects, and we will see how they are the source of all evil.
When an issue pops up
The issue might appear as it should be addressed by a psychologist instead of an IT person: we, human beings, find enormous difficulties in leaving an obvious pain unaddressed, even for the promise of later improvement. If you think about it, this is the origin of our catch 22 (catch 22; a paradoxical situation from which an individual cannot escape because of contradictory rules or limitations.) When implementing the ITIL best practices in an organization, we set up Practices (used to be named Processes) because we want to:- be more efficient,
- be better structured,
- gain control of our infrastructure,
- save money,
- increase customer satisfaction.
The catch 22
Even though the ultimate goal of all Practices is to make our customers happy, some of them are more user-facing than others. This is where we get into trouble: we invest all our resources in the most user-facing Practices, which leaves us unarmed when we should invest time and energy is less user-facing but equally (or even more) important Practices. Putting a focus on the most user-facing Practices is an obvious choice. When users are putting the Service Desk under pressure, or when an Incident impacts production, or when customers are waiting behind your door for the next version of your Product, you want to undertake action. It is humanly very difficult (in some situations, I daresay even impossible) to push back these activities in favour of others that will not have an immediate effect. As a result, we end-up investing all our time and energy in fighting fires, in such a way that we do not have the possibility to ask ourselves why we are having so many fires, to begin with. And here we find our catch 22: interruptions of Service (Incidents) are bad and should be resolved as quickly as possible. We put so much focus on the second part of the sentence that we forget the first one. If we agree that Incidents are bad, that they have a very negative impact on customer satisfaction, then we should try to avoid them, should we not? And if we cannot avoid them completely, try to minimize their impact, as is the goal of Problem Management. We all agree on this, but it is easier said than done, because we are only human and so engulfed in the “resolved as quickly as possible” part of the sentence.No magic solution but ….
So this is it, there is no way out, really? Are we condemned to empty this barrel without ever being able to turn off the tap that is filling it? Well, hopefully not. But as I said, there is no magic solution. Or at least none that I know of (if you have one handy, do not hesitate to share it with us). But we can work at it, and reduce the flow of the faucet. In an ideal world, one might think, an organization should have two separate teams to work on Incidents and Problems, so as to avoid being sucked in the catch 22 mentioned above. However, things are, unfortunately, not that simple.Incidents and Problems are closely linked
The first reason that comes to mind to justify the impossibility for separate teams, is because we do not have enough manpower to dedicate a team solely to resolving Problems. If this is true in most situations, we would probably not strictly separate these two activities anyway, because they are closely linked. Indeed, the technical knowledge and skills required are cross-practices. One learns a lot of useful things to troubleshoot Problems and document Workarounds as one is working on Incidents and the other way around. So totally segregated groups are probably not the best answer. But temporary teams might be. Indeed, setting up a temporary team (including the right skills) to work on one or several Problems should spare the member of the team the pressure oozing from Incident Management under the condition that the temporary team can work in a dedicated location.Clear implementation of the three phases of Problem Management
A clear implementation of the three phases of Problem Management, as suggested in ITIL 4, can also help you move in the right direction. As each phase has a clearly defined output, it is relatively easy to entrust the different phases to different groups, which can also be a good way to spread the workload and so find the time that we sorely miss.
1. The Problem Identification phase
Both proactive and reactive, should, to my opinion, be performed by people with both technical and functional skills. They should have a good understanding of the organization, as well as a clear vision of the technical infrastructure our services rely upon. Both are necessary to spot existing and potential Problems and thus produce the required output: complete and well-documented Problem records. Prioritization of the Problems records should take place between the Problem Identification phase and the Problem Control phase. This is essential to reduce pressure (there is always too much to do) and ensure that we make the best possible usage of our limited resources.2. The Problem Control phase
It should be executed by creative, broad-thinking, experienced technicians. Starting from Problem records, they analyse the Problems and document their findings. This will bring the Problems to the status of Known Error. The expected output of this second phase are Workaround solutions, that will help resolve Incidents quicker (and thus improve user satisfaction and free some time for our technical staff, starting to see the end of the catch 22).3. Error Control
It is the third and last phase of Problem Management Practice. An important activity of this phase is once again one of prioritization. Known Errors can stay open for quite a while, and that circumstance is bound to change, this prioritization activity should take place on a regular basis.Known Errors priority should be evaluated by a team of people. Indeed, several criteria must be taken into account like :
- impact on customer satisfaction,
- cost of application of current Workaround,
- cost of definitive resolution,
- technical feasibility of definitive resolution,
- influence on partner products we are using.
Date: 10/02/2021
The current crisis has helped us appreciate the skills and flexibility of the great staff.
To pivot and adapt to a changing environment is crucially important in this difficult time.
So, what happens when you bring new staff into your team, either through recruitment or by moving them from another part of the organisation? How long does it take to get them up to speed? How quickly can they adapt to the agile way of working?
What Onboarding means?
Onboarding is the term used to describe new employees joining and integrating into an organisation or team.
Onboarding isn’t just about induction and orientation it’s about how you manage the whole process of embedding new staff from the interview to the point at which they’re truly part of the team. It is about them moving from being outsiders to being insiders.
Because agile teams are autonomous, cross-functional and self-improving, newcomers into agile environments can face challenges in becoming fully integrated. Agile team members are expected to manage their own tasks and often take on several different roles.
In project teams, the work each team member does might differ substantially from day-to-day. Established team members often know each other very well and are confident of their own skills. All these factors can make it difficult for newcomers to join in.
We found from our research with a co-located team that agile techniques, as well as more traditional approaches, can help with onboarding. Traditional onboarding includes running an induction programme, providing a new staff pack, offering formal training, and allocating a mentor.
The table below shows some of the agile-related techniques used by the agile software development team we researched. These complemented the traditional techniques they also used. This team changed regularly and frequently had to onboard new members of staff.
Onboarding function |
Agile-related onboarding techniques |
|---|---|
| Recruiting | . Evaluate agile knowledge and give resources. |
| Orientation | . Provide Agile fundamentals pack |
| Support tools and processes | . Introduce and use an information radiator |
| Coaching and support | . Ceremonies - explain prior to the event . Encourage teamwork . Pair programming . Stand-ups . Co-locate when possible . Signal availability |
| Training | . Immersion from day one . Self-study |
| Feedback mechanisms | . Code reviews . Testing . Retrospectives . Sprint review . Sprint refinement . Small tasks |
3 Techniques for Onboarding onto an Agile Team:
Pairing
Pairing involves two people working synchronously on one task.
Pair programming is commonly used in IT teams, but pairing can be used for all types of work and is a great way of exchanging knowledge. Usually, one person deals with the detail while the other thinks more strategically and every now and then they swap roles.
In newcomer pairing, try pairing your newbie with an experienced member of staff for the first few weeks. During this time the newcomer will pick up lots of formal and informal knowledge. Although it is not possible for the two to swap roles, the newcomer will gradually become more independent.
If a new staff member starts while the team is working remotely, pairing can be a particularly useful way to help the newcomer stay connected while learning their new role.
Small tasks
Give your newcomer small tasks that they can complete in a day and vary the type of tasks you give them in the first few weeks. They’ll get a sense of progress from regularly completing tasks and get used to delivering chunks of work in short time periods.
As a result, they’ll be able to contribute to daily stand-ups immediately and learn from regular feedback. While working remotely, getting feedback is particularly important for new team members. Doubts can quickly set in without it.
Signal availability
At various points in the day, an agile team may work together in small groups or as a whole team to solve a problem. At other times individuals need to have uninterrupted time to concentrate on completing a task.
Find a way for team members to signal their availability throughout the day so newcomers can understand who can be interrupted and who prefers to focus on their own work. This is particularly important when working online.
Use an ‘available to be interrupted’ signal in your virtual environment so everyone in the team knows who they can ask for help. For instance, in Microsoft Teams you can set your status to ‘Available’ or ‘Do not disturb’ as an indicator.
Finally, don’t forget the social aspect of being in a team. Having a coffee break together - either virtually or in-person - and getting to know your new team member informally is important too.
Agile working is about people and culture as much as processes and practices, so spending time welcoming and getting to know newcomers is time well spent.
This article was originally published in June 2020 and reproduces by kind permission of the Agile Business Consortium.
Agile Research Network
The ARN is a collaboration between researchers at two UK universities, The Open University (OU) and The University of Central Lancashire (UCLan), at the forefront of investigating Agile methodologies.
Further reading Gregory, P., Strode, D., Barroca, L., Sharp, H. & Taylor, K. (2020) Onboarding: How Newcomers Integrate into an Agile Project Team. To be published. Proceedings of the 21st International Conference on Agile Software Development, XP 2020 https://www.springerprofessional.de/en/onboarding-how-newcomers-integrate-into-an-agile-project-team/18021556 Plonka, L., Sharp, H., Van der Linden, J., & Dittrich, Y. (2015). Knowledge Transfer in Pair Programming: An In-depth Analysis. International Journal of Human-Computer Studies, 73, 66-78.
Date: 03/02/2021
The abbreviation PMO is most generally used for the Project Management Office.
The Project Management Office is a group or department within an organisation whose job it is to maintain the standards for project management and programme management within the structure.
The PMO is the backbone of a successful project or programme.
The PMO offers guidance to projects and programmes by trying to standardize the practices and increase efficiency. It focuses on standards and offers help by implementing different methodologies.
The PMO also develops and maintains metrics to follow the execution of projects and programmes.
A best practice PMO has a problem-focused purpose, with its functions and services aligned with the purpose, function and services of the other PMO within the organisation.
Source:
Axelos: Value of the PMO
Axelos: Implementing and leading a best practice PMO
Read more
Different types of PMO
The term PMO is mainly used to describe a Project Management Office, however, some organisations use the term to describe either a Programme Management Office or Portfolio Management Office.- The Project Management Office supports individual projects.
- The Programme Management Office coordinates identify dependencies of projects and supports the transition of outputs to Business as Usual.
- The Portfolio Management Office functions at a corporate level where all change initiatives within an organisation are managed.
The Supportive PMO
The Supportive PMO provides support in the form of on-demand expertise, templates, best practices and lessons learned. This is a great solution for organisations where projects are done successfully in a loosely controlled manner.The Controlling PMO
The Controlling PMO provides support but also requires that the support is used. The PMO sets requirements of specific methodologies, templates and governance guidelines. Projects are also closely monitored by this type of PMO. The Controlling PMO is a solution for an organisation that seeks to align activities, practices and documentation.The Directive PMO
The Directive PMO provides Project Management experience and resources to manage a project. This type of PMO creates a high level of consistency of practise across all projects and is especially effective in large organisations.Purpose of the PMO
The PMO, whatever type, offers guidance and information. It helps the organisation make sure that the right projects are done and that the right decisions are made by the right people, with the right information at the right moment. It helps the organisation govern and deliver projects in line with the organisation's values and organisational goals.The PMO
- Seeks to implement appropriate project selection and prioritise criteria that assess the contribution to strategy, along with validation of the business case.
- Services to support the management of dependencies between delivery, deliverables, business changes and benefits across the projects and programmes.
- Can imply the use of appropriately tailored methodology like PRINCE2 and MSP or other Project/Programme Management methodologies in order to ensure projects and programmes are delivered well, efficiently and effectively.
- Provides a benefits framework and support for Project and Programme sponsors in order to deliver the benefits aligned with the organisation’s goal.
- Designs and implements functions and services that address the current or prospective problem/question that is recognised and acknowledged within the organisation.
- Listens to the decision-makers in the organisation and designs functions and services accordingly.
- Adapts to the maturity of the organisation, the culture, structure and level of sponsorship. Based on this it determines the value of the services to the organisation.
- Keeps an overview of all ongoing, previous and future projects and programmes and serves as a repository for all documentation.
- Creates quality reports that can be used for decision making by executives and boards with up to date, reliable and credible data.
- Demonstrates the value of the services it provides.
Capabilities within the PMO
The set of capabilities and fulfilled roles will be different for every PMO, depending on size, complexity and many external factors. However, for a good functioning PMO, there are some obvious areas that should be covered.- Stakeholder engagement: to ensure the right people are receiving the right messages in the right way – avoiding any misinterpretation
- Project management: to be able to support and/or challenge with credibility
- Analysis: to be able to collate, interpret and analyze often complex data
- Communication: to listen to and be able to present the right messages in the right way so that they will be accepted – even the difficult ones
- Negotiation: to act as a broker between the sponsor, business and PMO. Not usually a daily demand but potentially an invaluable skill at the enterprise level.
PMO Roles
The PMO is essentially providing services to an organization, but what this actually entails can differ between organizations. It is a complex and ever-changing environment and roles and the context of projects and programs highly influence the PMO. The PMO related roles are: . PMO Manager, who has the daily responsibility of the PMO. The Project Management Office Manager is to ensure that their company’s standards are upheld and clearly defined throughout the entire process of each project’s development and execution. PMO Managers are responsible for overseeing the work of all project management office personnel, and thus must take ownership of the resulting quality of each project. . PMO director is a senior level role and is most definitely concerned with taking ownership and accountability for change activities within a business. They are there to make sure an organization has everything in place for strategic initiatives to be delivered successfully. They are often focusing on creating the right environment with strong capability and capacity for delivery to succeed. . PMO administrators help to keep all those things organized. These administrators control documents, facilitate communication between the project office and stakeholders, and collect data to meet reporting requirements. . PMO Analysts hold a managerial position, but they work with employees from all levels who touch on the projects they are assigned to. As both analyst and manager, a successful PMO analyst is a talented multitasker. . Coach, who is responsible for providing ad hoc assistance to individual project managers or project teams. . Communication Specialist is the figure responsible for the communication plan and ensuring that all stakeholders receive timely communications regarding their projects. . Methodologist is this figure is responsible for the methodological content chosen for project management processes. It manages the evolution of templates and best practices, as well as for instructions on their use. Other probable roles within a well organized PMO can be defined into four different levels:- Project Support roles: Project administrator, Project Co-ordinator, Project Support Officer.
- Portfolio, Programme and Project Support roles: Project Management Officer, PMO Officer, PMO Specialist roles (Project Planner, Project Scheduler, Project Controller).
- Leading and Managing PMO’s roles: PMO Manager, PMO Lead.
- Directing PMO’s roles: Head of PMO, PMO Director, Portfolio Director, e-PMO (enterprise PMO).
P3O - Portfolio, Programme and Project Offices
For the higher-level roles within the PMO, a P3O (Portfolio, Programme and Project Offices) certificate is often requested. P3O is a methodology that helps organisations build support structures that enable the successful delivery of their portfolios of change management programmes and projects.
Source:
Axelos: Value of the PMO
Axelos: Implementing and leading a best practice PMO
Date: 27/01/2021
Our way of working is under constant change.
That automatically implies that also our Project Management is under constant change.
Project Management has become one of the most important pillars within any company as it has been recognized as one of the fundamental factors for the success of the organisation. This is why organisations are looking for technologies, systems, and processes that help them to customize and optimize Project Management.
There is a need for growth, which often goes hand in hand with an increase in clients/customers.
Project Management needs to be able to adapt to these needs and continue to serve the organisation at all stages of growth. This is why the Agile methodology was born, which seeks to bring that flexibility into the world of Project Management by completely detaching itself from traditional frameworks.
A traditional Project Management framework is defined as the ‘Waterfall Methodology’.
The Agile framework and the Waterfall Methodology differ in obvious and less obvious ways.
Both have their benefits and drawbacks and there is no ‘bad’ way of Project Management.
What works best for your organisation depends on your situation and strategic objectives.
In this blog post, we will analyze the differences, benefits and drawbacks of the Agile methodology and the Waterfall Methodology (traditional).
Which development methodology you go with depends very much on several key factors.
For example the structure of the organisation, the sector, the strategic goals and the role of Project Management in the organisation. There is no bad choice, for some organisations, the Agile framework will better fit the objectives, for others the Waterfall approach is a more obvious choice.
However, it also absolutely possible to create a mix of approaches, depending on the project.
Read more
Waterfall Methodology
The Waterfall approach is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. At the start of the project, the output, outcome and benefits are defined. The Waterfall model originated in the manufacturing and construction industries, where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process. When first adopted for software development, there were no recognized alternatives for knowledge-based creative work. The Waterfall model has a set team working in a linear fashion towards a clearly defined end goal. It makes use of standard documentation of which the format is predefined by the organisation. Examples of this documentation are the PID and the Business Case.Waterfall Methodology: Benefits vs Drawbacks
Benefits |
Drawbacks |
|---|---|
| Clear framework There is a clear understanding of the project timeline and deliverables before the project begins. The full scope of the project is agreed upon by the development team and their stakeholders in advance. | Less customer involvement A hands-off approach is not suitable for every type of product. Some customers will want more involvement as the project proceeds. If there isn’t a framework for that involvement, the waterfall approach could lead to frustration on both ends. |
| Documentation Each phase of the process is documented in detail to eliminate any misunderstandings or shortcuts. Documentation should be done at each stage of the process to ensure that all stakeholders are on the same page despite the sequential progress of the project. | Changes can be difficult The whole point of the waterfall methodology is that it follows clear steps and a set timeframe. Once these elements are in place, it can be difficult to make changes once the development team encounters a roadblock. Adaptability is a crucial part of software development to consider, particularly since it can be hard for customers to have a full grasp of the project before it begins. |
| Hands-off approach This approach allows for a more hands-off approach from the customer. Once the initial design and project plan is in place, there is little requirement for ongoing customer presence until the review phase. | Short in the effectiveness of requirements One area which almost always falls short is the effectiveness of requirements. Customers are sometimes intimidated by details, and specific details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting. |
Agile
The major difference between agile vs. waterfall might be summarized by saying that the waterfall approach values planning ahead, while the agile approach values adaptability and involvement. However, there is not just one Agile approach: Agile is a combination of multiple frameworks. The agile methodology has two core elements: teamwork and time. Instead of creating a timeline for one large software development project, agile breaks the project into individual deliverable pieces. These ‘time-boxed’ phases are called ‘sprints’ and last just a few weeks. Once each sprint is completed, the feedback from the previous phase is used to plan the next one. An Agile team starts every day with a short meeting where they discuss the status and objectives of the project they are working on. This is called a daily stand-up meeting, which is beneficial for all team members, regardless of their position in the team. Read here why the daily stand up meetings are being held and how to optimize them.Agile Framework: Benefits vs Drawbacks
Benefits |
Drawbacks |
|---|---|
| Customer involvement By allowing the client to determine the priority of features, the team understands what’s most important to the client’s business, and can deliver the features that provide the most business value. The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project. | Customer Availability The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation. |
| Early and Predictable Delivery By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly and frequently, with a high level of predictability. Agile development is often more user-focused, likely a result of more and frequent direction from the customer. | High involvement needed Agile works best when members of the development team are completely dedicated to the project. Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted time frame. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation. |
| Allows for change While the team needs to stay focused on delivering an agreed-to subset of the product’s features during each iteration, there is an opportunity to constantly refine and reprioritize the overall product backlog. New or changed backlog items can be planned for the next iteration, providing the opportunity to introduce changes within a few weeks. | Frequent refactoring The iterative nature of Agile development may lead to frequent refactoring if the full scope of the system is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration. |
Waterfall vs Agile: Comparison
Agile Framework |
Waterfall Methodology |
|---|---|
| Separates the project development lifecycle into sprints. | Divides project development process into distinct phases |
| Follows an incremental approach | Is a sequential design process. |
| Is known for its flexibility | Is a structured development methodology so most times it can be quite rigid. |
| Can be considered as a collection of many different projects. | Completes project development as one single piece. |
| Is quite a flexible method which allows changes to be made in the project development requirements | Does not include a scope of changing the requirements once the project development starts |
| Follows an iterative approach because of this planning, development and other phases may appear more than once | Completes all the project development phases like designing, development, testing, etc. only once |
| Reviews the test plan after each sprint | Rarely discusses the test plan during the test phase |
| Is a process in which the requirements are expected to change and evolve. | Is ideal for projects which have definite requirements and little change |
| Performs testing concurrently | Starts with the ‘build’ phase, after which the ‘testing’ phase follows |
| Introduces a product mindset where the product satisfies needs of its end customers and changes itself as per the customer’s demands | Shows a project mindset and places its focus completely on accomplishing the project |
| Works exceptionally well with Time & Materials or non-fixed funding. It may increase stress in fixed-price scenarios | Reduces risk in the firm fixed-price contracts by getting risk agreement at the beginning of the process |
| Prefers small but dedicated teams with a high degree of coordination and synchronization. | Has limited team coordination/synchronization |
| Has product owners prepare requirements just about every day during a project | Has business analysis prepare requirements before the beginning of the project |
| Has a test team that can take part in the requirements change without problems | Has limited opportunity to initiate any change in requirements |
| Can alter the description of project details anytime during the process | Needs detailed description |
| Has interchangeable Agile team members that, as a result, work faster. | Includes straightforward processes, so the project manager plays an essential role during every stage |
Date: 20/01/2021
In Scrum, team members work together to achieve shared goals, in an environment of collective responsibility and continuous progress.
In our webinar ''Scrum Master by APMG'', we discussed the role of Scrum Master within the Scrum Team with the expert Kim Delgadillo. Ever since we have been receiving many questions about the role of the Scrum Master and the Scrum Team in general.
This blogpost, written by one of our Scrum experts, is aimed to take away all doubts about the Scrum Team and answer all your questions.
Antonietta Fiorentino is an entrepreneur and Transformation Leader. Bi-modal PMO in digital transformation and for the innovation of large and medium-sized enterprises.
For QRP she is a trainer and agile business consultant.
Read more
How important is the technological competence of the Scrum Master? At times it may seem like the Scrum Master is a simple motivator with management skills rather than IT, or is it the link between the product owner and the team?
By carefully reading the guide to Scrum by Ken Schwaber and Jeff Sutherland we find no reference to “Technological” competencies of the Scrum Master. But it is absolutely possible that the Scrum Master is also part of the Development Team.Do customers easily accept to pay a Scrum team for a specific period without however being certain of the final result?
If you are used to procurement through “Fixed Scope” contracts, it can be difficult to change even if the goal is to seize an opportunity. Remember, Agile is a mindset. Therefore it is necessary for everyone (Customer / Supplier) to evolve; from a “closed” approach, with low external sharing, it is necessary to gradually move to an “open” approach, based on a cycle of learn-share-collaborate-improve, to encourage the exchange and transfer of knowledge in unconventional ways.What responsibility does the Scrum Master usually have in the context of cost and time control of a project?
The Scrum Master has many responsibilities (that you can discover here), but among these, there are no items that specifically concern the management of Time & Cost project constraints. It is a shared responsibility of the entire Scrum Team. Remember that Time & Costs are fixed and that the Scrum Team must be “Good” in setting the Sprint Goal. Here you can discover the responsibilities of the other Scrum Team members; the Scrum Developer and the Scrum Product Owner.If after multiple sprints the sprint goal is not reached, is this a failure for the Scrum Master? And what approach should the Scrum Master take in this circumstance?
The situation described is not a failure for the Scrum Master but certainly is a reason for reflection for the entire Scrum Team; issues to reflect on could be:- What did we not understand about the project/product?
- Is there a technical knowledge gap to fill?
- Internal/external changes to the client that make the sprint goal systematically obsolete?
But if the objectives are not reached during the sprints, does that mean that the time of the project is prolonged? If so, how does that work with the costs?
When the approach is Predictive in the early stages of the project, the focus is on detailing the planning by basing the estimates on the Scope defined in the formal documents (plan-driven approach). During the life cycle of the project, the project plan will be the work management guide and the reference for calculating progress. Changes are managed through a formal system and the value is generated at the end of the project, upon delivery of the final product. When, on the other hand, the requirements are unstable it is advised to focus on making decisions that give priority, and therefore time precedence, to activities with greater added value and actions for greater risk reduction (value-driven approach). It is advised to set budgets and create a plan in advance and to make the project scope negotiable. This rather than trying to fix the characteristics of the product, which will consequently determine the times and costs of implementation (plan-driven approach). When the approach is adaptive, therefore, the planning is carried out iteratively before each Sprint/Iteration, you are able to respond quickly and effectively to change. This results in a reduction in costs and, ultimately, an increase in profitability and Return on Investment (ROI). In more general terms, we move from an “inside-out” model, where you make and sell your product on the market, to an “outside-in” model, where you iteratively build the product/service together with your customer. Here the focus is on the Minimal Viable Product (MVP).Does the Scrum Product Owner also participate in the Sprint Retrospective phase? If so, what role does he/she play in the development team?
The Agile Business Consortium “strongly recommends” the presence of the Scrum Product Owner during the Sprint Retrospective meeting; like all members of the Scrum Team, he/she introspects and actively participates with the goal of continuous improvement.What does the Scrum Product Owner have to say during the daily? Isn’t that an obstacle to the Scrum Master in facilitating the ease of the team?
The Scrum Product Owner may be a member of the Development Team. This is a perfectly viable situation and in such circumstances, the Product Owner can obviously participate and participate fully in the Daily Scrums. If the Product Owner is not part of the Development Team, there are different schools of thought. Eg. Agile Alliance suggests keeping the Product Owner out of the Daily Meeting, Agile Business Consortium instead recommends the participation of the Product Owner and suggests the Development Team invite the Product Owner (it’s a good idea to share the choices and the commitment).
Antonietta-Fiorentino
Antonietta Fiorentino is an entrepreneur and Transformation Leader. Bi-modal PMO in digital transformation and for the innovation of large and medium-sized enterprises.
For QRP she is a trainer and agile business consultant.
Date: 22/01/2021
Holders of the Certified Associate in Project Management (CAPM) will no longer need to reapply and pay ($225 for members and $300 for non-members) to rewrite the CAPM certification exam at the end of their certification cycle.
From now on, in order for certification to remain active, CAPM certification holders will simply have to earn Professional Development Units (PDUs) over a shorter certification cycle through the PMI's Continuing Certification Program (CCR).
CAPM certification holders will be required to earn 15 PDUs over the new three-year certification cycle and pay the recertification fee ($60 for members and $150 for non-members).
Read more