Difference between programme, project, portfolio and product management

P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.

P3M Levels: programme, project, portfolio and product management

P3M Levels:
programme, project, portfolio
and product management

That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit.
Continue reading

Evidence for Agile

Although “everyone is doing it” is a reason to consider Agile it isn’t necessarily a reason to go Agile. I’ve thought it useful to outline reasons for going Agile and where possible provides research data to back up the argument. The data can be used to form the basis of a Business Case for Agile.
Continue reading

XP Refactored by Stephens and Rosenberg

In their book “Extreme Programming Refactored: The Case against XP” Stephens and Rosenberg (2003) outline their reasons for not liking XP as it is published, but they also outline what they do like and how risk can be reduced when using an XP like process.   I found their book rather long (and the humour rather unentertaining) but they made some good points and I made a few notes about their conclusions.
Continue reading

Scaling Agile Software Development for Larger Projects

“Small projects can succeed through sheer force of will and a bit of luck.  Medium and large projects require a more systematic approach” (McConnell, 1998, p. 36).

Most of the Agile Software Development methods are designed for small team sizes, for example the original XP team had 8 people, but what if we’re talking about 30 developers (let alone customers); what process should we use?
Continue reading