5
Mar

Make it Big ……. Make it Visible

Make it big
There is a big difference between measuring progress and showing it – I want to focus on the latter, almost ignoring how any kind of progression to the ultimate or milestone destination is tracked. No, this is about disseminating that information. So, once this information is collected, how do we distribute this?

I am a fan of big, visible pictures, available for all the necessary people to see. That is obviously anyone that is part of ‘the team’ (whatever that means, and whatever software development life-cycle model is utilised). But here is the rub: it can also mean the project sponsor, key business users and the HR department. They can see the summary of progress, or lack of it. It is GREAT to have progress visible to ALL – including the IT Director. It prompts interest, and causes the ‘casual passer-by’ (seldom casual and NEVER a passer-by) to ask questions. Is this a good thing, or a bad thing?

On one project I worked on, there suddenly appeared a big picture on the wall one morning. “Days to go Live: 45”. Wow – that concentrated the mind of all concerned. In 45 working days, what had been under development for over 2½ years would be rolled-out. These five words encapsulated the project position, and were visible to all. As you entered the large open-plan office, you could not miss the words, which were more powerful than many whole-project e-mails. Needless to say, the ‘45’ counted down day by day until it said ‘0’.

Make it visible, and then all can see it. It will also influence our actions so that the figures both tell a story and are part of the story. “Last week, we were 90% done. So this week we want to make sure that the chart shows progress. What can I do today to show that we are now ‘better’ than previously”? Having said that, I truly believe in a binary state of progress on individual parts. If the coding / testing / test plan / data acquisition for the module is not completed, then it counts as nothing. This gets away from the situation where atomic progress is 90% complete for days on end. If it is not 100%, then it is recorded as 0%.

How do you measure progress? Is it tests run? Tests written vs. tests passed? Perhaps a burn-down chart of the expected deliverables in the latest sprint, and what has been completed. One of my favourites is a table of bugs raised / bugs closed / bugs outstanding, at weekly intervals. This is a simplistic view, and does not go into the severity or priority of any defects raised or outstanding. However it does give a summary of where the project is, from a particular view-point. Even this view is of little relevance if no-one sees the information, and as necessary does something about it.

Put the information where it will be seen, and it can and does make a difference. Here is an amusing set of information, amusing but sad. “The first 90% of the features were implemented in 70% of the time using 85% of the budget”. So far all looks well. However, it is not finished. “The remaining 55% of the feature-set took 65% of the budget, and 75% of the time”. All three of the elements (features, time and budget) add up to more than 100%. In some organisations, one of these three can be more important than the others, and it depends upon the particular organisation as to which has pre-eminence. But to have ALL over 100%? That smacks of a project out of control.

The mere publishing of measurement details is beneficial for all. It enables key stakeholders to see whether the project is on track, encourages those building and testing to actively chase progress targets and lets users know when the software will arrive on their desktop. Big Visible Pictures tell one story in the same way to all. They are Big (can be seen from 5 yards away or more), Visible (the information is displayed for all – including the illusionary ‘casual passer-by’) and are a Picture (ideally diagrammatic with few if any words). They give a summary very effectively. If you have not used this approach before, try it. It can and does make a difference.

We want to avoid the situation where all three of ‘features’, ‘time’ and ‘budget’ end up at over 100%. Big Visible Pictures cannot stop this happening, but problems will be known about as they are happening, rather than come as a nasty surprise. You do need to be careful what you measure, but that is another topic ………………….

Peter Morgan, Freelance software tester @MorganpPeter

Web www.Nicemove.biz.

Share This:

Leave a Reply