Push Projects

A model for running projects where the software is developed externally to the sponsor company but operated and maintained internally.

Premise

Large corporations with big software development budgets like to run and control projects themselves choosing the best software developers. Running these projects in house makes them inefficient to start, staff and run for the following reasons:

Physical space: Space is often at a premium meaning that to start of project requires either waiting for space to become available or staffing the the project at a out-of-town location.

Candidate Vetting: As running the project on site means that project staff will have access to the corporate network. In highly regulated sectors such as finance allowing non-vetted access to the network would be unacceptable. Unfortunately vetting can take several weeks and cost thousands of pounds. It also means that some candidates are lost as they will take up other opportunities while a final offer is confirmed.

Desktop setup: Most corporates have a standard laptop build which is often out of date and under-powered for the needs of modern computer languages. In addition to this the software applications are often outdated or obscure.

Internet Access: We want corporates to protect our private information. One of the best ways to do this is to have a closed corporate network where it is not easily possible for data to escape to the outside world so restricted writing to USB sticks, emailing or web uploading. The problem with the latter is that this is only possible if http is being used and monitored. Using https this is not possible as the data channels are encrypted so https must be restricted. This does not play well as browser manufacturers and sites increasingly move towards https even for content that is read only.

Tooling: When it comes to build pipeline and software stack corporates tend to be conservative resulting in weeks of delay getting the latest and greatest IDE features or bug fix patches to open source software.

Training: While on site project staff will regularly be required to do all company wide training schemes (such as know your customer) which are often not relevant to people working on the project team who never need to interact with clients.

Employment regulation: In the UK employment regulation means that consultants and other temporary workers are often given a limit in how long they are able to work on a project (as opposed to working on the project while it is being actively developed) in order to avoid being considered as employees.

Candidate: The issued outlined above along with restrictions on dress code means that in some cases the most able staff are put off working inside a corporate bureaucracy.

What is a Push Project ?

A push project is one where the project software is developed by a team based outside of the corporation and and delivered, or pushed, to a software repository controlled by the corporation. The corporation then takes responsibility for the QA, installation, operation and maintenance of the software. Only confidential information specifically needed for software development is shared with the project. Let’s compare the points given in the premise:

Physical space is no longer an issue as commercial rental can be used as needed (e.g. WeWork).

As candidates will not have access to the corporate network or any sensitive client or company information minimal vetting is required.

Developers will provide their own desktop setup but will be provided with single-sign-on access to the project tooling (see Project Tooling below).

Internet Access is unrestricted as project staff have no access to sensitive client or company information.

Tooling is based on a template but there are no restrictions to project teams upgrading or switching technologies providing the push interfaces to the company (see Project Tooling) remain unchanged or change in an agreed way.

As project staff are selected based on expertise no training is required.

The fact that the staff on the project are only responsible for software development and not the ongoing running and operation of the system makes it clearer that temporary project staff are not employees.

As the project is based off site corporate dress codes do not apply project staff can turn up for work in dress they feel best working in.

How it works

Business people work with the push project leaders to define the work that needs to be done and the priority order in which it should be delivered.

The software is developed by the push project developers. When new release is made the source code repository is tagged with the version and then used to build the runtime software images (e.g. docker images, libraries or jar files) which are uploaded to the software image repository.

In house QA will then assure the quality of the software and on passing make the software images available for installation.

The in house operations team will then take the software image and install it into environments where it can be used or tested by the business. Any operational issues (e.g. database backups) will be managed by this team.

The in house maintenance team are the ones which maintain the system once the project is completed and moved into maintenance mode. They may be physically based with the push project team during the development phase. They know how to change the code and make new releases. When there is an operational issue they are called in if needed as second line support.

Risks

Project staff do not have access to confidential or client information but they do have access to project source code. On joining a confidentiality agreement is signed that makes clear their duty to safeguard this code. There is however a chance though negligence, hacking or wilful misconduct that the source code could leak outside the project. The risk associated with this is one of competitive loss as opposed to reputational loss. A leak although undesirable will often be of limited concern because:

• Large corporations run hundreds of systems a leak of any one will often be of limited advantage while the other systems remain confidential.
• Most corporations will do due diligence on the origin of software they use and will not want to touch bootleg source code.

Project Tooling

A push project typically runs with the following project tooling accessible to project members.

• A single-sign-on system that allows access to the systems below, and importantly, stops access on leaving the project.
• A secure restricted email service that allows communication between team members and people in the sponsor company.
• A source code repository that contains the source code for every release.
• A CI server to ensure the software is building cleanly.
• A software image repository that contains the compiled image for each release.