Measuring vs Controlling Software Projects

A lot of project managers and delivery teams don’t know what a truly successful software project looks like. Successful in solving a business problem at a cost less than the return, on a reasonable timeline, with healthy practices that leave the team positioned to turn around and do it again (not adding technical debt or burning out the team). This is something that I think most people in software development sense but no one wants to admit or talk about. The majority of my career as a dev, I was on projects that shipped code late and de-scoped to the bones. I “shipped” a lot of junk early in my career that rarely that met the business need presented to the team through layers of indirection.

The thing is, you can measure important things via traditional project management techniques. Sometimes you can predict useful things too. You just can’t easily control software projects through dials connected directly to those metrics. Throwing more people and money at a project to get milestones back on track is usually the quickest way to knock it further off track. The best way to “control” a project’s outcome is through continuous process improvement and investing in deep understanding of the nature of software development. The shortcut to this is usually adopting Kanban WIP minimization and flow maximization techniques, and thinking through the lens of theory of constraints and cycle times. Rather than throwing resources at a perceived bottleneck, take time to understand if it truly is the bottleneck and if so why it exists.

It is truly rare to find a person who understands how to maximize budget, scope, and time indirectly through iterative improvement and fundamental agility and responding to reality instead of updating spreadsheets.

Who do I know that understands this, has implemented it successfully, and agrees with it?