Measuring to Improve in Project Management

“You can’t improve what you don’t measure.” – Lord Kelvin

✅ Why Measurement Matters
Measuring key metrics like cycle time, lead time, and bug counts helps you spot bottlenecks and areas for improvement. Without solid data, you might rely on guesses, but accurate measurements lead to informed decisions and real results.

🚀 What Should You Measure?
According to Accelerate, focus on these four important DORA metrics:
-Deployment Frequency: How often your team releases changes to production.
-Change Lead Time: The time it takes for code to go live after being committed.
-Change Failure Rate: The percentage of deployments that result in issues, rollbacks, or failures.
-Time to Restore Service: How long it takes to fix an issue in production.

From my experience, I also recommend tracking:

-Cycle Time: The total time to complete a task from start to finish.
-Development Time: The time spent on coding and programming a feature.
-Bug Count: The number of defects or issues found in the software.

📊 Recommendations
Don’t overwhelm yourself by trying to measure everything. Instead, focus on 3 or 4 key metrics, establish a baseline, and make gradual improvements. Concentrate on enhancing one metric at a time for the best results.

🔧 Pro Tip
Use tools like JIRA, Trello, or Asana to collect your data, and Looker Studio (formerly Google Data Studio) to visualize it. Real-time insights help you focus on solving problems and improving processes.

Remember, measuring performance isn’t about micromanaging; it’s about empowering your team to continuous improvement by identifying growth opportunities.

hashtag#ProjectManagement hashtag#ContinuousImprovement hashtag#Agile hashtag#Leadership hashtag#KPIs hashtag#DataDriven hashtag#MetricsMatter hashtag#TeamWork

Prepararing a marathon project.

 

I love running marathons, and while I’ve completed several, I always wish I could run more. I treat my marathon training like managing a project—using a flexible, data-driven approach. With a 16-week training plan, I see each week as a new step, much like a Scrum sprint, where I check my progress and make adjustments as needed.

I track important details like my interval times, endurance, and recovery using tools like Strava and Garmin Connect, comparing them to previous training cycles and races like half marathons.

I’ve noticed that many runners stick to their training plans without adjustments, which can lead to burnout by race day. If you’re thinking about running a marathon, don’t make that mistake! Instead, listen to your body and adjust your plan based on how you feel.

Every week, I assess my performance and well-being. If I’m feeling tired or not meeting my goals, I adapt by adding more recovery runs or changing my long runs. When I’m feeling good, I push myself a bit more.

This focus on improvement—regularly checking in and adapting helps to get better and finish strong. As in project management, being flexible and responsive to change is key to success! So listen to your body and adapt your training plan 🏃‍♂️💪

#ProjectManagement #MarathonTraining #ContinuousImprovement

The Channel Tunnel Project

The Channel Tunnel is an undersea rail tunnel that links Folkestone in the UK to Pas de Calais, near Calais, in France. It carries high-speed Eurostar trains, and in recent years, it has transported over 22 million passengers annually, with freight surpassing 20 million tonnes.

In 1988, the Channel project began with a budget of £2.6B and an expected timeline of 5 years. However, it wasn’t completed until 1994, costing £4.6B—80% over budget and taking 20% longer than planned.

This is a classic case where uncontrolled changes in project scope occur due to unclear definitions and planning gaps.

Key issues in the Channel project:

Lack of historical data: Without precedent, crucial requirements like air conditioning were missed in the initial design.

Risk management: Unexpected underground conditions caused delays, highlighting the need for better risk identification and response planning.

Communication gaps: British and French teams tunneling from opposite sides faced communication challenges.

-Procurement issues: Optimistic bids led to the “winner’s curse,” where contractors couldn’t deliver on time or budget.

Would an Agile and Iterative approach have mitigated these issues?

Product Prioritization: Prepare a birthday party 🎉



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!).

What product prioritization tools do you use?

hashtag#projectmanagement hashtag#productmanager hashtag#agileprojectmanager

The Panic Zone

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.

We successfully delivered two major projects: opening 40 Burberry corners in El Corte Inglés malls and creating a new warehouse in Northern Italy.

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.

hashtag#projectmanagement hashtag#comfortzone hashtag#embracechallenges

Prioritizing product features with RICE

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.

#ProjectManagement #Prioritization #Productivity #RICEScoring

Sustainable Pace in Projects

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.”

Sustainability is key to long-term success both in marathons and in projects.
hashtag#Agile hashtag#ProjectManagement hashtag#SustainablePace hashtag#TeamHealth hashtag#AgilePrinciples

Daily Scrum common mistakes


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

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.

How to Measure Project Success: Lessons from NASA’s Space Shuttle Program (1981–2011)

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.