How to prepare for outsourcing a digital project to a software house?

By failing to prepare you are preparing to fail

Accessibility is what makes the digital product market so unique. However, at the same time, it's also the most significant flaw since it welcomes the unprepared and tolerates ideas that are poorly thought out.

Just as you would if you wanted to establish a new brand of cars, there’s a lot to think about before creating any digital product. Start with a general overview of your project that is aimed primarily at understanding what exactly is it that you want to sell. Yes, sell, not only build. Pink Floyd knew the value of their work and how to monetize it, as should you. Nobody makes software purely for artistic value.

If you see your product as something you want to sell instead of just make, you’ll automatically include marketing & sales perspectives in understanding the idea and designing its form.

How to start preparing for outsourcing a project?

Start with defining the general concept and specifying the idea that motivates you (“money” does not suffice for an answer here). Then gradually move to details. Here are some essential questions you should ask yourself:

• What is the business goal of my project? (a.k.a. What need am I addressing with my solution?)
  It’s probably one of the most important questions you should ask yourself before putting any real money in play. A precise definition of the business goal also provides you with a set of important follow-up questions, such as:
• Whom am I addressing with my solution?

• How to make it a sustainable and scalable business? (a.k.a. How am I going to charge money for it?)

This is extremely important. When defining the business goal, you most probably had a specific need that you want to address or a niche to fill with your product. These follow-up questions force you to explore further. The second question forces you to think about the end user of your product (someone with a specific need, your addressee), while the next one helps to identify a business model that will suit your product and bring revenue (how are you going to monetize the answer to this need).

Building vision

Once you have the general understanding of the product, it’s time to build a vision. At first, it may not seem like a must, but, as an exercise, take a moment and imagine what a banking app looks like. Go on; I'll wait...

Did you think about information display on the dashboard? Or functionalities connected with bank transfers? Transaction history? Or current balance?

What I mean is that it’s not enough to specify “I want to make a banking app”. It’s simply too broad of a subject - everyone imagines their banking app differently. That’s why it is important to have a vision that unified with your software development team to make sure you all know how to define the project.

A detailed method of defining the vision of the project was proposed by Karl Wiegers in his Software Requirements book:

Vision componentContextWhat is the name of your product?Give it a name so you can communicate quickly with your development partners.How would you categorize your product?Is it a CRM? Or is it a social media app?Who is it for?Identify all potential users of your product.What need does it address?Identify the most important needs of all potential users.What benefits does it bring?List some of the benefits that come with using your product.What’s its alternative?How do your end users deal with things without your product?What differentiates your product from your competitors?What are your unique selling points?

Once you have completed the above you have the general understanding of the project and - most importantly - can convey it in measurable terms. That’s great because now any established software house will understand what it is that you want to build and consequently sell. Of course, your development team might have additional questions (at Merixstudio we go in-depth into project understanding with our clients during workshops), but don’t feel discouraged - having a strong understanding of the general overview will let you answer most of them easily.

Time is (quite literally) money

Another aspect to determine are business fundamentals of the project, namely deadline and budget. Those are the constants of every project, and their role in software development is essential due to few reasons:

• they serve as limits to what can be achieved,
• they are an important factor in planning resources for development teams,
• they help decide what software house to look for.

Deadline and budget should be well thought out. You should base your deadline on solid research, market factors, and business reasons. A budget shouldn’t be based on a whim nor a guess. If you’ve got a set amount and don't want to go over it, then it is always best to communicate it up front. Ideally, you could schedule any talks with investors after you’ve got your first high-level estimate from a software house.

A good software house will always take deadline and budget into consideration when evaluating your project and tell you whether they think they’ll fit in or exceed it. If the budget turns out to be insufficient, there are some ways to deal with it - you’ll know you’ve found a right development partner when they present feasible solutions before you even ask them.

Communicating the deadline and budget is important from the perspective of determining the best resources for the project, as well as planning the headcount of the development team. If you’re on a tight deadline, but the budget allows for it, you can always add more specialists to your team, so the work goes faster. If the deadline is in a distant future, but the budget is limited, why not schedule a developer to work half-time?

Lastly, hourly rates are a good indicator of how established a software house is among its clients. Usually, one that communicates higher rates is in strong demand. In software development, brand means all, since a lot of new projects come from referrals and client reviews (for example on Clutch). Delivering mediocre work would, therefore, mean losing quite a lot of projects. That is why no reliable software development company will promise you something they can’t deliver.

Defining modules

A module here is seen as a conceptually whole subpart of the system. Sounds difficult, but in reality, it isn’t. Imagine a CRM system (a sales management system) - it will have several domains, such as client database, reports and statistics, or invoicing.

Every module has a set of features that streamline a specific process. For example - the client database module will contain features that help Sales Representatives manage their clients, leads, and relations. With that in mind, it should include a list of all contacts, current deals, lost deals, adding and editing functions, and so on.

Defining modules of your digital product is the first step towards structuring the requirements and understanding the key processes it should cover.

Defining processes within modules

You’ve got the modules covered so it's time to address the processes that are in them. Let’s decompose the process of adding a new client to the CRM database. The steps are as follows:

1. assuming the user’s already logged in, open “Clients” tab;
2. click “Add new” button;
3. fill in client’s personal information;
4. fill in contact details;
5. attach client’s project description;
6. select project type;
7. save input data;
8. add a note and a phone call reminder to clients profile.

If that was done by a regular sales representative, here’s what the process might look like from the head of sales' perspective:

1. see “New client added by John Doe!” notification
2. open “Clients” tab;
3. filter the list by sales representative “John Doe”;
4. open clients profile;
5. leave a note with a next step recommendation.

Do the above to all of the processes you have defined for your digital product. It’s a lot of work, but it pays off in understanding what’s crucial and what’s only nice to have in the early versions of your product. Of course, you may not yet be able to define the process down to every button and text box. That’s perfectly fine! It's only important that you understand what the process should look like - a good software house will take care of determining the best technological interpretation and solution.

As you probably noticed, the same process has its different users. One is a Sales Representative, while the other is Head of Sales. Naturally, Head of Sales has more influence, so they have access to more actions within the application than a regular Sales Rep. The difference lies in user types (or user permissions), about which I will talk in the next section.

User stories - where the fun begins

Now that you have an understanding of what is supposed to be happening within your digital product, you’re ready to start defining User Stories.

User Stories are used widely in software development world as a method of defining specific requirements or planning functionalities. Consider them as methods of translating an idea into a common language any development team will understand. Specify what is supposed to happen if an action is taken, decide who performs it, and then define its specifics.

To put it simply, if you think that “there should be a way to allow a Sales Representative to add a new client record to the system”, then here’s how you transcribe it for your development team:

Template: As <USER> I want <FUNCTIONALITY / ACTION> to <OUTCOME> because <REASON>

Example: As <SALES REPRESENTATIVE> I want to <ADD A NEW CLIENT> to <UPDATE CURRENT CLIENT DATABASE> because <CLIENT DATABASE HAS TO HAVE A COMPLETE REGISTER OF ALL ACTIVE AND NEW CLIENTS FOR PERFORMANCE, STATISTICS, AND INFORMATION PURPOSES>

The <USER>, or users, are different types of people that will benefit from your product. In this example, I defined two: a Sales Representative and Head of Sales.

The reason I did it is that most of the time these two types of people will have different permissions within the application. Here, permissions mean as much as authority or roles. Sales Representatives have authority over the leads and clients they oversee. So within a sales management system, they will have access to such actions as adding a new client, editing information on existing ones, seeing a list of added clients, and so on.

Head of Sales has more authority by definition, so it should be reflected in their user’s permissions. They could, for example, add a new client and assign it to a Sales Rep, edit information on any other Sales Rep’s client, see a list of all Sales Reps’ clients, or see team performance and invoicing reports. It’s up to you what roles (types of users) there will be within your product and what actions they will be permitted to perform.

The <FUNCTIONALITY / ACTION> and <OUTCOME> part is simple action-reaction scheme. You define different actions that can be taken within your application that are relevant to both the module that should contain it and the need you want to address.

Now, what you’re going to read below is probably one of the most important points I’d like to make:

Every action allowed in your software needs to (at least partially) answer the need you’re addressing. Every action that you want to be implemented should be relevant to your business goal and the end users you’re targeting. No exceptions!

Note the <REASON> element in the User Story formula. Every feature should have a reason to be implemented because every feature will cost you time and money. Allowing unnecessary elements in your project scope wastes both your budget and time without bringing any real business value that makes your product more attractive to its future users.

Scope of Work, MVP and Feature Prioritisation

Once you defined user stories, it’s time to decide which of them are the most important from the perspective of the business goal, end user, budget, and deadline.

The “absolute must have” features form the MVP - the Minimum Viable Product. It is a minimalistic version of your software consisting of only those modules and features that are required to achieve the business goal.

At Merixstudio, we always recommend starting with building the Minimum Viable Product. It is the bare minimum of what defines your software as a way to achieve your business goal. This also allows you to test the concept in a real market environment before investing too much money. If it takes off immediately, great - you can start talking about scaling. Keep your reliable partner close to you and work on a good strategy.

There are several ways to define the MVP of your product. Here’s two of them:

Eisenhower’s matrix meets MoSCoW analysis

You might know what the Eisenhower’s matrix is. You might not know, however, that it can be used to define your MVP. All you need to do is interpret different combinations of urgency and importance regarding functionalities (instead of tasks). See below:

Take all of the functionalities you’ve defined through User Stories and decide (as objectively as possible) which ones have the strongest correlation with the business goal of the product. Assign them to their respective fields. Remember - all "must have functionalities" are your MVP. The "should have" ones are worth considering if they fit the budget or in further development plans. Consider “could have” features a luxury and eliminate the “won’t have” ones.

Workshops

The second way to scope out an MVP for your product is to work with a software house that offers Product Discovery and Scoping workshops. There is a wide variety of reasons why this is an option worth considering:

1. the project is so big and complicated that it's hard to determine which elements are the necessity;
2. you are uncertain about your assumptions and need to confront them with specialists;
3. there is more than just the MVP to determine: designs, user experience, solutions;
4. you wish to consult the technological feasibility of the product;
5. you need a thorough plan for development with an accurate evaluation of time and costs.

Workshops are an effective way of gathering a potential development team to work with you in the early stages of defining your product. The way we do it at Merixstudio is we invite you to our office in Poznań, Poland, for 2-3 days. Every day has its own agenda with a focus on delivering the outcomes that provide the most business value. A team of UX & Graphics Designers, Developers and Project Managers work with you in the initial stage of Product Discovery, where you define the fundamentals of the project. In the Product Scoping and MVP stage, Project Manager’s strategy meets Developers’ technological expertise. Finally, when everything is taken care of, the whole project is estimated, and a low-level evaluation is presented to you.

The most important aspects of preparing for outsourcing your project

I agree that it’s not easy to take all the above and just do it (contrary to what Nike and Shia LaBeouf say). Unfortunately, there’s no way to practise it other than simply work it out by following the guidelines.

It is critical that you can effectively communicate the requirements for your project before you approach a development company. There are few reasons for that:

• digital projects are complicated and need to be structured and defined in details,
• requirements that are clear to you might not be evident to development teams - correcting your assumptions will be costly,
• translating an idea to a development plan and decomposing it to small features needs effective methods and tools,
• if you don’t do it, your software house will have to, which will take your team’s time (it's worth noting that some companies even charge for it),
• only a structured and well-defined concept can be reliably evaluated; otherwise, it’s hit or miss, or what we call a guesstimation.

On the upside, doing all of the above for your idea will skyrocket your understanding of its details and allow you to discuss it with development teams effectively. You’ll be able to quickly share all relevant information as well as receive an accurate evaluation on which you'll be able to base your business decisions.

However, if you feel that you still need professional expertise on how to plan and handle the project, are wondering what will an accurate evaluation of your project look like, or simply want to approach investors with some beautiful designs and wireframes, then it’s best if you contact a trusted software house and ask them to schedule a workshop session with you. Here're also some tips about finding a reliable parter in IT outsourcing. Good luck, Digital Product Owners and CEO’s!

‍