The 60 hour work week

Here's an interesting article about the effects of working more than 40 hours per week:

http://archives.igda.org/articles/erobinson_crunch.php

Basically, it states that the output you get from an employee who works 60 hours a week is roughly the same as one who works 40 hours a week.

So by pushing employees to work longer hours, a company is not only likely driving away its best employees, but it's also not getting any more work out of the employees who stay.  I have to think this is more pronounced for I.T. workers.  Since most of the good I.T. workers I've encountered get energy for their job by working on fun projects on the side, they would likely approach burnout quickly as a result of working too much.  What makes matters worse, burned out workers produce less, which in turn increases the pressure put on them, which increases the feeling of burnout, which in turn lowers productivity....  You get the idea.  I can't see any advantages to pushing employees this hard, so it's a wonder so many firms out there do it.

Using outsourcing effectively

There are plenty of stories available online about outsourcing projects that failed to live up to expectations.  Yet I see very few explanations as to why such failures occur, and more importantly, how to prevent a similar failure from happening again.  While I'll be the first to admit I don't have much experience with outsourced projects on the scale that usually make these types of headlines, I'd like to offer some advice on how to outsource effectively, from the perspective of a consultant who carries out outsourced work.

Before I get too far into that, though, I'd like to discuss the difference between outsourcing and off-shoring.  Outsourcing is the process of moving one or more business functions to an outside company, likely a specialist in that particular function.  Off-shoring is the process of moving a particular business function to another location outside of your current company, typically to a country with less expensive labor.  You can have one without the other, or do both at the same time.  I will stick to outsourcing for now and leave off-shoring for another time.

If you’re outsourcing the development of a computer application, you will help both yourself and your vendor if you start by getting as good an idea as possible of what you want out of your application.  Most vendors should expect that you will change your mind about some of the application's functionality during the course of making the software; unfortunately such "scope creep" is an expected part of building software.  However, requirements that are too vague will make it extremely difficult for your vendor to build what you want.  If you know you will have trouble making requirements, hire someone who will help you discover and articulate them.

It is also important to determine where your priorities lie.  Everyone wants their application done quickly, at a low cost, and with high quality.  To make matters even more unclear, "quality" can take on different meanings to different people.  Application speed, ease of use, application up-time, number of bugs, scalability (i.e. the ability for the application to grow with few growing pains), ease to add features, secureness of the application, etc., can all contribute to the perception of "quality".  Unfortunately, many of these are conflicting goals.  Making an application execute very quickly takes longer to develop and is more expensive to build, just like adding a large number features can make your application harder to maintain.  You and your vendor should be on the same page as to where compromises must be made.  Be sure to communicate these goals and make sure your vendor follows them.  Communication up front along these lines can save a lot of headaches and discussion when the bill arrives.

One thing that will help you and your vendor manage your project is to break your large projects into smaller, yet still useful, chunks.  More often than not, once a client starts working with their application, they discover that some of the ideas generated don't work as well in the application as they do in the planning stages.  If you try to develop too much at once, problems are identified late, and the later a problem is found, the more expensive it is to fix.  If you start small, you will see the results of your work sooner, allowing you and your vendor to adapt to each other's styles.  This will allow each of you to communicate more effectively.

You may want to consider billing your projects on a time and materials basis only.  Fixed bid projects are tougher for both parties.  The outsourcing company very often tries to put in as many features as possible in an effort to get the most for their money.  This can cause the company to lose focus on their core needs from the software.  The vendor must protect its interests, and therefore cannot be very open or cooperative to change requests.  If a project is billed on time and materials, a company can focus on which features/changes are most important to them, and the outsourcer can focus on how to most efficiently fill these requests.  In other words, the discussion turns from extracting the most value possible from the other company in a fixed-bid situation to a more cooperative effort to build the best software possible in a time and materials situation.

Also, be sure to stay active in your project.  You may be tempted to give your vendor all the information you think he or she needs and then let him or her finish the project, but that's usually a recipe for failure.  Review any documentation, samples, code, beta versions, etc., as thoroughly as possible.  Your vendor should have tried to understand your needs, but something inevitably gets lost in translation.  Be sure to voice any concerns early before they become problems.  The sooner you find errors or omissions, the cheaper and easier it is to fix them.

Most of these suggestions come down to improving communication.  Understanding your project and understanding your priorities help you give clearer directions to your vendor as to what you want from your project.  Breaking down your project into smaller, but still useful, chunks helps you and your vendor communicate requirements in a meaningful way.  Billing your project on a time and materials basis help you and your vendor communicate about what the project needs, rather than about unnecessary information.  Keeping communication clear, open, and frequent will help increase the odds of success in any of your outsourced projects.

Competing Through I.T.

One of the hot topics in business today is the tense relationship between business and I.T.  Of the many articles that I've read, very few try to thoroughly describe how the severity of the problem can differ from company to company, or how the solutions can vary because of those differences.  Nearly 25 years ago, Steven Wheelwright and Robert Hayes published an article in the Harvard Business Review called "Competing Through Manufacturing," which described the different levels in which a manufacturing arm of an organization could be integrated into the organization as a whole, as well as the benefits and consequences of each integration level.  Their terminology could easily be extended to the integration of an I.T. department.   Here are their original four "stages," only slightly adapted for I.T.:

Stage 1: Minimize Information Technology's Negative Potential

An Information Technology department whose role is in Stage 1 would be characterized by a lack of trust between I.T. and the rest of the business.  In Stage 1, a business feels the need to control as many aspects of I.T. as possible to avoid possible negative consequences of mistakes or misunderstandings.  A large portion of the strategic management and implementation regarding technology is left to consultants.  Internal research is discouraged because it leads to uncertainty, which in turn could lead to problems down the road.  The feeling is that anyone could manage I.T., which leads to inappropriate people chosen for leadership positions within the department.  For companies whose major focus is I.T., internal applications aren't given nearly the attention that the customer-facing ones receive.

Stage 2: Achieve Parity with Competitors

An Information Technology department whose role is in Stage 2 would be characterized by the desire to expand I.T. only to keep up with competitors.  Industry best practices are followed regarding programming languages, hardware, purchased software, etc.  Investments in the department usually come in the form of investing in hardware and software, rather than investing in the people or in the process.  Unlike Stage 1 organizations, Stage 2 organizations often look internally for leadership in IT, though leadership still sometimes comes from outside the department.  Improvements are often only made when shortcomings become obvious.

Stage 3: Provide Credible Support to the Business Strategy

Stage 3 Information Technology departments would be expected to actively support and strengthen the company's competitive position.  Stage 3 I.T. departments would make sure that all of their decisions are consistent with the organization's overall strategy and that these decisions are communicated effectively to all I.T. personnel.  These departments would be aware of long-term trends in the marketplace and would be actively considering ways to use these trends to their advantage.  Stage 3 I.T. companies often stay in Stage 3 for short periods of time to implement one or two large changes then revert back to Stage 2.  As opposed to Stage 2 companies, however, Stage 3 companies will often pursue improvements for the sake of improvement, rather than based on some external force. 

Stage 4: Pursue an I.T.-Base Competitive Advantage

A company reaches Stage 4 when the competitive strategy of that company is reliant on I.T.'s ability to implement the strategy.  In other words, I.T. is just as (but not more) important as other departments, and successful projects are largely a collaboration among departments.  What sets Stage 4 I.T. departments apart from other stages is the expectation by other departments that I.T. can contribute ideas and strategies central to the business as a whole.  Wheelwright and Hayes mention briefly that some Stage 4 firms take this idea too far – a firm that promotes one department at the expense of others is doing harm, regardless of which department is being favored.

If I could be able to state with certainty how a company could bring its I.T. department from Stage 1 to Stage 4, I would probably be making seven figures as a business consultant.  Clearly, I can't do that (yet).  But by identifying some terminology, I should be able to communicate some ideas much more easily in future posts.  For example, in a previous post I wrote about improving the job interview process.  However, I hope it's clear that a Stage 1 organization would have different needs than one in Stage 4.  A Stage 1 organization may have driven away its qualified workers, leaving only workers unable to find jobs elsewhere. Its hiring efforts would not only need to focus on finding good programmers, but also on finding programmers who would be willing to endure, and help turn around, a Stage 1 environment.  Since a Stage 4 company's I.T. department is involved in the overall strategy of a business, its management would need to focus its hiring efforts on finding personnel who can understand the business as well as the technology.  

Determining if a project is worth the money

In a hypothetical scenario, let's say I have the opportunity to take or reject a project, that will cost my company $200,000 this year, and is predicted to get my company the following yearly profits:

This year (2010): $0
2011: $20,000
2012: $50,000
2013: $100,000
2014: $80,000
2015: $30,000
2016: $0

Should I take the project?  On the surface, the project seems to bring in $80,000 profit for the company.  But I should take into account the fact that most of the profits come in years 2013 and 2014.  To see why, imagine that the bank on the corner is offering an incentive to start an account.  Just bring in $1000 and you get $100 cash on the spot.  Would you take that deal?  Now imagine that bringing in $1000 now will get you $100 a year from now.  That doesn't look so good.  Would you take the deal if you had to wait 20 years for the $100?  Probably not.  So how should I go about determining whether the delay is worth it?

It's easiest if I start by figuring out what rate of return I would like from this investment.  (You'll see why in a moment.)  If I work for a publicly traded company, I could use the Weighted Average Cost of Capital (WACC) as a starting point.  The WACC basically tries to answer the question: if my company wanted to raise money for a project today, what interest rate would I expect to pay?  I won't go into the details about how to calculate it, but it tries to predict what people would pay for new stocks and bonds issued by the company.  (While I recommend having someone calculate the value for your company if you were to use it for something important, http://www.wikiwealth.com/ seems to have numbers that are close.)

Now, I said that the WACC should be a starting point.  The reason is that it doesn't take into account any specifics of the project.  If this particular project involves a lot of risk (maybe the sales estimates are uncertain or the estimates are based on the economy continuing to grow) then I might want to adjust the rate higher.  (Riskier projects, stocks, bonds, and most other investments require a greater return if more risk is involved.)   Finally, keep in mind that since the WACC is the rate a company would pay investors for capital, it is essentially the break-even point.  Accepting a project that has returns that match the WACC would be like taking a bank loan at 6% to buy an investment that returns 6%.  In the end that investment has no net gain.

I think that my project isn't particularly risky so I'll just use my company's WACC.  For this example, I'll use both the WACC for Microsoft (9%) and CitiGroup (14%), as determined by www.wikiwealth.com.  I could then find the present value of my profits using Excel.  The present value is essentially a way of telling us the value of a series of cash flows for a given interest rate.  For example, if I wanted to determine how much the project is worth for Microsoft, I would enter:

=NPV(0.09, 20000, 50000, 100000, 80000, 30000)

Where the first term is the interest rate, and all the subsequent terms are the expected profits from each future year.  When I enter this, Excel returns a present value of $213,822.93.  Since this is more than the $200,000 investment for the project, I should accept the project.  What about CitiGroup?  Here is my present value calculation in Excel:

=NPV(0.14, 20000, 50000, 100000, 80000, 30000)

Which returns $186,461.87.  It looks like I would not take the project if I worked for CitiGroup.

I hope that gives you a little bit of insight into some of the finances behind decision making.  As you can see, the process is somewhat subjective (such as determining the interest rate and estimating the profits), but it does give you a relatively easy way of comparing the value of two different projects.