7 Effort
Introduction
This chapter discusses issues associated with effort tracking. These are suggested guidelines.
Specific implementation should be driven by your organization's needs.
Contents
This chapter includes the following sections:
August 1994
Page
Section
7-2
Overview
7-4
Effort-Tracking Issues
7-8
Suggested Implementation Approach
7-10
Sample Project Types and Effort-Tracking Activities
Guidelines to Software Measurement
7-1
Overview
Effort
Overview
This section defines effort tracking, discusses why it is a critical measure, and lists the
objectives of effort tracking.
Definition
Effort tracking is a method that allows for tracking work effort by activity and/or task.
Effort tracking may incorporate a method for collecting time for customer billing (internal or
external), project time tracking, and/or attendance. The needs of the organization should
drive the requirements of the effort tracking system.
Note: Because of billing or effort tracking policies, be careful about using billing
information for effort metrics. For example, an Information Systems department may bill
only for 40 hours per week when 60 hours are worked. If the billing information is used to
plan the next project, there is a very real risk that the project effort will be underestimated.
What Is Not Included as Effort Tracking
For the scope of this document, effort tracking does not include the following components:
 Project management
 Estimation
 Function point tracking
 Charge back or customer billing
While each of the above functions is certainly critical and may interface with effort tracking,
it is not necessarily a part of an effort-tracking system. Careful evaluation of your company's
effort-tracking objectives will enable you to best create a useful effort-tracking system.
Time as a Critical Measure
Time is a critical measure for your process-improvement efforts. Organizations are actively
looking for process-improvement methods that result in increased productivity.
Most measurement efforts require effort tracking. For your organization to benefit from
measurement data, you need to know where you are spending time and make appropriate
process improvements. Your organization can improve its effectiveness by setting some
basic effort-tracking standards.
Objectives of Effort Tracking
Possible objectives for effort tracking include supporting
 Project estimating and tracking
 Productivity metrics
 Charge-back and customer billing
 A benchmark initiative
 Budgeting
7-2
Guidelines to Software Measurement
August 1994
Effort
Overview
Your objectives may identify other supporting systems that need to be implemented.
Effort-tracking measures need to be used with other measures to produce useful business
metrics.
August 1994
Guidelines to Software Measurement
7-3
Effort-Tracking Issues
Effort
Effort-Tracking Issues
Before designing an effort-tracking system, you must get corporate agreement on a number
of issues.
While it is essential that these issues be defined and used consistently across your own
organization, agreement between organizations is not always possible. Agreement with other
organizations only becomes important when external benchmarking is a goal. Having a good
understanding of the components of your effort tracking system usually makes it possible to
normalize data for benchmarking. (See the Benchmarking chapter for further information.)
The following list is not exhaustive, but it does include most of the common issues that need
to be resolved or agreed on before designing an effort-tracking system:
 Unit of time
 Overtime hours
 Work type
 Calendar-versus-accounting month
 Staff hours per month
 Project-start and -end dates
 Project activities
 Attendance reporting and billing
 Client/user/customer project time
 Consultant or contractor time
 Nonproject time
 Project team definition
 Project categories
The remaining paragraphs in this section explain each listed issue.
Unit of Time
Companies need to define the unit in which they will report staff time. We recommend that
companies report time at least by the hour.
Overtime Hours
All work time must be reported. However, you may want to differentiate between regular
and overtime (paid as well as unpaid) hours.
Work Type
Your company may need to categorize work effort by type. See Sample Work Types on page
7-10.
Calendar-versus-Accounting Month
7-4
Guidelines to Software Measurement
August 1994
Effort
Effort-Tracking Issues
Very often, companies use a physical calendar month to track projects, and a companydefined month to track other accounting functions such as payroll or customer billing. When
this is true, it will be necessary to consider all uses when designing the effort tracking
system.
Staff Hours Per Month
The hours associated with a staff month (work month) can vary greatly among companies.
Ranges of 18 to 22 work days per month are common. In addition, the number of hours
worked per day can also vary. To benchmark with other organizations, you will need to
normalize your time data. This is not difficult if each organization understands how they
define their staff month.
Project-Start and –End Dates
What is this section about.
Your company needs to consistently define how to determine project-start and -end dates.
Exact start dates vary among organizations. Generally, when a project can be uniquely
identified, effort tracking should begin.
A project-end date is typically defined as the date it is put into production. As with project
start dates, a consistent definition for end date is imperative. The project end date marks the
point when you stop charging hours against a project.
Incomplete or partial projects need to be specified in the project attributes.
Project Activities
Each company needs to define, with consistency, which activities/tasks will be included in
the project. In addition to the established project life cycle activities (requirement, analysis,
design, construction, implementation, etc.); function point counting, documentation, and post
implementation reviews may also be included. See Sample Project Activities on page 7-10.
Attendance Reporting and Billing
In addition to project time tracking, an effort-tracking system may be used to handle
attendance reporting and/or customer billing. Each of these areas will have its own issues
that need to be addressed. For consistency and staff productivity, it is beneficial to have a
one-time tracking system. However, the needs of project managers, payroll departments, and
accounting departments may vary greatly.
You may need to look at each of the following hours differently depending upon use (that is,
payroll, customer billing, project productivity, etc.):
 Billable-versus-nonbillable hours
 Paid and unpaid overtime
 Accounting months and calendar months
 Direct and indirect project time
Attendance reporting will have issues pertaining to obtaining data within specific accounting
time periods, and capturing all staff work hours whether they are billable or not. Certain
August 1994
Guidelines to Software Measurement
7-5
Effort-Tracking Issues
Effort
time categories may require management action (sign-off) before being processed. Examples
include overtime, holiday, vacation, and sick time.
Organizations that use an effort-tracking system to bill work effort to specific clients (or
charge back) have another set of issues. These might include determining how to bill by the
day, when time is reported by the hour, and how to bill for unpaid or paid overtime.
Client-Project Time
You must determine whether total project time should include time for clients or business
units that are part of a development project team. There is no correct answer. However,
each company needs to be consistent in its inclusion of client time. Some organizations have
simply chosen not to include client time, because it is difficult to obtain and hard for the
project team to control.
Consultant and Contractor Time
When consultants or contractors (not part of the company internal staff) are part of a project
team, their time should be included in the project work effort. In many instances, it may be
necessary to separate internal staff time from consultant time, such as when there are
different hourly charge rates for each.
Nonproject Time
Nonproject time is time spent on all activities that are not defined or included as part of a
project. While this will vary for organizations, some common nonproject activities include
general staff meetings, travel, and nonproject related education. Meetings, education, and
travel that directly relate to a project should be included as part of the total effort for that
project.
Project Team Definition
Companies need to consistently define the makeup of project teams. Analysts and
programmers are typically included. Questionable (and possibly prorated) are database
administrators, network analysts, computer center personnel, management, user/business
analysts, testers, and clients.
Project Categories
Each company needs to determine a standard set of project categories. This includes
defining terms such as new development, enhancement, support, maintenance, defect
correction, etc. Some common issues usually revolve around the terms enhancement,
maintenance, and support. For example, is all enhancement work categorized as such for
measurement purposes, or are minor ones considered support? Of course this means that the
terms major and minor need to be clearly defined and uniformly used.
As you can see, establishing a policy or standard for your company and maintaining
consistency within your organization are the keys to resolving these issues. The fact is that
not all companies handle these issues the same way. Try to involve as many internal work
groups as possible to resolve these issues to minimize organizational resistance and increase
staff support.
7-6
Guidelines to Software Measurement
August 1994
Effort
Suggested Implementation Approach
Suggested Implementation Approach
This section includes suggested attributes for effort-tracking systems and suggestions for
implementation.
The suggestions in this section are a consolidated list from individuals within IFPUG who
have implemented effort tracking within their respective companies. These are just
suggestions and are not meant to infer IFPUG standards or future direction.
Attributes for Effort-Tracking Systems
IFPUG members suggest that effort-tracking systems have the following attributes:
 Accessible
 User friendly
 Reflect various reporting levels
 Interface with external systems
The following paragraphs explain each of the attributes.
Accessible
Accessible means accessible by developers, support personnel, administration, outside
contractors, users, and management. This implies that all personnel that work on a project
record their time. Again, this is only a suggestion to more accurately record how much time
is really spent on a project.
User Friendly
The user-friendly attribute is accomplished by
 Help screens to display specific activities and tasks
 Prior data entry display
 Daily or weekly input option
 Online edits to increase accuracy
Reflect Reporting Levels
Effort tracking should be available at various reporting levels with capabilities to generate
summaries for or by
 Employee
 Group Leader
 Manager
 Department Manager
 Organization
 Application
 Project
Interface with Systems
The effort tracking system should be able to interface with external systems that may include
 Function point repositories and other reporting systems
 Project tracking and management
August 1994
Guidelines to Software Measurement
7-7
Suggested Implementation Approach



Effort
Employee tracking systems
Organizational databases
Billing and charge-back systems
Suggestions for Implementation
In addition to the design suggestions, the following list includes suggestions for
implementing an effort-tracking system:
 Address issues covered in this section and others as they arise. Many of the issues
associated with effort tracking are organizational issues that can and will cause
significant delays if not decided on by all the key players.
 Establish goals and objectives for effort tracking and develop a system justification.
Decide the amount of time and effort you and your management are willing to spend.
 Identify and define project types and associated activities.
 Develop an effort-tracking system with appropriate team members and buy-in from
management.
 Document and distribute effort-tracking policies and procedures.
 Evaluate whether it will be better for your organization to develop and build an efforttracking system, or whether an available commercial application will meet your needs.
 Determine what training will be needed by the staff who will be expected to use the
system or method of effort tracking.
7-8
Guidelines to Software Measurement
August 1994
Effort
Suggested Project Types and Effort-Tracking Activities
Suggested Project Types and Effort-Tracking
Activities
This section defines sample project types and effort-tracking activities by presenting
examples of each.
Sample Project Types
The activities defined in this section may be broken down into smaller activities or rolled up
to larger activities.
Consulting: Technical service not related to a specific application. This is a type of
development work that includes strategic system planning.
Defect Correction: Applied effort to perform corrective maintenance on an existing
application.
Development: Application development effort that results in the creation of a new
information system or effort to deliver a purchased software system.
Maintenance: Applied effort that does not alter the functionality of a system, but is
necessary for the proper operation of an application. Includes items such as: conversion,
user support, problem resolution, and production support.
Enhancement: Modifications made to an existing application that results in the change of
its functionality.
Administrative: Applied effort in overhead areas such as holiday, vacation, education, etc.
Sample Effort-Tracking Activities
There are many views of what should or should not be tracked. The sample activities in this
section include one view of effort activities that can be tracked. Pick the categories that
make the most sense for the amount of management control required to complete the job. Be
aware that if your organization is not collecting any information today, there will be cultural
issues that have to be addressed for this change to be successful.
Project-Related Activities
You might want to track effort usage for the following project-related activities:
Design: Includes planning, analysis, and all areas of design work (general system design,
file and program design, code design, etc.).
Construction: Development and creation of computer program code and JCL code.
Includes all types of testing (unit testing, component, and system testing).
Documentation: Creation of both technical and functional documentation. Includes
function point documentation.
Project-Specific Education and Training: Time spent in project-specific formal and
informal education and training.
Evaluation: Time spent evaluating hardware and software options.
Hardware Set-Up: Time spent in hardware configuration.
Project-Related Meetings: Time spent in formal project-related meetings with
clients/users, organizational staff, vendors, etc.
August 1994
Guidelines to Software Measurement
7-9
Suggested Project Types and Effort-Tracking Activities
Effort
Project-Related Administration: Time spent on administrative work associated with the
project, such as budget work and preparing status reports.
Nonproject Information
The management team may want to track additional information about how time is spent, but
this time needs to be segregated from project-related effort.
Administration: Time spent attending to administrative work associated with the job, such
as budget work, preparing activity reports, and performance appraisal preparation and
review.
Holidays and Vacations: Holiday or vacation time.
Sick Days: Time absent from work due to illness.
Nonproject Time: Any time not related to a specific project. Examples include department
meetings, safety meetings, and blood drives.
General Education and Training: Time spent in general (not project) formal and informal
education and training.
Personal: Time absent from work for personal reasons.
Other: Any indirect time not otherwise accounted for: use of this category should be
minimal.
Support Information
Support may wish to organize their time tracking into the following categories:
Software Installation: Time spent in software installation.
Support - Conversion: Time spent upgrading hardware or software.
Support - Problem Resolution: Time spent investigating software failures, system
problems, etc.
Support - Production: Activity related to initiating, monitoring, controlling, etc.,
production-system processing for the client/user.
Support - Training: Activity related to training users in areas such as a PC package or
implemented system.
Support - User: General user support, which would include discussions about an
application's logic or function.
7-10
Guidelines to Software Measurement
August 1994