<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=60438&amp;fmt=gif">

Getting a new project is always a rush but so is scaling up an existing one. A healthy business relies on a good balance of bigger projects and smaller ones. Diversity is also key, especially in challenging economic times.

Today we’re going to be looking at the different types of scale-ups we’ve experienced so far and what are some of the best practices we’d recommend for each of them.

Types of scale-ups

There are two common scenarios where we usually consider scaling up a project.

In the first one, the client informs us of a short-term shift in their needs. Either the scope of the project changed or the deadline for delivering the final product changed. We consider this to be a simple scale-up when it requires one or two extra developers and can be done in a matter of days.

In the second scenario, we’re looking at either a different scope, a different deadline, a different/ additional product, or a general long-term collaboration. This would involve a more complex plan that looks at more than three people, a longer period of time, and what we like to call a team ramp-up.

Simple scale-up

When a client informs us of the new parameters we need to accommodate, we usually take one or two days to come up with a scale-up solution.

A best practice for this is to have regular team allocation meetings. We use them to move fast when a scale-up opportunity arises. During these meetings, we take a look at our available people, their skill sets, and their learning plans and we decide who would be the best fit to join that project. The scale-up can happen in just a few days, after presenting the solution to the client and discussing the details.

Another best practice we’ve identified is being proactive. If the project needs a bigger capacity, we come up with a scale-up proposal and discuss it with the client. For example, if they have an unexpected investor meeting and need an additional feature implemented fast, we suggest a new timeline or an additional team member. In a different project, we saw a business opportunity in a new project feature and the client was thrilled to incorporate it.

Project ramp-up

For a more complex scale-up, we need to consider additional factors. If the scale-up requires more than three additional team roles we’ll start working on a plan that takes into account:

  • project scope
  • delivery milestones
  • team composition
  • recruitment needs
  • seniority level (a mix between seniors and juniors)
  • team leader capacity
  • team onboarding

Project scope

The project manager for that project does an analysis of the new scope to determine its complexity.

Delivery milestones

If the deadline remains, the plan will look at an accelerated ramp-up time and, most likely, a bigger team. Whatever the new milestones are, they are also dependent on the team composition and onboarding process.

Team composition

If we already have the right people for the job available, the process moves fast. That’s almost never the case. For each role in the team, we look at the required skillset and the earliest date when we can assign someone to that project.

Recruitment needs

If we lack the internal capacity for the new team composition we start a recruitment process.

Seniority level

A best practice for our teams is to have a balance between seniors and juniors. Having mostly seniors would give the project more velocity but can sometimes make the interactions between the team members more difficult, while an all junior team lacks the experience necessary and will deliver more slowly, albeit more enthusiastically.

Team leader capacity

Having to hold the entire fort together, the team leader needs to have enough capacity to ensure the technical proficiency of the team as well as the proper team dynamics. A best practice is to nominate and groom a second-in-command team leader for every project team. That person will have the knowledge and capacity to receive delegated team leader responsibilities when the team expands.

If the client has their own team working on the project as well, the ramp-up plan will also take into account the cross-team scale-up, with roles being divided between the two teams depending on all the factors listed above.

A good case practice we recommend using is to ensure a good team onboarding process. For example, in one of our projects, we started working on the ramp-up plan and team onboarding at the same time. The new team members were already familiar with the project and the technologies so that when they officially started, they became productive much faster.

When it comes to managing client expectations, we also come up with more than one scenario. For some projects, we prepared a number of scenarios, each looking at different team compositions and delivery timelines to make sure they picked the one that suited them best.

 

What other best practices have you identified when scaling up a project?

 

 
YOU MIGHT ALSO BE INTERESTED IN

Kicking off new projects

The ABC of starting a new software project, complete with best practices, how-tos, and other resources.

Read more

Andrei Stănescu, COO

Articles similar to this one