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.

Predictions for 2021

It's January, the start of anew year. Let's have some predictions!

We can start with easy predictions:

Remote work: Telework and online meetings will continue to be popular. Covid-19 is still with us; work-from-home will remain a necessity for many people.

There will be some push-back against remote work; some from managers and some from employees. In my view, discomfort with remote work is a symptom that the right performance measurements are not in place.

If easy, simple, and clear performance measurements are available, then it is easy to see that an employee is performing -- or not performing -- whether they work in the office, at home, or at a different location. But in our imperfect world, there are many jobs that do not have easy, simple, and clear performance measurements.

Companies have an opportunity to review performance measurements and improve them to match telework, Will they? A minority, I think, will.

ARM processors: The new processors from Apple will be hailed as a significant advance in performance, and Microsoft will be pressured to increase support for ARM processors. Most of the interest in ARM processors is driven by raw performance.

Improving the performance of desktop computers may be a mistake -- except for Apple. Computing -- except for Apple -- long ago moved from the desktop to web servers, and is not moving to cloud servers. The desktop is not the center of computing; it is more akin to a terminal in a timeshare system. Improving the desktop performance does not help the central processor.

Apple is an exception. It continues to use the model of desktop applications, where processing occurs on the local PC (or the tablet, or the watch). For Apple, improving the processing capabilities of the local PC makes sense.

Programming languages: The general trends of language popularity will continue; that is, most languages will decline in popularity. Expect declines in especially Perl and Java. Perl because Python is gaining at the former's expense, and Java because Oracle is doing little to help the development communities. (Both commercial and open source communities.)

I expect little in the way of improvements to Objective-C compilers and libraries. Apple will encourage people to move to Swift, and not developing Objective-C is one part of that strategy.

I expect to see a large number of new programming languages, made by individuals and research groups, and perhaps even companies, but none of them will become popular. We have our hands full with the current set of languages; new languages will be curiosities. An exception might be a programming language that is designed for cloud computing. Such a language would be designed for smaller programs, most likely not object-oriented, easy to learn, and capable of receiving and sending web requests.

Corporate migrations: We've already seen companies leave California for Texas. Will other companies follow? I tend to think that these migrations were made possible by the work-from-home forced upon us by Covid-19. Regardless, companies have decided that they can leave Silicon Valley.

Companies may leave the condensed area of Silicon Valley to form a new condensed area somewhere else -- or they may disperse across the country. (And some may even leave the United States.) The result will be a shift in employment, as some companies will ask employees to follow to new headquarters and others will let employees work from any location. Some companies may move only the executives, others may ask the entire roster of employees to move, and some may move select departments and keep others in their current locations.

I expect that there will be no new "Silicon Valley", no one place that attracts tech companies (much less all of the companies). Individual companies will move to locations that make sense for each company. That could be Austin, TX; Miami, FL; Phoenix, AZ; or any of a number of smaller cities.

Legislation will have major effects: An obvious area of legislation will be the DMCA (for copyright issues) and CDA section 230 (which shields platforms from liability of content posted by users). Other issues will be digital taxes (or more precisely, taxes on the providers of digital services), anti-trust, and privacy concerns. Any of those could become a hot issue in 2021.

Politics will remain significant: Already we have seen Twitter, Facebook, and Amazon take action against users who violate their terms of service. These actions have seen reactions and pushback from other users, loyal to the original offenders. The social and political environment will make it difficult for companies to remain neutral. Companies which move their offices will be judged on the move, both in the origin (where they move from) and the destination (where they move to).

Summary: Changes for 2021 will be driven more by non-tech issues than tech issues. New versions of Java or C# programming languages will have little effect on the market. New cloud services and new versions of operating systems will have little effect. Politics, legislation, and possibly high-profile lawsuits will drive the changes.