Politically and Technically Correct ?

Search:   

Document Info.
First Published
SM&P Issue 3
Reference Category
Applying Software Metrics

Related Info...
Articles
Services
Training

Reference
Categories
Articles by Title
External Ref's
Other Web Sites

by: Grant Rule

The terms `man hour', `man day' and `man month' have been known to cause comment. Where necessary, I have long adopted the habit of using such terms as `work hour', `staff day' and `staff month' - I believe the intention is clear and it just avoids any possible issue.

However, there remains the technical problem: what on earth do the terms `staff day', `staff week' and `staff month' mean?

The answer? Very different things to different people. I make it a habit to collect such figures. Companies in the UK have variously told me they use `staff month' (or `work month' if you prefer) to imply anything from 108 work hours to 200 work hours (!!! Who are they kidding?), with a mean of 142 work hours. By the way, a `work hour' is an hour spent on productive work; that excludes lunch breaks, interruptions, comfort breaks, etc., but obviously the `product' resulting will vary. This essentially is the measure of expended effort known by the International Software Benchmarking Standards Group (ISBSG) as `Reporting Method C'.

A `staff day' may mean anything from 8, 7.5 or 7 hours spent physically present in the office (plus 2 to 3 hours of unpaid and unaccounted overtime), to the more realistic 5.2 or 6.5 work hours actually expended on productive work for the projects of concern.

As there is a 35% difference between the optimistic 8 hours and the more pessimistic 5.2 work hours per staff day, it seems rather important to have a `mutual understanding'.

So far as I am concerned, the only `safe' scale is `work hours' where we mean `an hour of effort spent on productive work'.

For estimating I would expect and plan no more than 5.5 work hours/staff day (unless the organisation has explicit procedures in place to maximise productive effort e.g. red/green time, `do not disturb' schemes, telephone rotas, etc.). This gives 110 work hours per staff month i.e. 5.5 work hours/day x 5 days/week x 4 weeks/month = 110.

Alternatively, 365 days/year less 52 weekends less 6 Bank Holidays less 20 days vacation = 235 staff days/year multiplied by 5.5 work hours/staff day = 1293 divide by 12 calendar months = 108 work hours/staff month (rounded). And many Europeans/British have more than 20 days vacation each year, so you could charge me with over-optimism!

However you work it, any expectation of more than approximately 110 hours of productive work in a period of 20 days `at work' is unrealistic. Differences in definition/meaning with respect to effort often far outweigh the range of error in functional sizing.

Related Information

back to top

Articles

Count Me In
Every 10 years since 1801 there has been a count of all people and households in the UK... Organisations can conduct a software related census.

Software Project Census
Details of a typical approach used and the services available from SMS for conducting a census.

Planning Counts
Measurement programmes and benchmarking exercises need to be planned and managed. For ideas we look at the 2001 Census.

Tick, Tick, Timesheets!
With just your normal timesheets, your work breakdown structure and a spreadsheet, you too could soon have your project running under statistical process control.

RAG States
Using Red, Amber, Green status to manage corrective action.

Performance Assessment
To compare project performance, identify improvement opportunities and make good estimates for future projects, you need to assess the performance of existing projects.

Services

Applying Software Metrics

Data Collection
Services for identifying, collecting and checking measurements.

Starting a Measurement Programme
A measurement programme is part of a means to an end (one or more business objectives). To deliver any benefit the objective(s) must be clearly understood first and then the measurement programme must be designed to support them.

Supporting a Measurement Programme
Once successfully started, there are various activities required to keep the measurement programme operating effectively and the results relevant.

Estimating and Risk

Early Estimation
Estimating software size from the feasability stage through to early requirements gathering. Also approppriate for otuline designs.

Estimating Cost, Duration, Effort, etc
Developing estimates of cost etc from measurements or estimates of size in combination with other constraints.

Training

Manager’s Guide to Software Measurement  Overview
Understand how disciplined, quantitative practices can be used to control costs and maximise productivity.

Software Measurement Services Ltd.
124 High Street, 
Edenbridge, 
Kent, 
TN8 5AY 
United Kingdom  
  tel +44 (0) 1732 863 760
  fax +44 (0) 1732 864 996
 e-mail: sales@measuresw.com
  www.measuresw.com

© Copyright 1997-2004 Software Measurement Services Ltd. All rights reserved.

                                               
Applying Software Metrics
Assessing Capability     
Estimating and Risk       
Improving Processes     
Measuring Performance
Sourcing                       
Tools and Techniques   
             
                
Services               
Training                
Events                  
Reference             
                
About SMS         
Opportunities
Copyright & Legal