Continuous Improvement Over Project Management
My operations management class taught two discrete methods of measuring and improving: traditional project management, and continuous improvement. The general heuristic for which to use was “does it have a budget and a timeline and outcomes?” If yes, then it’s a project to be managed. If it is an ongoing process, then best use continuous improvement tools like Kaizen and Kanban. But in the software industry, you almost always get better results prioritizing the latter over the former even though there’s almost always a budget and timeline and outcomes. The reason is somewhat counterintuitive, but you will achieve better control over a software project by understanding its processes and pitfalls deeply and improving the current reality iteratively than by trying to estimate and control what remains. Project management tools like Gantt charts and critical path calculations share a key weakness — they need accurate estimates. If there’s one thing the software industry has proven time and again that it can’t do well, it is estimation of future work, both known and unknown.
Just as the Agile Manifesto values certain things over others, I also assert: while traditional project management tools are useful, I find much more value with continuous improvement practices in achieving important goals.