Can a project perform PPQA on themselves?

Is it possible to use the project team to achieve PPQA SG1?

We have an idea to use the project team to assure the process using checklists and peer reviews, so the QA just audits work products AND assure that the project team do the checklists or peer reviews.

Is it enough for PPQA SG1?

If you've been following my posts you'll know that I'm not one to say that anything is absolute within the CMMI - local tailoring to accommodate culture and local norms is very important. So, I never say never . . . but . . . .

The PPQA PA specifically calls out the need to "objectively" evaluate processes AND the use of those processes.  It doesn't say "independent" though, but it would be uncommon for an organization to be mature and open enough when first implementing PPQA to perform this objectively on themselves.  Many Lead Appraisers insist on "Independence" to prove objectivity.  This isn't always correct though.

The other problem is that PPQA is the "eyes and ears" of the process deployment effort.  It's job is NOT to be the "process police," it's to uncover problems with the use of the process and make sure that information gets into the hands of the right people and is used appropriately.

One idea I advocate is a "rotating" PPQA responsibility.  PMs and Engineers from other projects serve for a period of time in a PPQA role (say 25% of their time for six months).  This has the hidden benefit of gaining "buy-in" from people who may not be fully engaged, and creates process evangelists. 

www.broadswordsolutions.com

What is the minimum number of projects that need to be appraised?

Is there a minimum requirement for the number of projects that must be appraised for a L3 rating?  I was told that at a minimum 3 projects from the organization must be appraised for all SPs and all the SPs should have been implemented across all the 3 projects. Is that true?

Not exactly.  This seems like an easy question to answer, but like everything else related to the CMMI, it's more complex than it appears.  The SCAMPI MDD (and LA's guide for conducting appraisals) says that:

"In appraisals where the reference model scope includes any project-related PA, the organizational scope must include at least one focus project. If the organizational unit includes more than 3 projects, then the organizational scope must include sufficient focus projects and non-focus projects to generate at least 3 instances of each practice in each project-related PA in the model scope of the appraisal."

It then goes on to say:

- Focus projects must provide objective evidence for every PA within the model scope of the appraisal which addresses model practices applicable to those projects (this includes not only "SPs" but applicable "GPs as well!)

- Non-focus projects must provide objective evidence for one or more PAs within the model scope of the appraisal which address practices performed on projects. 

- Support functions must provide objective evidence for their functional areas (for instance Process audit function, SEPG, management, etc).

So, my reading of the MDD is that if you have three or more active projects, then you must come up with evidence for AT LEAST three instantiations of each practice across the focus and non-focus projects and at least ONE of them has to be a focus project (providing evidence for all PAs).  In this example, you could have a minimum of three focus projects, or you could have one focus project and ten (for example) non-focus projects, as long as you have three examples of evidence for each practice.

The MDD doesn't directly speak to what happens if you have only ONE project (I have several clients in this situation).  My interpretation of the rules here is that if you have only one active project, then that one project is a "focus" project and all of the evidence has to come from that single instantiation.

This scenario is unlikely in ML3 though, because you'll also need to add in "support" groups such as SEPG, QA audit, process management, et al and you will end up with more than one "project" to appraise then.

One more wrinkle.  The sample to be appraised is something that the Lead Appraiser and the Sponsor need to agree upon.  I received an RFP once from a DOD contractor that said they had "already determined the appraisal projects" and that there was no opportunity to discuss it.  That's a no-no.  The LA needs to buy into the sample in order to maintain integrity of the appraisal.

www.broadswordsolutions.com

What is the simplest way to satsify RD3.1 "Establish Operational Concepts and Scenarios?"

I have a problem on how to advice SMEs on the simplest, value added way to implement RD P 3.1 Establish Operational concepts and Scenarios. In which specific work products can we see the development of operational concepts? Is it ok to say that you can see the operational concepts reflected in the following work products as they are refined: non functional requirements, design restrictions, system architecture document, installation manual, deployment diagram, package diagram, component diagram?

First let's take a look at why RD.SP3.1 is even in the model.

Sometimes it's difficult to visualize the feasibility or reasonableness of a requirement without putting it in context. This is one reason prototypes are so popular - they literally paint a picture of what the implementation might look like. When they see this users often say "no, that's not what I meant" or "what would happen if we tried this?" This is a form of requirements validation.

RD.SP3.1 is asking you to validate requirements by putting them into some context.

The simplest and most useful way to do this is with a Use Case, User Story, or Storyboard. They require only a marker and a whiteboard, or software like Visio, to implement. They're extremely valuable at putting requirements in context, and they're low cost, low effort.

Developing a prototype for a more complex requirement, or a proof-of-concept (a "spike") is another way, albeit more costly, to drive out pesky requirements defects.

The other artifacts you've listed seem more like they belong in the Technical Data Package (design documents from TS) rather than in RD, with the exception of non-functional requirements, which need to have RD SP3.1 performed against them to be completed.

http://www.broadswordsolutions.com/

Should process improvement tools be represented in our software process improvement plan?

Our software group is currently revising the Software Process Improvement plan to cover CY2009 process activities. For the lst few years the Software Process Improvement Plan (SPIP) only concentrated on process definition work, however for next year the team has identified tools and applications that will work together with our current processes to improve productivity. The million dollar question is: can we still label this document as "Software Process Improvement Plan" (SPIP) although it contains many tool improvement information. The team prefers to maintain a single document rather than having to maintain multiple documents. What is the industry norm for managing this type of elements (Process + Tool)?

Anyone who has worked with me knows that I scoff at the idea of implementing tools when a process improvement program starts up. Too many companies see a tool as their salvation and end up creating a monster that helps them do the wrong thing – only faster.

<<>>

We had this experience in the Broadsword Labs once when our sales staff, without consulting us, decided they needed a new “tool” for expense processing, went out and bought one, slammed it in, and it wreaked havoc with the client base because . . . you guessed it, they didn’t have a solid process behind it. The clients started seeing all these new forms and reports, no one knew how to use the system, there were errors in the expense reports, it was conusing what the roles were . . . . sounds like some GPs doesn't it?

It’s natural for a company to start to see opportunities where a tool could indeed be helpful after they've deployed some stable processes. Early in the "proces improvement" cycle these tend to be tools related to REQM and CM, then later MA, estimating, and then finally life-cycle management tools like Borland’s CALIBER product line.

I would expect a ML3 company to implement some tools, and to manage that implementation in the SPIP. This is an absolute MUST for ML5 (OID) where piloting and deploying “innovations” is spelled out in the SPs.

However you do it, the deployment of tools should be governed in your SPIP and under the guidelines spelled out in OPF.

http://www.broadswordsolutions.com/