Software development Strategy Guide for Scaleups

Becoming a scale-up is not an easy task. According to a study conducted by Deloitte, only 1 out of 200 new enterprises reach maturity. But why is this failure rate so high amongst start-ups? In most cases a lack of holistic approach to the process of scaling up is the cause. Yet, change has to affect the whole organization with a greater focus on software development which is a driving force during the scaleup process. Below you will find some hints on how to change your project development strategy and complete the transition phase successfully.

How to define project definition?

Scaling-up your business requires a change of approach toward project definition. In the context of software, we refer to it as all the aspects that need to be covered during the process of planning and execution.  A good project definition should answers the following questions:   

Why?

All projects should start by providing its business justification, a prerequisite to initiate any project. We can see this phase in almost every project management approach, including PRINCE2, DSDM (Dynamic Systems Development Method) or even AgileSHIFT. The latter one, which  is relatively new to the market, distingues a phase called “Start up” which asks if the project is worth doing. 

What?

Everything that needs to be done during the project. The scope of work has to be established before the project starts. As change is a part of every software-based project one has to take it into consideration when defining technical and system infrastructure, and the rules and procedures which will be used to operate the software. There is also a need to provide your team with training on maintenance or new organisational procedures introduced after scaling. 

Who?

There is a need for a simplified structure within the team, with a clear set of responsibilities assigned to every person. 

When?

A project definition has to include both a general and a detailed (with every task required) timeframe allowing the team and all stakeholders to track the progress. 

How to define project scope?

Even if you have vast resources, without a well-defined project scope there is a little chance of success. So what is a scope and how do you define it when you have to make frequent changes to your product during the software development process? In simple terms: by defining scope we mean adopting a clear vision and an agreement on the deliverables expected from the project.

While defining the scope you have to prepare a detailed description of what the project is supposed to achieve and what it cannot accomplish. Of course, in today’s world changes to the project are inevitable, especially if you assume scaling up. To deal with that situation project managers use project scope management which includes defining project needs, understanding the project objectives and the project scope definition. 

By using Work Breakdown Structure (WBS), Product Breakdown Structure (PBS) or Resource Breakdown Structure (RBS) you can determine the impact of the change on project scope.

These structures identify the features, components or resources that would need to be added, changed, or deleted during the lifecycle of the project. By doing so it will help to avoid scope creep. Furthermore, you must frequently update your project scope and communicate any changes to all stakeholders. 

Tips:

• Use WBS, PBS RBS to identify any changes that can impact the project
• Update your project scope frequently 

How to re-organize a software development model when the product continually changes?

To maintain both high-quality and high-value when the product continually changes there is a need for a re-organisation of the software development model, which means choosing the right methodology, preferably the agile one (Extreme programming, Scrum etc.) When it comes to requirements, project managers using Scrum tend to freeze the model for the current iteration so developers have a certain level of stability, although XP and DAD practitioners allow a change during the iteration. Whichever you choose, it is important to bear in mind that it may result in moving some requirements to the next iteration.

When working on the software project, stakeholders are responsible for defining and prioritizing new requirements, whilst developers are in charge of estimating the effort it takes to implement them. As many examples show, dealing with smaller requirements is easy to estimate, while bigger ones can be challenging.

So how to manage more difficult requirements? You must  reorganise them into smaller and more manageable parts, so they can be implemented within a single iteration. As for iteration itself, it has to be shorter than in Scrum because it reduces the feedback cycle, making it easier to stay on track for both developers and stakeholders. 

Tips:

• Incline toward Agile rather than traditional methods. 
• Try to manage any change to requirements within one iteration.  

How to structure the roles matrix?

As the company grows in size, the structure is becomes more and more complex, but a traditional organizational structure can hinder productivity. It also takes a lot of effort to ensure a good flow of information because one employee is only accountable to one person. However, there is also an alternative structure called a matrix organizational structure that addresses most of these problems.

Matrix organizational structure allows companies to leverage vast resources while staying small and task-oriented. In this grid-like structure, every person typically has two managers: a functional manager and a product manager. Instead of assigning employees exclusively in terms of function, the matrix structure allows to form interdisciplinary, cross-functional groups centred around certain goals. We distinguish three types of Matrix Organisational Structure with different degree of authority: 

• Functional Matrix: project manages are limited to coordination
• Balanced Matrix: project managers are responsible for defining what needs to be accomplished
• Project Matrix: Project leaders have primary control over the entire project. 

Depending on your business objectives and the way your company operates you can also choose the Partial Matrix Structure, allowing you to form an interdisciplinary task force. Furthermore, you may also consider the Ad Hoc Matrix structure that can be used to address short term projects.   

Matrix structures allows companies to:

• Focus on multiple business goals 
• Facilitate the flow of information
• Quickly respond to environmental demands

Key takeaways

Before taking an effort to scale-up your business there is much to consider. Bear in mind that this move implies more than just a simple definition of your project scope and  goal. While working on the constantly changing project you would be forced to choose between different software development strategies. Furthermore, as your team grows, it is crucial to take care of the proper role matrix, enabling its interdisciplinary functionality.

Seems like too much trouble? The good news is that there are many consulting companies that can help your start-up with transition, scaling the project to your exact business needs.

Eversoft is a leading Software Development as a Service (SDaaS) partner with expertise in delivering solutions optimized for future business goals in terms of technology and architecture. Apart from exceptional competences in technology our company stands out because of its holistic methodology and business-first approach.

---

Related posts:

• The biggest startups concern: How to organize a software development model when the product is constantly changing
• Is your startup/scale-up ready to work with external software providers – Readiness checklist
• 9 code quality sins made by startups in their software development process