|
|
The case: The client is a consulting company experiencing a phase of growth and transformation. To improve its ability to respond to change and increase project quality, the company decided to independently introduce the Scrum framework, starting with a pilot project for an important customer, with the goal of progressively extending the framework to other initiatives. During the pilot project, several issues emerged due to a misinterpretation of key agile concepts, ultimately leading to an interruption of the project. |
|
PMProgetti’s intervention: We began by working closely with the Project Manager and the Team to build a shared understanding of the agile philosophy and the principles behind Scrum. Establishing common ground and a clear vision of what it truly means to work in an agile way was essential. Many misunderstandings surfaced during the training sessions, which allowed us to clarify several aspects related to the agile mindset. Together with the client, we reorganized the project team, focusing not only on technical aspects but also on collaborative culture and shared responsibility. After the training phase, we supported the Product Owner, the Scrum Master, and the Team through targeted coaching activities, guiding them through the first project Sprints, helping them gain confidence in their new roles, and turning theory and tools into daily practice. After a few Sprints, the Team began to operate autonomously, showing greater confidence, fluidity, transparency, and adaptability. Scrum events started to make sense, and the Team’s improvement became clearly visible. At that point, our focus shifted to scalability: how to extend the Scrum approach to other project initiatives while maintaining consistency, quality, and value. We realigned the company’s PMO, defined an agile project methodology framework aligned with the organization’s project lifecycle, and supported the Management team in adopting a leadership style more suitable for agile projects. For scalability, we referred to the Nexus and SAFE frameworks. |
|
|
|
The case: The client is a group of consulting companies. The organization decided to introduce the Scrum framework for software project development across all companies in the group (more than 80). However, the contracts with their Clients follow a traditional plan‑driven lifecycle. Therefore, project and service contracts need to be redefined according to Agile principles. |
|
PMProgetti's intervention: After delivering Scrum framework training for Scrum Masters, Product Owners, and Developers, and supporting many professionals (over 2,000 people) in achieving PSM‑I, PSPO‑I, and PSD‑I certifications, we were asked to provide support in adapting proposals and contracts to the Agile framework. Our work focused on redefining the structure of technical and financial proposals in alignment with Agile principles. We proposed a multi‑level (multi‑tier) structure consisting of:
Milestones and payment terms were reorganized to emphasize the actual Value delivered. For certain types of Time and Materials contracts, we introduced the concept of graded Time and Materials, linking the quality and timeliness of the work performed to the economic compensation, including a bonus for early delivery and a reduction for late delivery. For managing Change Requests, we proposed the Dynamic Scope Option, which allows scope adjustments and innovation funding at specific moments while limiting the supplier’s risk. Finally, we emphasized the partnership relationship by introducing schemes to manage early contract termination, with the goal of maximizing project value for the Client and strengthening the supplier group’s presence through the acquisition of additional business. |
|
|
|
The case: After a five‑year collaboration and having already introduced Agile approaches within the company (a multinational corporation), the context was clear from day one: six international teams, distributed across more than 12 countries, tasked with solving highly complex technical issues on packaging machines installed worldwide. Each issue was essentially a project of its own: different customer, different context, different operating conditions. A program like this cannot be managed with standard processes. It requires method - but also cultural sensitivity. Structure - but also adaptability. Agile - but real Agile. And so began a four‑year journey. |
|
PMProgetti's intervention: The starting point included six globally distributed teams, many cultures, and a single shared challenge. Teams were mixed: engineers, technicians, product specialists — people with very different backgrounds and mindsets. Two Scrum Masters, six Product Owners, separate backlogs, rapidly shifting priorities. The complexity wasn’t only technical. It was cultural. How do you create a shared language among people living in different countries, speaking different languages, with different professional habits? How do you build a common way of working when every team faces different problems? Our approach: start from the foundations, together. We began with what we consider essential: training. Not theoretical training, but a practical path built around the real problems of the teams. We organized:
The goal wasn’t to “do Scrum,” but to build a common and sustainable working system that improved communication across teams. Daily complexity: priorities, cultures, suppliers. Each team had its own Product Backlog because each customer had different needs. Priorities shifted frequently, and the most complex solutions required the involvement of external mechanical companies. To prevent teams from becoming isolated, we introduced:
The goal was simple: make work visible, so it can be improved. The roll‑out challenge: launching five more teams in four months. After the first team went live, the challenge was to launch the remaining five teams within four months. It was an intense effort, involving:
And we succeeded. All teams were launched within the expected timeframe. Scrum and SAFe: coordinating without complicating. To manage inter‑team planning — especially when multiple teams worked on the same customer or the same machines — we integrated elements of SAFe and Nexus. Not to create bureaucracy. But to give teams a simple, structured way to:
This became one of the most appreciated aspects of the program, because it transformed complexity into collaboration. Four years later: what truly changed? It wasn’t just the way of working that changed. It was the culture. Teams learned to:
And above all, they learned to trust the process. The truth is: this wasn’t a program. It was a transformation. A transformation made of people, not tools. Of conversations, not procedures. Of small daily improvements, not big announcements. And for us, being part of this journey for more than four years has been a privilege. |
|
|
|
The case: The client is a company in the mechanical engineering sector that decided to develop an IT system to manage the administrative activities of its maintenance technicians (over 1,000 technicians distributed across Italy). The project was assigned to an ICT consulting firm that proposed an application based on a workflow‑management system. The first phase of the project, which had followed a traditional plan‑driven (waterfall) lifecycle, had revealed several critical issues, and the relationship with the IT vendor had become strained. However, the system still needed to be completed, and the client had decided to implement a series of improvements to make it usable. There were many doubts - both on the client side and on the vendor side (the ICT consulting firm). |
|
PMProgetti's intervention: After discussions with both the client and the ICT provider, we proposed changing the project approach and adopting a change‑driven (agile) lifecycle based on the Scrum framework. Neither the client nor the ICT provider had prior experience with Scrum. A certified PMProgetti consultant took on the role of Scrum Master. The Scrum Master began by organizing a workshop to introduce Agile concepts, set up the project parameters (defining roles, Sprints, the Definition of Done, the Roadmap, the Product Backlog, etc.), and - most importantly - rebuild the project team by involving both the client and the ICT provider. At the beginning, doubts were many, and skepticism on both sides was strong and evident. However, after the first two Sprints, the joint project team (client and provider) had overcome the main issues that had emerged in the previous phase: roles were clear, the agile management of change requests made the project more flexible, the quality of both the project and the product improved, the team was following the roadmap precisely and keeping its commitments, and requirements analysis had significantly improved. The second phase of the project was completed on time and within budget, even while managing several unforeseen changes along the way. In the final retrospective, both the client and the provider (especially the provider’s team) were visibly satisfied with the results, and the client decided to continue working with the provider. One sentence from the client particularly struck us: “This project was simple, but we would never have achieved this result without this Scrum Master.” |
|
|
|
The case: The client is a major player in the financial sector, accustomed to managing complex projects in a traditional waterfall mode - regulated, structured, and often slow by nature. The greatest delays, however, came from a long and intricate decision‑making process that caused significant bottlenecks across projects. At some point, the company made a decision that changed everything: moving software development to Agile. Not just a process update, but a shift in mindset, roles, and responsibilities. The initial request was clear: start with the Business Analysts, the first actors involved in every project. |
|
PMProgetti’s intervention: Step 1: Building the Product Owners of the future. The company chose to begin at the heart of the Agile model: the Product Owner role. They asked us to train their Business Analysts, giving them a shared methodological foundation and guiding them toward the PSPO‑I certification. This marked the beginning of an intense, practical, and highly concrete journey. Within a few months, around one hundred professionals earned their certification. Not just an individual achievement, but a strong signal: the organization was truly changing. Step 2: Growing Scrum Masters and Developers. For Agile to work, teams must be complete. They need Scrum Masters capable of guiding, facilitating, and protecting the teams. They need Developers who understand the rules of the game and know how to work according to Scrum principles. So we: At that point, teams began working in Agile for real: clear backlogs, regular sprints, retrospectives, continuous improvement. The transformation was no longer a project. It had become the new way of working. The decisive step: creating an Agile Center of Excellence. Once the teams started running, the company realized it needed something more: a place that would safeguard the methodology, support managers, help the most complex projects, and ensure consistency and quality. It needed an Agile Center of Excellence. We built it together, integrating: We provided our certified consultants - PMO‑CP, Scrum, PMI, and IIBA - creating a solid, scalable, and sustainable model. The Center of Excellence became the reference point for the entire organization: a place where people learn, improve, and grow. A collaboration that continues. Today, our partnership with the client continues. The company has made a significant cultural leap, but it keeps evolving, experimenting, and improving. And we remain by their side, helping them face new transformation challenges. Because Agile is not just a methodology. It is a way of thinking. And when an organization truly embraces it, everything changes. |
|
