One of my assigned tasks as manager of a recently formed PMO is to develop a SDLC/software development methodology. Not quite the role of a PMO, but so be it.
If I had to characterize our organization, I'd make it about a CMM 1.5. We have some defined coding standards and such, but no real process. PM practices are pretty dismal.
Although it's early in the game, I thought it might be a good idea to form a SEPG now to assist in the creation of new processes. The literature I've read says the first step is to document current processes and then identify areas for improvement. Since there is no real process in place there's nothing to document or evaluate.
My question is how should the role of the SEPG be defined at this point? My idea is to define the processes as I think they should be with strong adherence to IEEE standards and then let the SEPG review and modify as they see fit. The SEPG members don't really have the time to get involved in ground up process definition. Unfortunately our first try at this was disasterous. I must say that I was rather beligerent as it seemed that the prevailing attitude was that they saw no reason for having what they considered to be much too rigid and cumbersome a process. Given that attitude, if they are empowered to alter it as they see fit, I'm afraid we'll end up with a gutted shell that doesn't really get us where we need to be.
I'm thinking that there should be some sort of precursor to a full blown SEPG that offers advice, but with limited authority to make modifications until something has actually been put in place an utilized. Does it make sense to charter a 'weak' SEPG now and the re-charter later to give more authority. In the long term, I definately want to turn the whole thing over to the software development organization for management. Saving Changes...
Sort By:
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Lyle, Before you form a Software Engineering Process Group, I think you should develop the group's objectives from the viewpoint of top management. I would begin the group by reviewing these objectives and have them help you craft the GAP analysis between the CMM level you are currently at and the level that the management wants you to be at 12 to 18 months from now. From there you can review the current process issues and workflows to identify improvement opportunities. An SDLC can be a good or bad thing depending on its deployment, so go slow and be sure that at the end-of-the-day, you deploy and SDLC that provides the speed and flexibility needed to support maintenance, new development, package evaluation and the like. Good luck. Saving Changes...
Linda Yee Man ChengAssociate| Morgan Stanley Asia LimitedCauseway Bay, Hong Kong
I am basically a one person SEPG for this small software startup I am working for. Most of the battle is human resistance to change. I'm just lucky this is a new company and I have the license to turn their world upside down. The key is easing changes in slowly. People need time to get use to new ideas and new ways of doing things. The processes I've churned out so far are mostly based on best practices from Rational Unified Process, CMMI, and bits and pieces from Rapid Development and Agile. I find RUP very comprehensive. I use CMMI's key processes as guides/goals when tailoring processes to fit my organization. Mind you, a lot of tailoring needs to be done to make it workable for the corporate culture. I would say in fact 20% would be researching on the processes, and the remaining 80% just figuring out what the spirit of the process is and how do I interpret (tailor) it to work for my organization. Saving Changes...
A one man army will not hold much water in Quality group. You need to identify key persons with the help of top management who would assit you in deploying processes.
This would tremendously help gaining insight into the teams responses. Saving Changes...
