Good discussion of doing product management instead of project management. Also, discussion of user metrics to track design and usability:
“Defining success metrics helps you focus on what’s important in your product and how well it solves the problems you’ve identified. Defining key steps the user must take is also important in order to shine a spotlight on where in the process users are failing. With this data, you can conduct further in-person research to understand why they are failing and devise an even better solution.”
Original source: Project vs. product management, in government
‘That discussion starts with a very concise and useful distinction between project management (the world the government knows) and product management (the world it doesn’t). Project management, they write, is “focused on managing to a plan” — such as managing schedule, budget, risk, policy compliance and then reporting status to stakeholders. “Success for a project manager is delivering a defined scope of work on-time and on-budget,” Johnston and O’Connor note. Product management, meanwhile, “is focused on delivering a product a user wants or needs.” Success for a product manager “is delivering a product that users love — and use to complete tasks (or in the private sector — a product customers will pay for).”’
Original source: Project management vs. product management
“Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.”
Original source: Why Your IT Project May Be Riskier Than You Think
The primary measure of progress for the Scrum Team is working software, but the primary measure of progress for the Product Owner is user stories that are “ready,” which is a very nebulous concept.
a Kanban board can make a cross-functional team feel more like a reality. In a large organization, where there are specialist systems, software, hardware, and test engineers, the various disciplines are usually not going to start performing work in each other disciplines, no matter whether or not they are on the same agile team. But by working off the same board, at least they are in the position of being able to visualize each other’s work and see how what they are doing contributes to the success of the whole program.
the advantage of lean and Kanban approaches is that they make explicit and visible the full state of a program in a way that encourages people to make good decisions for improvement to the process as a whole rather than optimizing for one part of the process. This includes the poor product owner, whose work is finished before most agile boards start.
From: “The Case for Lean: Capturing Business Work”
This is pretty much all the project management us kids who grew up in the 80s learned.