Best Buy and financial services firm The Motley Fool have learned that giving staffers free rein over their schedules helps improve their productivity. This notion is at the center of a management philosophy known as Results-Only Work Environment, in which workers are evaluated on the basis of their output instead of how many hours they clock at the office. Just 3 percent of U.S. companies have formally adopted ROWE …. Bloomberg Businessweek, July 29, 2012.

Does Apple sell their world class iPad by pricing it at the cost to manufacture the iPad? Nope. They wouldn’t make any money on it that way. They need to sell it for the cost to manufacture plus the cost to develop it plus a profit margin (for all those things one does with profits).

Many people miss this part of developing a product or service. The drug companies get a lot of grief for selling a pill that costs them pennies to manufacture where they then charge dollars for us to purchase them. The additional cost of research and development is simply not visible to most people and hence charges look to be outrageously high.

Well, we as project managers have a tendency to sell our products and services at below cost. Let me illustrate with an example.

My boss wanted to know how much memory the software was taking up in the product we were developing. Needing more physical memory to run the product would mean an increase in manufacturing cost and so he wanted to know how close we were coming to our limit.

While the data existed to know this information, it was not easily attained. I had to dig through various technical outputs from product builds to get this information. In addition, some of the memory was static (was always used) and some was dynamic (used when needed) and so I also had to dig through all the test results to find the use cases that used the most amount of memory. Also, the product could be configured differently, based upon the customer requirements, and so I also had to dig through the other various testing outputs from our customer testing to ensure we really knew which customer was needing the most memory.

Once I had dug up all the information and thought I had a good answer, I didn’t give it to my boss. This effort took about a half day to complete. This included all the interruptions and other things that come up when working on any effort and was a bit error prone to do as it was easy to miss the test case or the customer configuration that had the peak memory need.

Instead, I labored through midnight that night and most of the next day (again, dealing with all the normal interrupts and efforts that I still needed to do during my normal day) working on how to automate the answer to this question. I had to pull in all the build logs, all the test reports, all the customer configurations and parse out the data I needed from reports and logs that were not designed to be used as data input. In fact, these standard output logs weren’t even seemingly designed to be read by humans. I was just lucky, it seemed, that they dumped out in fairly incomprehensible form the data I needed.

I gave my boss the results of my analysis the next day. I confirmed what I had gotten manually, and actually had to update it based upon the data my automated script had dug up.

What do you think happened? Yes, the following week he asked me for an update to the same information, including a few changes to the data (e.g., a different breakout of detail that I had not captured previously).

If I had not taken the time to automate my process, doing this change and update would probably have taken me another day. Instead, it only took a few tweaks to my script and I had the update in a few minutes. Did I then give it to my boss? No, I hung onto it and gave it to him the next day.

Why did I wait? For the same reason Apple charges more for their product than just the manufacturing costs. I felt I had purchased the additional time by working through the night and day the previous days. My boss didn’t know about my efforts (why tell him) and he had an expectation (that I encouraged a bit) that it would take some time to make the update. He also had the expectation that each time we needed to see the memory status that I would need a day to pull together the memory numbers. During this time he generally avoided giving me more tasks.

This kind of approach, of making oneself or team much more efficient and productive but not necessarily passing this productivity onto the rest of the organization, is one of those “am I doing the right thing here?” conundrums. I can attest to the fact that when I originally started to do this kind of investment (e.g., work around the clock on an automation effort) and then shared the results immediately, I didn’t get the kind of feedback I expected (e.g., “wow, great work, amazing, here’s a bonus, no here is a promotion ….”). Instead, I just set an expectation that doing hard work was very easy. “OK Bruce, make these several dozen complex changes that I think are easy and get it to me within the hour ….” You can imagine how that worked out.

As we implement improvements, always keep in mind that we want to earn back our full costs. When we undervalue our efforts by not “charging” the whole price plus a profit, then we set an expectation for products and services that, over time, may not pay for themselves. We know what happens when we can’t make a profit on our work. We eventually will be out of that work.

Are your project or individual improvements earning back for you or your team the time and effort you put into them?