What are the roles and responsibilities of a CMMI sponsor?

Dear CMMI Appraiser, I work in health care support services in Maryland. Our two biggest clients are requiring us to adopt the CMMI, and guess who got picked to lead the effort? Can you tell me, what are the roles and responsibilities of a CMMI sponsor? ~ Paula R.

Paula, as more companies are responding to client demands that they adopt the CMMI, the CMMI Appraiser has received a steady stream of questions about managing this change. One of the leading experts on this topic is Julie Calfin, a Senior CMMI Consultant with Broadsword. Julie does amazing work with companies who are undergoing large scale business transformation. Take it away, Julie! ~ The CMMI Appraiser

Thank you, CMMI Appraiser!

Paula, congratulations on being selected to lead the transformation of your company! That’s a big vote of confidence. Adopting the CMMI is a change that will affect everything – process, technology and people – and you are wise to seek out information about the roles and responsibilities that will help you architect that change.

As I mentioned in an earlier post, Organizational Change Management (OCM) techniques are there to help. Like an architect’s blueprints, OCM principles guide the process of changing behavior throughout the company, and allow you to make the changes quickly, with minimal disruption on the business.

What are the roles and responsibilities of a CMMI Program Sponsor?

The company should establish the governance of the CMMI-based process improvement program at the beginning of the program, and provide you with training to perform your role as the CMMI Program Sponsor. You may find it helpful to think in terms of the behaviors you need to exhibit as a program sponsor:

• Serving as the “champion” of the program and its results

• Aligning the goals and objectives of the program to the organization’s vision and strategic business objectives

• Allocating resources to the program, including people, equipment, and tools

• Reviewing the actual performance of the process improvement program against its plans and estimates

• Removing obstacles that may hinder the program from achieving its goals and performing according to its plans

• Providing authority for the policies that require the organization’s process assets to be followed by their intended users

• Overseeing the performance and maturation of the organization’s processes, and ultimately, the optimization of these processes

The good news is, your behavior is under your control. By exhibiting effective behaviors, you can lead a successful process improvement program, and help transform the company.

I’m excited for you, Paula! Please check back and let us know how you are doing.

Like this blog? Forward to your nearest engineering or software exec! 

Julie Calfin is a Senior CMMI Consultant with BroadswordSolutions Corporation. She has years of real world experience using OCM strategy and tactics to help her clients achieve their goals. Julie also uses the CMMI, in partnership with her clients, to set-up, monitor, and sustain process improvement programs.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.

Does the Agile Manifesto "forbid" writing down requirements?

Hey, CMMI Appraiser – I’m a member of an an agile team for a Maryland contractor to the National Institutes of Health. We just started designing a fairly complex financial system for NIH, but one of my teammates is adamantly against writing down changes to the requirements. He says the Agile Manifesto forbids it – but our boss clearly thinks it’s important. Does the Agile Manifesto really forbid writing down the requirements? ~ Carol W.

Carol, I had the same conversation with an XP team a couple of weeks ago. They said, “We don’t see any value in writing down the changes to the requirements. Business value is in our software, not in documents.”

Suffering through unclear requirements is not a question of "if" but "when" on any project team.  In my experience, anyone who says that has never suffered from the confusion and chaos that inevitably occurs when a team loses track of the current state of requirements (just ask any tester or customer).  In the case of your colleague, I strongly suspect he is mistaking the Agile Manifesto, a very well thought out, disciplined set of guidelines, for the "Lazy Manifesto."  Only one of those approaches is going to help make your company great (hint: it's not the Lazy Manifesto).  Let's take a look at what the Agile Manifesto actually says (with compliments to Sutherland, Jeffries, Beck, Schwaber, Beedle,  Cockburn, et al):

No doubt you've seen this before.  At this point, the Agile Manifesto is so familiar that a mythology has been built up around it. After listening to so many people talk about it I get this mental image of a gang of brainy geeks climbing up a mountain-side, complete with crampons and ice picks, setting up a smoke lodge, and sitting there on the mountaintop for a couple days. Smoke fills the teepee, and on the last day, out comes a puff of white smoke along with the Agile Manifesto, along with a torrent of hundreds of conferences and books!  Everyone in the teepee goes on to become a superstar and software is defect free and on-time forever!  Did I mention the rainbows and unicorns?

It turns out these folks got many things right … and one thing REALLY right.  Collaboration and communication  (and the structure to encourage them) are pivotal for creating great software.

They were also smart enough, as the founding fathers and mothers of "Agile," to say about the stuff on the right: “This stuff is important too.”

But somewhere along the way, too many people took a paper cutter to this document, and focused only on the stuff on the left.  This may be why your colleague is confused.  This is where comments like "business value only exists in code" came from.  That is ONE of the places business value exists, perhaps the most important, but not the only place.

So, IMHO, it is important to write down requirements.  Does it have to be a huge, heavy specification?  No, it can be as simple as sticky notes or maybe in a tool like iScrum or Process Focus.  Applying discipline to your Agile methods will help your team, customer, and boss understand the business issues at stake. This will help make your team more successful and put you in position to take on larger, more complex projects.

To be clear, when I say "apply discipline," I don't mean rigidity and useless documentation.  Of course we care more about the stuff on the left.  Just remember the stuff on the right is really important too.

Sounds like your colleague is about to get his first experience with that.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.