Saturday, July 26, 2008
The project's software development lifecycle (SDLC) specifies managable project phases, such as analysis, design, code, and test. The SDLC is one of the necessary components, along with the tasks, activities, and work products, that are used to estimate the scope, effort, and cost for the project. Each project phase usually concludes with a decision point and/or project milestone. The project's processes govern the tasks and activities that occur within and across each lifecycle phase. The project processes do not determine when project milestones occur and neither do they determine which project milestones occur. These two aspects of the project are determined by the SDLC.
The other aspect of the project's SDLC is that the project's processes are a function of the SDLC chosen for the project. If the project uses a waterfall SDLC, the project's processes would be very different from those needed to support an agile SDLC.
Friday, July 18, 2008
A few years ago I took the official CMMI v1.1 Introduction training. Given that I don't have a lot of time right now, I was wondering how much longer the upgrade training to v1.2 would stay available - just to be sure I don't have to spend another 3 days later on for the intro to v1.2.
I asked this question of Mike Phillips several months ago and he said that the SEI has no immediate plans to do away with the v1.2 Upgrade class. Over 40,000 people have been trained on either CMMI v 1..0 or v1.1 and only a fraction have taken the upgrade. So there is an ongoing need for the Upgrade class. Given the v1.3 information I posted on this blog on May 12 CMMI Updates from the SEI and the fact that the Intro to CMMI class will be changing at some unspecified time in the future, I would expect that the SEI will also be producing a v1.3 Upgrade class that could replace the v1.2 Upgrade class (pure speculation on my part).
Thursday, July 17, 2008
This looks quite exhaustive, please advise.
- ANOVA Reliability Growth Modeling
- Chi-Square Response Surface Modeling
- Regression Time Series Analysis
- Logistic Regression Hypothesis Testing
- Dummy Variable Regression Logit
- Bayesian Belief Network Monte Carlo Simulation
- Designed Experiments Optimization
- Discrete Event Simulation
- Reliability Growth Modeling
- Response Surface Modeling
- Time Series Analysis
- Hypothesis Testing
- Discrete Event Simulation
So what would be very helpful for you is to either get some training on data analysis and statistical techniques or hire a statistician to help you with your High Maturity efforts. Then you will figure out which quantitative analysis technique(s) are appropriate for your data and your organization.
And, to quote Pat O'Toole: "High maturity is NOT just about statistical techniques. Rather, it is about performing your critical processes so consistently that the information to be gleaned from the use of these techniques contain more signal than noise. You can use the data streaming off the critical processes to detect abnormal performance, and to predict (in a statistical sense) future outcomes of interest."
Thursday, July 10, 2008
The best advice that I can give you is to take the SEI’s 3-day Introduction to CMMI class. That class will provide you the basics for understanding what you need to do to achieve Maturity Level 2.
A very important concept to understand is that there ISN’T any canned set of documents or templates that you have to have in order to achieve Maturity Level 2. The specific processes you need to document and the associated process assets are a function of the work you perform and the methodology you use to produce your products. I would also suggest that you hire an SEI-authorized Lead Appraiser/consultant to help you understand how to implement the model and achieve Maturity Level 2.
An alternative is to read some of the many books that have been written on how to implement the CMMI. Just look at Amazon for some ideas.
I don’t think the EPG or SEPG for that matter was ever referenced in the CMMI. Though I could be wrong. I just checked the v1.1 book and it doesn’t mention the EPG or SEPG in OPF GP 2.4. In point of fact, there is no difference in OPF GP 2.4 between v1.1 and v1.2. You are correct in referencing GP 2.4 because that is the GP that expects a group such as the EPG or SEPG to be assigned responsibility for OPF. However, the reason the CMMI does not mention these two groups is because you don’t need a group named the EPG or SEPG to perform the OPF activities. You can call the group whatever name you choose, you just need to assign the OPF responsibilities to someone or some group. And a group can be one person.
Tuesday, July 8, 2008
For me, the best way to perform day-to-day-monitoring outside of regular Stakeholder-meetings is "management by sneakers" and ask frequently intrusive questions like "Are you performing as planned?", "Do you follow the plan?", "Did you use our template?", "Why did you not follow the plan (or our process)?", "Does our process or template fit your needs?" etc. That's much more effective than scheduling a meeting and brainlessly pounding on a checklist.
But I always have problems then finding direct artifacts, when things are running smoothly. I am highly convinced, that nothing has to be produced for appraisal's sake, only. What do you think?
I find that every client I appraise, big or small, has difficulties understanding the difference between GP 2.8 and GP 2.10.
GP 2.8 is monitoring and controlling the process WHILE you are executing it, not after the fact.
Reviewing the results of having followed the process at some later time with higher manager is essentially GP 2.10.
I don’t see a difference between large or small settings when performing these two practices. The only difference would be the actual procedures. Large organizations would have more projects and procedures to monitor and control and then report on than small organizations. And for real small settings it is usually the same people performing both GP 2.8 and GP 2.10, and that is usually why small organizations have difficulties with these two GPs.
Your day-to-day monitoring questions sound much more like the questions PPQA should be asking during a process audit. And you are right, these are invasive questions for the monitoring of a process while it is being executed.
Here is what I advise clients as acceptable evidence for GP 2.8 and GP 2.10:
Direct Evidence is usually the process monitoring as demonstrated in a report at some project status meeting or review.
Indirect Evidence is either a corrective action resulting from the monitoring or the meeting minutes.
MA must be used to monitor and control GP 2.8, the same way as it is used for all project measures.
The emphasis is on PROCESS measurements and PROCESS reviews NOT project monitoring.
In a Maturity Level 3 and above organization, there should be organization-wide process statusing, activity reporting, etc. at the organizational level as well as the project level.
The emphasis is on PROCESS measurements and PROCESS reviews NOT project monitoring.
Direct Evidence may be the monthly project reviews that include the status of the project’s processes AND the monthly/quarterly process or SEPG reviews
Indirect Evidence would be meeting minutes and/or meeting agenda for the evidence provided as direct evidence.
Suppose in an organization all the projects are following the organization's standard processes correctly. What additional things can PPQA can suggest to the project? For example can PPQA suggest the best tailoring for the project scope etc.?
Please let me know what types of value added tasks can be done by PPQA. OR in other words, please describe possible checkpoints that PPQA can check during an audit.
I look at PPQA and auditing the same way I look at the testers and tests. If the testers are using a specific test case and over time the test case is executing properly and no longer finding defects, then the test case needs to be examined to determine if it is still needed. Perhaps the test case is no longer valid. Perhaps it needs to be enhanced to make it more useful. Perhaps it needs to be kept and used for regression testing. Etc. The same is true for PPQA and the audits. If an audit is no longer identifying issues or non-compliances, then you have to question the audit’s effectiveness. You also have to question the frequency of conducting the audit.
Personally, I would be highly suspicious if all of your PPQA audits came out clean with no findings. Over time as your processes and procedures become institutionalized I would expect that you would find less and less non-compliances, but not zero. People make mistakes and when someone new joins the organization it will take some time before they have personally institutionalized their processes.
PPQA has two roles in the organization:
- Process consultants
- Process police
PPQA is there is enforce the organization’s processes and procedures and identify when they are not being followed. When an issue is discovered in an audit, PPQA needs to determine the root cause. Is the process broken/inadequate? Is it a training issue? Is it a personnel issue? Etc. And PPQA is also there to help people understand why and how to use the organization’s processes. So it is perfectly reasonable to have PPQA suggest process changes, tailoring options, improvement suggestions to the project, etc. while coordinating with the SEPG or EPG.
Monday, July 7, 2008
Do we need to collect measures and have measurement results for all the Process Areas or would just conducting lessons learned at the end of a milestone/phase/project be enough to satisfy the practice? Lessons learned in our case are mostly qualitative comments only and very few quantitative. We have all the planning and tracking related details available in EPM and other associated templates.
Please keep in mind that GP 3.2 is a generic practice and it applies to EVERY Process Area (PA) from Maturity Level 3 and up. It also happens to be one of those compound practices that require multiple things. In this case four different items to collect and feedback into OPF, OPD, and IPM. The advice that I give my clients when preparing the PIIDs for an appraisal is that the process work products you provide for GP 2.6 should be the same work products you are submitting for GP 3.2; the process measures that you use to monitor and control the process in GP 2.8 and the results reviewed with higher management in GP 2.10 should be the measures and measurement results you are submitting in GP 3.2. Therefore, the only additional piece of information required by GP 3.2 is improvement information from planning and performing the process. Sometimes this takes the form of lessons learned, which is an exercise focused on gathering data on what worked, what didn’t work, and what should be changed for future use. There are other ways of collecting this information without conducting a formal lessons learned meeting. But the bottom line is that you are EXPECTED to collect all of these data items for every PA in scope of your implementation and appraisal.
Another point is that these four items are independent of each other and therefore would be collected at different times. Conducting lessons learned meetings at the end of a milestone, phase, or project is a good practice and they don’t have to be quantitative in nature, unless you are at Maturity Levels 4 or 5. What you are trying to do is surface candidate process improvement suggestions from the people who have just used a process.