I want some information in regard to SEPG's (Software Engineering Process Group). Basically we are lookingat two aspects: Typical structure of SEPG with their responsibilities, and b) Compliance with CMMI Level 5 requirements. We are not sure if it is a requirement of CMMI to have a formal SEPG in the organization. Looking forward to some guidance.
Every SEPG I have come in contact with has had a different approach and mission. Some of the flavors include:
"working" SEPG's that actually develop and deploy process as a type of internal consulting team.
"oversight" SEPG's that oversee the process architecure, approveit, manage changes, and prioritize it (sort of a process CCB)
"deliberative" SEPG's that debate the process approach and develop strategy for a process architecure and deployment
"virtual" SEPG's that are made up of representatives from throughout the organization that dedicate a certain amount of time to the effort and are responsible for deploying and training everyone else in the organization
.. . . and everything in-between.
My favorite is the "virtual" SEPG because it helps the entire organization feel ownership of the process, thereby bypassing the most difficult and hard to achieve step - acceptance. The real difficulty here is getting people to dedicate their time and to make them accountable. You're trading one challenge for another but the latter challenge is, in my humble opinion, easier to manage. Don't underestimate the difficulty in enterprise acceptance - it's by far (an order of magnitude) the most difficult to conquer and the primary reason why the failure rate is so high. Approach and the mission of your SEPG (or whatever you call it) is very important to the success of your effort.
In terms of it being "required?" The model doesn't dictate any requirement for an SEPG. You can look to OPF, OPD, and OPP for guidance on the "mission" but, that said, there are more than 100 ways to skin the cat, name the cat, and cook the cat and in the end these are only guidelines.