Is Project Management hiding behind your Product Management?

How can we differentiate Project Management from Product Management? Project mindset from Agile mindset? When does Project make more sense than Agile for Product Development?

Is Project Management lurking behind your Agile Product Management initiatives? Let's take a look to see if we can clarify somehow the differences.

I always define Product as the intersection of 3 worlds: UX (discovery), Agile (Delivery) and Data (metrics).

As many of you already know, I entered the world of Product Management through Agile as an engineer, but before that, I spent some time on Project Management too. The world has long since changed but even today, there is a lot of confusion around Project and Product, Project Management and Agile.

Warning: this article might not make a consensus! Just the way I like it ?? But do not mistake the intention of this article, Project and Product/Agile are two different approaches best suited for their own given context, none is better than the other in all situations. There is no war between both, but a need to understand what they mean and when to use each.

I. PROJECT AND AGILE

1.1 Traditional Project Management

We should go first to the basis of any project, what we all learned at school (oh man, that was long ago!). There are basically 4 dimensions in any project management:

• Budget and resources (people)
• Timing (or schedule)
• Scope (or features)
• Quality (but this one is usually implicit: no one wants to build something that just doesn't work, right?).

A good Project Manager will have a fixed allocated budget, a fixed scope of what needs to be done defined previously and a set schedule for the work coming. Here comes our beloved Microsoft Project and its Gantt charts and waterfall approach!

Note: Please find me a top manager who doesn't love Gantt charts ??! They are neat, they give this sense of control, tidiness, security... You can plan for everything and have "visual proof" that you will get your project on time, on budget and working perfectly. Ooooh, we love charts!

And here comes the problem: the system is over-constrained, you cannot fix the 4 dimensions, and if you try fixing time, resources and scope, you pay it in quality inevitably...

So what does traditional Project Management do if quality cannot be compromised?

Scope is fixed. Time must be maintained as much as possible making resources the only variable. Externalising, subcontracting, subdividing, parallelising... All means are good to keep the timing, but budget will increase and might get out of control.

What if budget is limited? Well, we have all seen this project that was supposed to be shipped last year, right? If resources (budget) are constrained (and the scope too), timing will suffer and that's the definition of poor project management...??

The focus on Projects is the successful delivery of a fixed scope on a fixed time, trying to preserve resources and quality as much as possible.

1.2 Agile approaches

Agile has a different approach to this, inherited from LEAN (you can read more about this in my previous article). Realizing that the system is over-constrained is the birth of agility practices.

Quality is non-negotiable (ok, that's a good start). Resources are usually fixed (you have the team that you have, with minor adjustments). We want to bring value (even with a limited product) as quick as possible, so a classic artifice is to segment time in sprints to try to fix it while loosening up scope (Scrum). Or we can fix subdivisions of the scope and loosen up time, while limiting the work in progress (Kanban).

The focus on Agile is the exploration of customer needs and bringing value as quickly as possible usually with fixed resources, to gain insights and be able to pivot (change scope) as quickly as possible (reduced time).

CONCLUSION:

As a general rule of thumb, fixing time and scope simultaneously means "Project" and Agile cannot exist.

Beware of detailed roadmaps and Gantt charts, or phrases like "I want you to garantee / promise / commit on delivering X (scope) at this date Y (time)", they are clear signs of "project" mindsets.

II. PROJECT AND PRODUCT

So now, the question comes to Product...

A project is set of work that brings value in a fixed timeframe, it has a beginning and an end that are set beforehand. A Product is "alive" and as such, evolves. It has a beginning and might eventually have an end, but the timeframe is not fixed.

Can we do Product as a succession of Projects? Can we do Product Management in a non-Agile way?

2.1 Product Management as a process

If you consider Product Management as a process, a succession of known tasks to solve a know problem, Discovery and Delivery can be sequentially chained and both could be managed as Projects with some bridges in between.

Many of you might be familiar with V-cycle approaches... Can you build great products with V-cycles? Of course you can, it is what was done for decades!

2.2 Product Management as a human-centered fast-reacting approach

Agile introduced LEAN principles to software but also placed the human aspect at the center. While LEAN focused on processes, Agile focused on human interactions and reacting to change quickly.

Remember the 4 Agile values:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Combining Design Thinking inspired practices and Agile practices (like SCRUM inspired frameworks) would give a human-centered team-based fast-reacting approach to Product Management.

So when does one approach make more sense than the other?

2.3 The Cynefin model

Let me introduce the Cynefin model: it defines 4 domains where problems reside

• Clear: the problem is known, solution is clear and actionable. We know what to do, and it is simple.
• Complicated: the problem is not necessarily known as a whole but it is a combination of known problems, trying known solutions will solve the overall. No big pivots or unknown solutions are expected and things, while complicated, can be planned.
• Complex: navigating complex problems requires unknown solutions, probing and sensing are crucial before responding. Reaction time must be reduced and therefore a focus on shortened interactions must drive the initiative.
• Chaotic: solving a chaotic problem is much like playing darts in the dark with a moving target... ?? pure frugal exploration is key (and some amount of luck).

Products solving clear and complicated problems are perfectly fine with Project-based approaches (and actually Agile practices are not best suited).

Complex problems benefit the most from traditional Agile practices and this is where Project practices usually fail spectacularly.

Chaotic problems, well... Stay away from them if you can ?? Otherwise use radical hyper-short and frugal Agile approaches.

Unless you work in a very stable, predictable and mature sector, where Project Management is the way to go, in a world that is Volatile, Uncertain, Complex and Ambiguous or even now Brittle, Anxious, Non-linear and Incomprehensible (thanks Fanny for pointing in out in the comments ??), I have rarely seen teams not dealing with complex problems (borderline chaotic) and therefore my following statement: it is not wise to properly do modern Products Management in today's world with a Project mindset.

But our (or our management's) need to have the illusion of control, of predictability, of reassurance, will hide Project Management practices at the very core of your Product Management.

My brave Product Managers, beware of hidden Projects behind your Product ??

What do you think? How is Project Management lurking in the shadows of your Agile Product organisation?

I hope you enjoyed the reading! Don't forget to follow and comment.