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
- November Online Training Schedule
- How to Cultivate High-Performing, Collaborative Teams
- DHS Brings New Discipline to Cyber Planning
- State Department Bets Big on Data-Driven Diplomacy
- Augmenting Intelligence in State and Local Government
- How One Agency Wove Zero Trust Into Its Culture
- How to Lay the Foundation for Long-Term AI Success
- How the Modern Data Center Raises the Stakes for Network Reliability
- 5 In-Demand Skills for Modern Government Workers
- How to Apply Empathy as a Business Skill
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.