So sure, I’ve read a ton about doing a capacity maturity model and in theory (and according to my practice versions) I understand how to do one. But in reality, I’m finding it more difficult to place this tool into practice. So when do you implement this kind of tool? Do you do it because the sponsor of your project requested it? How useful has it been for you?
Recent Articles on GovLoop
- Rethinking Networks for the Age of AI
- How to Be Productive Without Burning Out
- Improving Agency Efficiency to Improve Public Trust
- Why It Might Be Time to Move on From Cyber Risk Management
- What You Need to Know About Bots and CX
- Why Workflow Modernization Makes Such a Difference
- Featured Contributors Lift Up Public Service
- What PSRW Means to Us at GovLoop
- Digital-First Communications: Reaching People Where They Are
- Data Is the Heart of AI
I’m more familiar with the similarly named capability maturity models, which are sometimes discipline (ie, project) specific. In my experience, they’re used to measure between projects and a way to push projects (or programs) into determining reliability and valid results. I think they have a practical application if you’re looking to grow a project to another phase or looking to justify resource increases.
I don’t think we’ve been tracking projects within the agency that way and maybe that speaks to our organizational maturity? That or I’m just not in the “loop” with the crowd that does this tracking.
Section 6.2 of Agile Software Development with Scrum discusses the problems caused by applying the Capability Maturity Model to software projects: “the assumption that software is manufactured and that it therefore should follow similar processes to manufacturing is incorrect…. Watts Humphrey prodded us to use a manufacturing model in software through the CMM…Humphrey borrowed the Manufacturing Maturity Model from Crosby… and that has left us with a history of 20 years of software development that has tried to emulate manufacturing process models. … software better fits the model of new product development. But creating something new requires research, creativity and learning. These activities are based on different assumptions and require a completely different way to estimate, plan, track, and manage than those techniques used in the manufacturing of products.
I’ve noticed a trend towards using agile software development on new projects. It’s about time. The Scrum book explains how and why this approach to managing software projects works so well. I like this quote from a presentation on scrum: “Scrum will help you fail in 30 days or less.” The quote explains the core difference between agile development and waterfall development. You don’t spend years planing a project that is doomed to fail from the outset. The planning horizon is always short and targeted at solving small, manageable tasks. If a project takes a wrong turn and a scrum session fails the most you loose is 30 days of effort on the project.