|
 |
Home > Detail: Free Time is Not Free
| A StickyMinds.com Original |
|  | |
Free Time is Not Free
By Edward Weller
   
Summary: Unpaid overtime has negative personal and business consequences. Although regarded as free time by many organizations, there is a true business cost to not estimating or counting overtime hours, whether paid or not. In this week's column, Ed Weller presents the argument that those who do not count free time in their planning and tracking will make poor decisions and often invest in the wrong projects. | | |
|
|
 |
An insidious force in software development continues to make reasoned trade offs between projects difficult, if not impossible. Whether you call it free time, casual overtime, unpaid overtime, or "blood from a turnip," organizations that do not measure this gift from their development teams cannot make accurate decisions when faced with "Do we do Project One or Project Two?" because they cannot estimate the true cost of either project.
The term free time was the inspiration for this article as it is perhaps the worst name for overtime I have run across in my career. Paid or not, overtime has many negative consequences on personal as well as business levels. I will discuss both, but will emphasize the negative business consequences in the hope that those who focus on the bottom line to the exclusion of all else will see that ignoring free time does not make good business sense.
The Personal Side
My first job out of college was working on the Apollo Program at Kennedy Space Center. The goal to land on the moon by the end of the decade was a challenging goal that created strong motivation to work long hours. Sixty to eighty hour workweeks for extended periods (years) was not unusual. Although most of the overtime was paid, Brevard County, Florida, had the highest divorce rate in the country in the late 1960s. One has to wonder if the steady seven day work-weeks had anything to do with this.
In a later job, I regularly visited a team working on a critical project, typically after lunch. As they fell behind schedule, management decreed they would work overtime to catch up. For the first three to four weeks, I observed a concentrated effort on the part of the team. As time went on, I noted their lunch breaks became longer, and their focus was poor in the afternoon hours, with extended discussions of non-business topics. Overall efficiency was down and in spite of the extra hours; did they really accomplish that much more?
On another occasion, an ex-boss and friend lamented that his project management had decreed the team work Saturdays "until the project was back on track." I asked my friend how far behind schedule they were. Thirteen weeks was the answer.
I asked, "When do you have to deliver?"
His answer, "Six months."
Some simple arithmetic which he had already done and every person on the project was capable of doing, figures 13*5 = 65 days, or more than a year, to make up the schedule deficit, assuming further slips did not occur. The logic of this decree to work Saturdays in situations like this erodes what respect and confidence the team has in those who make the decrees.
Add to this the increased rate of mistakes made by tired people, the loss of creativity, the added stress on physical well being, and the forced tradeoffs in personal and family activities. This would seem to be enough to mitigate the use of overtime--whether paid or not. Sadly, this isn’t the case. I know of one company where project managers were measured in part by how many hours of free time they squeezed out of their people. Since people issues seem to be ignored, let’s look at business reasons why free time isn’t free.
The Business Case against Free Time
Let's take two projects in the proposal stage and show what happens if free time is not accurately estimated. Note accurate estimation typically requires recorded data from previous projects, or--worst case--an organization's memory of a past project history that allows the next project to estimate based on reliable anecdotal experience. We will evaluate the project’s Return on Investment (ROI) and show that unless the hidden cost of free time is considered, organizations will usually invest in the wrong project.
Hidden Effort and the Same Return – Example 1
On Project One, the project manager disregards any accounting of free time even though in the past his projects have burned out the team members with a steady diet of sixty plus hour weeks. He estimates 100 units of labor are needed, and overlooks the previous fifty percent error in estimating, since he assumes his team will "suck it up" and work any needed overtime to get the job done. After all, if he included that effort, the project might not be funded.
On Project Two, the project manager takes into account historical data which shows previous similar projects really took fifty percent more effort than initial estimates, so she estimates 150 units of labor.
Project One has an estimated return of 150, and Project Two a return of 200 (this example assumes labor cost is the predominant project cost, which is true in software development–a key point discussed later). However, with the lower estimate for Project One, Project One’s ROI is 150 versus 133 for Project Two. The company decides to invest in Project One.
However, if we follow this example and assume that both projects take 150 units of labor to finish, the ROIs are reversed. As the green bar in Figure 1 shows, Project One returns 150 units for an ROI of one. If Project Two had been chosen, and came in on a budget of 150 units, the ROI would have been 133 as planned. The company just lost thirty three units of return. In this case the higher cost estimate returned more.
Figure 1 – Example 1
This example makes a number of simplifying assumptions, but I believe it usefully demonstrates how ignoring the estimation of free time will lead to making bad decisions. Whether or not the overtime is compensated, it is a resource that represents the most valuable commodity in a software development organization–the intellectual capital of the development teams. When it is spent, it should return the maximum. In the example, both projects used the same number of units and one had a thirty three percent greater return. You can adjust the numbers to show any number of cases where ignoring the effort will result in the wrong decision.
Lower Return Project Selected – Example 2
Take two projects where the paid effort is the same, and both assume a fifty percent free time budget, but the first project ignores the free time "because it is free." It automatically gains a large advantage in the decision to select one of the two competing projects (see the "Estimated ROI" bar in Figure 2). In the case where both projects return the same value, there isn’t a problem. However when the accurately estimated Project Two has a higher value, the correct decision is hidden by the inaccurate effort estimate of Project One. As shown in Figure 2, the actual return is the opposite of the estimated return.
Figure 2 – Example 2
Why Isn’t The Hidden Cost Counted?
Software projects are typically dominated by the cost of effort. Systems and hardware projects are more equally weighted to equipment, material, and manufacturing costs, so the ROI calculations do not show the same story. I suspect many of the mental models used to make project tradeoff decisions have not made the transition from physical costs to intellectual (person hours) cost.
Summary
The idea that free overtime is free is wrong. A company that chooses to ignore an employee’s personal time and is willing to burn out its development teams may be following an acceptable business strategy if the bottom line accurately reflects turnover, recruiting, and training of replacement people. However, when free time is not included in project estimating, the wrong projects will be chosen and the company’s return will be impacted.
About the Author
Ed Weller is associated with Software Technology Transition, providing software process improvement consulting services. In a thirty-plus-year career spanning hardware, software, test, systems, and process engineering, he has developed a process-oriented view to product development that is closely tied to the organization's business needs. He has more than thirty publications to his credit, including the 1993 IEEE Software's Best Article of the Year award for "Lessons from Three Years of Inspection Data," and has presented over twenty tutorials and talks at conferences and seminars. He is widely recognized for his knowledge in software engineering, including inspections, metrics, project management, software maintenance, test management, and applications of statistical process control to software development processes. A regular columnist on StickyMinds.com, he can be contacted at EDWARDFWELLERIII@msn.com.
Back to Top
|
|
| |
|
|
|
