Beyond MoSCoW, ROI, or Cost of Delay product prioritization tools, will talk another day, one fun technique is buy-a-Feature. When planning a product, the Buy-a-Feature prioritization technique can help teams align on the most valuable. …
14 years ago, I received an unexpected call: “We need a Project Manager in London.” Without hesitation, I said yes, and within minutes, I found myself jumping from my comfort zone into the panic zone. …
When managing multiple tasks, the RICE scoring model helps prioritize based on four key factors: The formula is simple:(Reach x Impact x Confidence) / Effort = RICE Score This allows teams to focus on high-impact, …
In March 2014, I ran my first marathon. I followed a structured training plan for four months, and by the end, I felt nervous but ready. Three weeks before race day, I completed 30K at …
The daily scrum is part of the empirical control process in Scrum. Some of the common mistakes that avoid inspection and adaption. 1. Status Meeting vs. Goal-Oriented Focus:Teams often fall into reporting completed tasks (e.g., …
Beyond MoSCoW, ROI, or Cost of Delay product prioritization tools, will talk another day, one fun technique is buy-a-Feature.
When planning a product, the Buy-a-Feature prioritization technique can help teams align on the most valuable. This method assigns a virtual “budget” to stakeholders, who then “buy” the most important features.
Imagine organizing a birthday party! You have €100 to allocate between options like catering (€40), a live band (€60), decorations (€20), and a cake (€30).
Everyone involved can contribute their thoughts by “buying” their favorites with their budget. If the cake gets the most votes, but no one “buys” the live band, you know where to focus your efforts.
This technique fosters collaboration and ensures that resources are spent on what matters most to the stakeholders, creating alignment and building better products (or parties!).
14 years ago, I received an unexpected call: “We need a Project Manager in London.” Without hesitation, I said yes, and within minutes, I found myself jumping from my comfort zone into the panic zone.
In just two days, I became the Infrastructure Project Manager at Burberry’s headquarters, the iconic fashion brand. The catch? I had zero experience in infrastructure projects. Luckily, I had an incredible team backing me up. The first month was tough. The gloomy December weather in London, my uncertainty with the language, the loneliness, and the constant fear of failing in meetings weighed heavily on me. But I refused to give up.
I spent countless evenings in my apartment diving into infrastructure software, trying to acquire the knowledge I needed to succeed. By January, something clicked. I began gaining confidence. Meetings became easier, and together with the team, we tackled every challenge head-on.
My time in London was unforgettable. I met amazing people and learned so much—not just about infrastructure and project management, but about pushing beyond fear. Whenever I face a new challenge or feel my confidence waver, I remember that time. I turned the panic zone into a place of growth.
So, embrace the challenge. Trust yourself. Growth happens when you step outside your comfort zone.
When managing multiple tasks, the RICE scoring model helps prioritize based on four key factors:
Reach: How many people will this impact?
Impact: How much value will it create?
Confidence: How sure are we of the expected outcome?
Effort: How much work is required?
The formula is simple: (Reach x Impact x Confidence) / Effort = RICE Score
This allows teams to focus on high-impact, low-effort tasks that maximize value and efficiency. It’s a great tool for balancing workloads and making smart decisions on what to tackle first.
In March 2014, I ran my first marathon. I followed a structured training plan for four months, and by the end, I felt nervous but ready. Three weeks before race day, I completed 30K at a pace of 5:20/Km, feeling great. But on marathon day, we had an unexpectedly strong heat in mid-March in Barcelona. I tried to maintain my original pace. This was a big mistake. By 40K, I was near burnout. Why? Because I was pushing at an unsustainable pace, one I couldn’t hold for 42K.
This personal experience shows what often happens in project teams. During crunch times—major releases or special events—teams might be asked to go the extra mile, and that’s okay occasionally. But the team will burn out if that extra effort becomes the norm for extended periods.
One of the twelve Agile principles reminds us: “The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
The daily scrum is part of the empirical control process in Scrum. Some of the common mistakes that avoid inspection and adaption.
1. Status Meeting vs. Goal-Oriented Focus: Teams often fall into reporting completed tasks (e.g., “I finished tasks A, B, and C”). The daily meeting should be more goal-driven. Instead of focusing on tasks, try shifting the conversation: “I worked on this to help achieve our sprint goal, and today I will focus on this next step.” This keeps everyone aligned on the bigger picture.
2. Micromanagement: Sometimes managers use the daily as an opportunity to micromanage. Keeping the manager as a listener is crucial to fostering autonomy. Let the team self-organize and problem-solve, without external pressure.
3. Endless Dailies: In less mature teams daily stand-ups can be extra long. One simple fix: timebox each intervention. When team members know they have 2 minutes to share, they go to the point, focusing on essential updates that drive progress toward the sprint goal.
Mixing roles in Scrum, like having one person act as both Product Owner and Scrum Master, can lead to challenges. It’s like a two-headed dragon—one role focuses on driving the team’s direction (Product Owner), while the other ensures the team’s well-being and process (Scrum Master).
When these roles conflict, especially under pressure from stakeholders, there’s a risk of burnout if proper control mechanisms aren’t in place. On the flip side, without a sense of urgency, the team might struggle to meet their goals.
Balancing these roles is crucial for maintaining team health and productivity.
The Space Shuttle Program was one of NASA’s most ambitious projects, designed to create a reusable spacecraft for low Earth orbit missions. From 1981 to 2011, the program achieved impressive feats, but it also highlighted critical lessons on how to define and measure project success.
Early Wins, Long-Term Challenges
When the Space Shuttle Columbia launched in 1981, it marked a new era in space exploration. Over the next three decades, shuttles like Challenger, Discovery, Atlantis, and Endeavour completed various missions—from deploying satellites to assembling the International Space Station (ISS), one of humanity’s most significant collaborations in space.
Yet, despite these successes, the program fell short of its original promises. NASA aimed for frequent, affordable space travel, but each launch cost about $450 million—far exceeding initial estimates. Extensive refurbishments were required after each mission, reducing the impact of the shuttle’s reusability.
The program’s reputation suffered further after two tragic accidents: Challenger in 1986 and Columbia in 2003, leading to multi-year flight suspensions and raising serious safety concerns. Ultimately, by the time the program was retired in 2011, its total cost had surpassed $196 billion. Though it delivered major milestones like the Hubble Space Telescope and the ISS, the Space Shuttle Program didn’t fully meet its core objectives: safe, reliable, and affordable space travel.
Defining Success in Projects: A Critical Lesson
In many projects, teams invest months of effort, only to launch a product or service with little clarity on whether it meets expectations. The lesson here is clear: defining success criteria early is essential for guiding the project to its intended goals.
Success criteria are measurable goals and standards that determine whether a project has achieved its objectives. Here are a few examples:
“This feature will reduce customer help desk calls by 10%.”
“We aim to increase customer engagement in the app by 5%.”
“The project must be completed under a $500,000 budget.”
One of the first questions I ask during any project’s inception phase is, “Why are we here, and how will we measure success?” Answering these questions helps us define the project’s scope and make necessary adjustments throughout its lifecycle.
Just as the Space Shuttle Program achieved great things but missed some of its critical objectives, our projects can have significant milestones while still failing to deliver on their core promises—unless we define what success looks like upfront.
Hans Christian Andersen’s story The Emperor’s New Clothes (1837) teaches a lesson that is still relevant today, especially in project management.
In the story, an emperor who loves his clothes hires two scammers pretending to be tailors. They promise to make him a special, invisible outfit to anyone “stupid.” Of course, no one wants to admit they can’t see the clothes, so the emperor and his advisors go along with the scam. The emperor even parades through the streets wearing nothing, and the crowd pretends they can see the outfit. Only when a child says, “But he’s wearing nothing at all!” does the truth come out. Still, the emperor keeps going, unwilling to admit the obvious.
This story reflects situations where people ignore the truth because they’re afraid to speak up.
Sounds familiar? I’ve been part of projects that echo this tale—large-scale, cross-country integrations or complex product launches—where leadership insists on a timeline that no one believes is achievable. The days move on, and yet no one dares to challenge the feasibility of the goal, fearing they’ll be seen as the “fool” in the room.
In project management, these “Emperor’s New Clothes” moments can happen when people are afraid to ask tough questions or challenge unrealistic goals. But the best thing we can do is speak up and ensure we’re honest about what’s achievable.
Let’s aim for transparency in our projects and not be afraid to ask difficult questions before it’s too late.
The Situational Leadership Theory is a leadership theory developed by Paul Hersey and Ken Blanchard. The main principle of this theory is that there is not a single way in the leadership style so the most effective way is to adapt the leadership style to the maturity of the staff that is being leading and the details of the task.
Leadership Styles
Hersey and Blanchard categorized the leadership styles into four behavior types:
Telling (S1): where the leader provides the what, how, when, and where to do the task. This style is based on a high level of direction and a low level of relationship.
(Gene Hackman with a telling leadership style in Crisom Tide)
Selling (S2): where the leader provides information and direction, but there’s more communication with the team. Leaders “sell” their message to get people on board. In this style, there are a high level of power by there are a high level of relationship too,
(Josh Lucas is a selling leader in Glory Road)
Participating (S3): where the leader works with the team, and shares decision-making responsibilities. In this style, there are less level of direction and is focused on the relationship.
(Robin Williams is a Participating leader in Dead Poets Society)
Delegating (S4): where the leader delegates or pass most of the responsibility to the team. The leader still monitors progress, but he’s less involved in decisions. In this style, there are a low level of direction and relationships.
(Al Pacino is a Delegating Leader in Any Given Sunday)
But the leadership style will depends on the level of maturity of the person to be lead. Hersey and Blanchard identified for level of Maturity for their theory.
M1: where the team member lack of the specific skills required for the specific tasks or goal in hand and is unable and unwilling to do or to take responsibility for this job or task.
M2: where the team member is unable to take on responsibility for the task being done but, they are willing to work at the task.
M3: where the team member is experienced and able to do the task but with a lack of confidence or willingness to take on responsibility.
M4: where the team member is experienced at the task with their own ability to accomplish it. And he´s able and willing to take responsibility for the task.
Based on this theory, no one style is considered optimal for all leaders to use all the time. And the leadership style for one team member could be evolving at the same time the collaborator’s skills are improving. The recommended leadership styles associated with maturity levels are shown in the Situational leadership curve.
If you have to achieve goals in your company you have to measure the performance or success in your activities. A KPI (Key Performance Indicator) report is a great way to do it.
A KPI is a measurable value that shows if a company is performing well and achieving the goals or business objectives or if a process or service is working well.
-Number of bookings in an online store page during the holiday season (Business objective)
-Number of issues solved in a Software Maintenance Service (Service Performance)
-Number of calls issues solved in a call center (Service Performance)
During the process of defining and creating the KPI´s we have to avoid :
-Measures are not relevant
-The data are not accurate and we have changes between similar periods
-The measures are not aligned with the company strategy goals
-The final report with the measurement are not easy to understand
-The first measurement of this could be use to establish a baseline in order to compare an improve in the future periods.
Measuring a Service Performance with KPI´s
Let see, we have a Service that provides support to all employees in a company that sells air conditioning equipment that are using an specific CRM software. The Service consist in a Call Center and a dedicated team that solves issues and create new features for software based on the business needs.
We want to have an accurate view about the performance of this service about the software performance and how the team is dedicating his time.
So what we need to measure?
With a clear goals we have to ask the right questions, and every question will lead us to a KPI measure.
Get accurate measures: We need a tool to track the activity of the process. It could be a ticketing tool a database, something where we can get clear registers of the activity that we want to measure.
Are these measures meaningful?: We should avoid overmeasure or get measures that has not sense.
When we get the measures we have to prepare dashboard with the monthly results. In this dashboard we should include
YoY measures in order to have an overview
Clear data about the last two months
Some comments about why we get this data.
Below some examples how we show the KPI´s with and overview of the last 12 months and data about the average and the last two months
Response and resolution time: this KPI shows a trend that the issue grew during mid summer because this company has more activity (they sell air conditioning equipments), but along the time the response time is going down
Capacity vs demand: this KPI show if the team is overloaded during the last 12 months. But we have the capacity and the demand aligned
% Demand vs time logged in issues: this KPI shows that the team efficiency solving issues
