Side projects for corporations

We're familiar with the notion of a "side project" -- a project that is not related to our day job, but one that we work on anyway. One can have a number of reasons for the side project, including learning a new technology, building a solution for the household, or just plain fun. (There's also the notion of a "side gig", which is a second job and might also be called "moonlighting", but that's a different idea.)

People have side projects. Do corporations? I think that they do.

Corporations, depending on the industry, can have lots of projects, a few projects, or almost none. IT consulting firms run on projects -- its what they do for their customers. Doctor offices tend to have very few IT projects. Regardless of industry, a company will probably use technology of some kind and will have some projects, at least from time to time.

For a corporation, a side project is one that does not directly affect the services to customers. For an IT consulting company, a side project may be an upgrade to the time-recording or invoicing system. For a doctor office, it might be an upgrade to desktop PCs or a replacement for the appointment system. (Appointments for doctor offices are quite important, and tracking them and the people who are involved is an important task.)

How does a company handle side projects? How do they fund the project? How do they staff it? How do they measure performance?

It seems to me that there are two approaches to a side project. One is to treat it like any other project. For an IT consulting company, that means defining the objectives, specifying requirements, allocating a budget, assigning people, and executing the project.

The other approach is to ignore the project as much as possible. Define objectives, and assign a manager to complete the project, but allocate a minimal budget and don't assign people. Let the manager scrimp equipment and people from other projects. In other words, treat the project as a necessary evil.

The latter approach is used all too often, most likely because it reduces costs. Or appears to reduce costs. When the project manager "borrows" people from other projects, those work hours are quite often charged back to the original projects. The project itself is completed as quickly as possible, often resulting in a solution that is poorly designed and poorly implemented. Normal project management procedures (such as testing) can be truncated or eliminated. For an application that will be used internally, that poor design and poor implementation will be inflicted upon people within the company, perhaps a large number of people.

The worst aspect of treating a project as a necessary evil, with short budgets and shortcuts in processes, is that it sends the message that such projects are allowed (and possibly encouraged). It sends the message that it is okay to cut corners and deliver a project with low quality. The risk is that the shortcuts will be applied to not only internal projects (side projects) but also the "real" projects, resulting in poor quality for customers. (Performance will vary, of course, from manager to manager.)

The former approach is, in my mind, a healthier one. It recognizes the costs of a project and justifies them. It provides an honest analysis of benefits for the investment.

A side project can be an opportunity for employees to gain experience in new technology or new roles in the organization (such as project manager). As an internal project, the risk of failure is lower than the risk of a failure on a project for a customer.

Also, side projects can be showpieces to prospective customers. One usually cannot show details of a project for one customer to another customer, but the case with internal projects is different. For an internal project, the documents and results can be clearly shared with others.

A portfolio of successful projects, with objectives, initial estimates, budgets, schedules, earned-work metrics, test plans, test results, and implementations can be a powerful sales tool.

There is, of course, the possibility that an internal project will not be successful. It may overrun the schedule or the budget (or both). It may deliver the wrong solution. It may run into unforeseen technical difficulties such that it cannot be completed. Such a project is a learning experience, but perhaps not a project to put in a portfolio. (Unless it occurred early in the company history, and you have a lot of successful projects after the failed project. That could show improvement in your management.)

For companies that are not in the IT consulting industry, a portfolio of projects is not necessary. Those companies deliver products or services different from IT. Yet side projects are still opportunities for employees to develop new skills and work with different parts of the company.

We can consider side projects necessary evils or opportunities. I think the latter offers more benefits.