Random Ramblings on LabVIEW Design

What's the ROI of all this Process Stuff?

Wotcha My Spiffing Chums,

NI Employee of the month (awarded by me) Peter Horn emailed me an interesting question the other day. It was pertaining to the LabVIEW Center of Excellence and associated software processes.

To quote "I was wondering if you’ve ever measured the impact of implementing these processes – either with your own development work or customers you’ve been working with? Everything I’ve found online so far makes sense, but figuring out how to apply it to a specific account isn’t making sense to me just yet."

Now that is an interesting question.......

I feel SSDC has taken a lead in this space over the last 20 years, it's therefore a little difficult to apply a sensible benefits comparison, I then started thinking about Risk Registers. These are things that you need to fill out as part of ISO9001:2015. What if we look at the main points of the CoE assessment as risk reduction techniques and what are the risks we're trying to mitigate. This is very much a work in progress so feel free to chip in friends.

Here's the spreadsheet of the register with the points allocated for out of control projects.

You assign a score of 1 (low) to 5 (highest) to grade Probability, Impact and Control to get a score. Any score over 37 needs urgent attention.

Let's take a look in detail (I think the wording of some of these is poor, but feedback is more important than perfection)

Requirements changes negatively impact a project

Really high probability of this happening, Really, really high!

From the CoE assessment document the mitigants for this are......

Process for gathering requirements
Process for tracking and updating requirements
Process for changing requirements

I'd put this all under team has a process for managing requirements. All we can really do with these is to reduce the Control score. To reduce the Impact score we're talking about Design, designing with requirements changes in mind.

By applying these techniques you can reduce the risk from 100 to 40 fairly easily, take control of your design will reduce it to 20.

Poor design decisions affect the performance of the project

The truth is a bit more extreme in my experience, poor design decisions often kill a project. The ROI of better design decisions is therefore somewhere between 0 and All of the Project Costs!

So we can't really reduce the Impact much, but we can improve the Probability and Control. And you do this through Design Reviews (and training, and templates)

Poor coding practices are allowed unchecked

Similar to the design, poor coding practices affect things like maintenance, team support, quality, reputation. This can go unchecked for months and even years, having a mechanism for doing peer code reviews states up-front that you will be looking at each others code from the off. Just that is valuable.

Lack of code reuse affects competitiveness and quality

I struggled with scoring this one, but for some businesses it's vital. Scoring therefore is relative to use-case.

Poor code management affects project delivery

Poor code management includes not knowing where your code is, not knowing what version it is. Impact is sending broken, untested or wrong versions of the code to the customer.

Plenty of Tools are available to improve the Probability and Control of this.

Tests not applied to ensure customer satisfaction and adherence to specs

Records of tests, teststubs, a testplan, unit tests are all ways to reduce the probability of sending crap to the customer and the cost of sending crap out is not only impactfull on your reputation but also awful for team morale. Cost that one management types!

Poor training affects competitiveness, employee retention (this is also related to poor coding practices).

If you don't invest in your good staff they'll probably go and play somewhere else, that's expensive. Think 120% more expensive than staff retention. It also affects code quality and one would assume it improves productivity somewhat.

Inefficient Deployment and Distribution makes coding as a team costly, projects late

Often a project needs to be scaleable, you will need to have more than one person working on it at a time. Or maybe you just need to have some temporary help. For us it's related to code management as we tend to deal with source-code rather than deployments. But when dealing with deployments there are plenty of tools and techniques to mitigate the risks. Automating this will be an easy thing to cost as a ROI and also can change the way you deliver code. This is especially true when dealing with remote customers as I learnt from Fabiola's presentation at the eCLA summit this year (Technical Debt vs Technical Wealth)