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/