Onboarding process

The onboarding stage is where we gather your requirements and introduce you to how we do things at 1902 Software. Typically, it consists of one or two meetings with your project manager/s and a non-technical interview to prepare for the project.

Let's talk about your project

The onboarding stage

The onboarding stage is all about us getting a full understanding of your requirements for the project, and you getting introduced to our processes and how we generally do things. In effect, it’s also at this stage that we determine if our companies are a good match.

IT development projects are not always smooth sailing, but by defining expectations and being transparent right from the early stages of our collaboration, we are in a better position to avoid problems and unwanted surprises down the road.

The following describes our typical onboarding flow for new projects. Since our customers vary greatly in company size, industry, and especially, project requirements, our actual onboarding processes may also differ from one case to another.

We typically begin by having short meetings between you and Peter after you directly contact us or get referred to us by existing customers. This is where we get an initial idea of what your project will be about and check whether we are a good fit for what you’re looking to achieve. We say “no” to potential projects when:
  • It requires a technology that we don’t work with;
  • Our time zones don’t overlap (we only work with companies with at least four overlapping hours with our time zone, GMT+8, to ensure that we have enough time to hold meetings);
  • Our current workload does not allow for it; or
  • We believe that we’re simply not a good match.
Otherwise, when we’ve determined that your requirements are within our specialization and that we have resources who can take in your project, we turn you over to your project manager for requirements gathering and estimation.

Depending on the nature of your project, you may work with one or two project managers—a Design Project Manager and a Technical Project Manager. Unless it’s a design-only project, it’s typically the Technical Project Manager who is overall in-charge of the project.

You will have a meeting or series of meetings with your project manager/s for requirements gathering. This is when we drill down to the specifics of the project, discussing the look and feel (UI/UX), features, functionalities, integrations, etc.

We provide suggestions on what plugins or modules you can use so you can save on development time, themes that you can purchase instead of getting a full design done from scratch, and other things that can improve your project based on our knowledge of best practices and more than 20 years of experience with IT projects.

If the project is a support/maintenance project where we work on an existing website, webshop, or custom software application, we may also do a review where we look at how the system was initially put together. We look at different things like the plugins used, types of integrations, if there is anything changed in the core of the CMS/system, etc. This is for us to catch any errors and warn you of them before we officially start on the project, in case you want your previous supplier to fix these errors.

Next, we prepare a price estimate where you can see the tasks needed for the project and the estimated cost associated with each task. For larger projects, we may also create a Project Plan document that contains the details and specifications we’ve discussed over these meetings.

We also do an onboarding interview, which covers the non-technical details of the project. It’s an important step for us to understand you as a customer beyond the technical specifications of your project. This interview is typically done around the same time that you’re introduced to your project manager/s.

We usually cover four main topics:

  1. Experience – Have you worked with other IT suppliers in the past? What has your experience been like with IT projects? Have you ever tried outsourcing/offshoring before, and if so, what worked and what didn’t?
  2. Expectations – Do you foresee any challenges that may prevent the project from being successful? Is there anything that worries you about our collaboration (e.g., the location and time zone difference)?
  3. The project –What are your goals for the project and how will you measure its success? Are there important dates or time constraints that we have to be aware of?
  4. The company – What can you share about your company that can give us a better perspective on the project (e.g., your history and other details that may not be apparent when we look at your website/webshop)? What is your role in the company?

These are only a sample of the questions that you can expect from us, but note that this is not a one-sided interview. You can also ask your own questions about our company, services, and processes so that you too can get an idea on how your collaboration with 1902 Software will be.

After the interview, we prepare a report from our conversation and send it to your project manager/s.

Your project manager will prepare a detailed project estimate which will be accessible through our online project management system. This contains:

  1. The basis for the estimate – this explains how we created the estimates, including the specifications or requirements you provided for the project.
  2. Estimate breakdown – this is a detailed list of tasks included in the project and the time and cost associated with each.
  3. Working with 1902 Software – this explains how we do things at 1902 Software and the standard features we implement by default in every project we work on, so that you know what you can expect throughout our collaboration

We use an online system where we keep all details about the project, enabling customers, developers, designers, testers, and other people involved to get a comprehensive overview of the project.

Upon the official start of your project, your project manager will give you a walkthrough of our system and introduce you to its features.

It’s not uncommon for clients to request a lot of changes while the development is in full-swing. Sometimes it’s a simple change of heart, but often it’s because when clients see a preview of the system (a mockup or a staging version), they also start to better visualize it and think up different things that they want to add or change. We highly discourage too many change requests because:
  1. It can add a lot to the final project cost. Change requests are billed separately, considering that they are not included in the initial price estimate before the project started.
  2. It can cause delays to the project. When you’re constantly changing requirements, it’s difficult to keep up with the original timeline and project pace because it takes time to develop the changes.
  3. It can degrade the quality. The components of a software are highly interdependent with each other—changing just one can lead to problems elsewhere.
Of course, there are cases where changes may be necessary to the project due to previously unknown factors that have come up or maybe a shift in your business goals. Generally, though, we tell our clients to stick with an MVP—a minimum viable product—that they can go live with. Changes can then come after the MVP is deployed. Not only will this help avoid the problems mentioned above, but also gives them enough time to evaluate whether they would really like to proceed with the change request or not.
Once the onboarding process is complete, it’s time for us to start on your project. Read all about our development process here.

Get a call from Peter within 24 hours and have a conversation about your requirements.