A Software Process Improvement Portfolio

Subsequent to my previous post, I thought we could clarify some issues using a Software Process Improvement Portfolio approach.  As noted earlier many methods appear to extol the same virtues and build up a strawman of other methods to differentiate themselves.  The implementation is often lacking in specifics to show differences to those who have come before.

While some SPI approaches provide guidance for selecting them e.g. good for safety critical domain,  bad for teams > 50 people – generally these tend to blend and an ad-hoc approach is taken (often by default).  This means that many companies have a multitude of improvement approaches – some new, some legacy and other just vague remnants of what happened before.

I guess we’ve all seen TQM, Quality Circles, Deming and other approaches lurking about the place – some still used, others still around but no one knows why and what it was supposed to be for.

Typically when an organisation has staff turnover, they of course lose a lot of corporate memory.  Sometimes the turnover includes PI sponsors, champions or similar.  The remaining staff then have to pick up the pieces and carry on – but because of the budget cuts that invariably accompany these turnover re-orgs, carrying on is rendered almost impossible except to use a template here and a form there.

What is lacking?

A whole of business i.e. portfolio view of improvement initiatives.  Ask yourself:

  • have we identified all of our current (and remnant) improvement and change initiatives
  • are these initiatives still happening?
  • have they been institutionalised/operationalised?
  • how committed are staff to them?
  • how do they align with current company objectives, structure, focus, direction, technologies?
  • can they be prioritised?

It’s this prioritisation process that enables a purging of unused activities and initiatives.  If a method or improvement approach is still about but hasn’t been used or touched in 6 months, you can be pretty sure it can be dropped.  Do a lessons learnt, use what you can and close down the initiative.  By doing this the improvement initiatives can remain fresh, relevant and focused on what is needed.

Whilst cost benefit calculations are notoriously difficult due to competing projects and compound variables e.g. was the defect rate reduction due to the ISO9001 initiative or a peer review process as instigated by CMMI?  Or was it a technology improvement?

Even still, by looking at the tasks implemented including

  • what was intended
  • cause/effect
  • what occurred

We can begin to identified potential weightings of attributes from each SPI approach and then use this as a basis of comparing impacts from improvement methods and their eventual impact on company objectives.

This entry was posted in agile, CMMI, defects, improvement, method, peer reviews, process improvement, software quality and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s