14.2 IN BY THE BACK DOOR

 < Day Day Up > 



14.2 IN BY THE BACK DOOR

If you have authority or responsibility for a metrics initiative and you sit within some functional group removed from mainstream development, perhaps as part of an R&D group, then reducing the scope of your metrics initiative may well appeal. What do you do if you do not really have management's eye or the explicit responsibility for process improvement within the organization, through metrics or through any other means?

It is possible to slide metrics into an organization through the back door but it can take a long time and it can be quite frustrating in the short term. Let us set up a scenario and then look at a particular solution that may work.

You are a manager. You do not report directly to the Systems Development Director, in fact there are numerous levels of management between him or her and your lowly self. You are responsible for a particular software product and you know that you and your team are struggling with problems. You believe that there are better ways of doing things and you have perhaps come across the idea of management through measurement at a seminar. Such a concept appeals to you but you know that you do not have enough clout to drive such an initiative through the organization. Anyway, apart from anything else most of your time is spent managing your own team.

Try this approach. Get your first-line reports and any other team members whose opinion you especially respect into a room for a few hours. The agenda is "process improvement." Ask your colleagues what the major problems are today. From what they say and subsequent discussion you should be able to arrive at a small set of key requirements that need to be addressed to improve things for your group. Obviously you need to concentrate on items that you can affect.

Assign one individual the task of designing a solution that will satisfy the requirement. Give them visible support; help but do not overshadow, and aim to get a revised process in place within two months.

Run it for six months and at the same time target the next major problem area. Do not go for sledgehammer solutions. You are looking for levers to move things to a higher level of effectiveness. This means that you cannot put in fantastic, whizbang, automated solutions and that all you may end up with, apart from a better process, is a paper and pencil system supported, possibly, by a spreadsheet.

Within nine months you should be able to identify a significant improvement in the way your group operates. Of course, you will not be the only one to notice this. Management will also become aware of improvements and so will other teams. You may well find that you start to get inquiries from these other groups and from management. The problem with this is that you may end up managing the metrics initiative for the whole organization.

An excellent example of metrication came from a large European organization. One divisional manager got fed up with not being able to control software development projects, and to counter this put in place a process based on simple and regular information-gathering from project managers using straightforward metrics about progress against plans. Things improved quickly and dramatically. The end result was the extension of the project control process to all software development divisions. The fundamental key to this approach is that, as an individual, you can accept responsibility for improving things. The question is, will you accept that responsibility? Measurement is only one aspect of this work ethic. Measurement gives solid information on which to base management decisions and, furthermore, can demonstrate unequivocally that improvement has occurred.



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net