Your Guide to Writing a Software Requirements Specification (SRS) Document#Product label
A software requirements specification (SRS document) describes how a software system should be developed. Simply put, an SRS provides everyone involved with a roadmap for that project.
It offers high-grade definitions for the functional and non-functional specifications of the software, and can also include use cases that illustrate how a user would interact with the system upon completion.
Hint: We can help you write a detailed SRS and build software according to it. Just contact us now.
Why is an SRS Document Important?
Suppose you want to create a chat app with a specific appearance and functionality and would like it to be geared specifically to enterprises. You feel that you can cut out the extra features that commercial chat apps use to appeal to the public and focus on features that enterprises need. But you aren’t a developer.
So you need to outsource the development of the app. But you also need to make sure that whoever you hire to turn your idea into reality knows exactly what you’re trying to accomplish. Without all the details to finish the app, time and cost can quickly get out of hand. Developers can take a wrong turn and have to refactor the code if the finished product doesn’t match the picture you had in your head.
An SRS document forces you to put the idea down on paper to cover all these details. You must translate this idea into a language that developers understand. An SRS document describes what a client wants and what developers will provide. It is the written agreement on every detail of the app.
Having a clear set of requirements ensures that a development team creates software that meets the clients’ needs. An SRS will help with estimating the cost of work and covering the project scope. It also gives coders an idea of the tech stack they’ll need and helps them plan their work, but that’s not all:
- Designers get project insights through SRS documents so they can match the design to the use case.
- Testers get the guidelines for creating test cases that match the business’s needs.
- End-users use the SRS to understand the software.
- It provides investors with an overview of the system’s features so they can make investment decisions.
An SRS is important because it is a single source of information and expectations, which prevents misunderstandings between project managers, developers, designers, and testers.
What Does an SRS Include?
An SRS should have enough information for developers to complete the software described. It not only lays out the description of the software under development but also the purpose it will serve: what the software is supposed to do and how it should perform.
An SRS document typically includes these elements:
- The purpose of the software being developed
- An overall description of the software
- The functionality of the software or what it is supposed to do
- Performance of the software in a production situation
- Non-functional requirements
- External interfaces or how the software will interact with hardware or other software it must connect to
- Design constraints or the limitations of the environment that the software will run in
The Difference Between Functional and Non-functional Requirements
Functional requirements are the goals of the new system you are designing. They describe the system and how it will function to help with a user’s tasks. They define how the system will respond to user input and have details on calculations, data input, and business processes. You can consider functional requirements a detailed description of the application’s features and the user’s needs. Without meeting the functional requirements, the system will not work.
While functional requirements specify what a system does, non-functional requirements describe how the system will do it. Non-functional requirements do not affect the application’s functionality. Even without meeting non-functional requirements, the system will perform the desired tasks.
Non-functional requirements are also important because they define the general characteristics that affect user experience. Instead of focusing on user requirements, they focus on user expectations and cover such topics as performance, security, reliability, availability, and usability.
How to Write a Software Requirement Specification Document
It is best to organize the process you use to write an SRS document by starting with a skeleton and general information on the software you’re developing, and finishing by adding details to flesh out your draft. Here are six steps involved in creating an SRS document:
Get software requirements specification
Relevant is a 7 years old software development company. We helped 200+ companies safely outsource their software development. Let us help you write SRS and build your software project.Contact us
Create an Outline
The first step in the process is to create an outline for your SRS. You can create this yourself or use an existing SRS template as a starting point. Here is a basic example of an SRS outline:
- Intended Audience
- Intended Use
- Overall Description
- User Needs
- Assumptions and Dependencies
- System Features and Requirements
- Functional Requirements
- External Interface Requirements
- System Features
- Non-functional Requirements
Define the Purpose
Once you have an outline, you must flesh it out. Start with defining the purpose of the product in the introduction of your SRS. Here you will describe the intended audience and how they will use the product. Here’s how you should structure the purpose:
- Define the product’s scope
- Describe the value it will deliver
- Show who will use the software
- Detail how it will help with the intended users’ job
Give an Overview
After defining the product’s purpose, summarize how it will work. Here you will give a general description of the software’s features and how they fit the user’s needs.
You will also describe the assumptions you are making about the product’s functionality and anything it depends on in the current tech ecosystem.
Describe Functional and Non-functional Requirements
Now that you have written the general information, it is time to get more specific. Completing your overview before you work on functional and non-functional requirements gives you a reference to make sure you meet the user’s basic needs while you fill in the details.
This detailed description of the system’s requirements is the most essential component of an SRS document. Describe the functional requirements in enough detail so developers can get to work and the non-functional requirements like security specifications and performance.
Here is where you add use cases to vividly describe how a user will interact with your system. It is where your project’s objectives are detailed and will measure how the project is progressing during development.
Add Supplemental Details
The last step in creating the draft of your SRS document is adding any details that could help developers finish the job in the form of appendixes, glossaries of terms, and references.
Once you have added enough details to the SRS to describe what the system is supposed to do, it is time to have the stakeholders approve the document.
You will most likely have to make a presentation to the people involved in the development process. They may ask for changes, and you will have to update the SRS document based on stakeholder feedback before final approval.
This is a good sign. It means both developers and stakeholders are making the document more precise, so the project is less like to go off track.
How to Write Software Use Cases in an SRS
A use case describes how a user will interact with the system. It will describe the product from the end user’s point of view in a simple story format. Writing out use cases forces you to think through what users will do with the software and how it will respond. It is the real-life visualization of the functional requirements.
Here are steps you can follow to write a use case:
- Describe your product’s end users.
- Focus on one of these users.
- Break this user’s interactions down into use cases. Each interaction is a use case.
- Describe the sequence of events for each use case.
- Write a detailed description of the user’s actions and how the system should respond.
- Expand each use case with alternate user actions and system responses.
- Repeat 1-6 for each type of end-user.
What are the characteristics of a great SRS?
There are specific characteristics that every SRS should have. By reviewing this list and comparing it to your SRS, you can ensure that it will be a useful document for all stakeholders.
An SRS document should be easy to understand. Nothing should be vague, so there are no misunderstandings between stakeholders.
The requirements in your SRS document need to be measurable, so the finished product can be validated and verified against the specifications.
An SRS document should have enough information for your development team to finish the product and for testers to validate that the product meets the user’s need without bugs.
The requirements should fit the reality of the current environment, including the budget, timeline, and technology. They shouldn’t depend on upcoming technological breakthroughs.
Because things could change in the working environment, your SRS document should be flexible enough to allow for updates. Don’t add redundant information to multiple sections that have to be updated with each change.
Everyone on the development team should have access to the document so they can reference it as frequently as necessary. Requirements need to be precise so that team members do not have to ask for more details. They should all be available in the SRS document.
The requirements should fit each other. One section of your requirements document should not conflict with another. The document should be formatted consistently and used the same terminology throughout.
No Implementation Constraints
An SRS document should be detailed enough to finish the job, but should not be overly specific, because that might restrict development. A lot of development depends on third-party services that developers have no control over.
Goals in a requirements document should be precise to avoid confusion. Avoid the following:
- Loopholes: “The application should load in 3 seconds if it can be done.”
- Ambiguity: “The MVP product should be released as quickly as possible.”
- Subjectivity: “The UI should be user friendly.”
- Superlatives: “This should be the best application in its class.”
- Comparative: “This application should be better than Slack.”
A Software Requirement Specification (SRS) Example
Here is a trimmed down example of an SRS document for an enterprise chat app called eChat:
This document details the project plan for the development of “eChat.”
It is intended for developers, designers, and testers working on “eChat” as well as project investors. This plan will include a summary of:
- how the system will function
- the scope of the project from the development viewpoint
- the technology used to develop the project, and
- the metrics used to determine the project’s progress
- Overall Description
Companies need remote communication tools, especially now that more people are working from home. The problem is that most companies end up using multiple applications to accomplish this: one for text chat, one for video chat, and one for conferences and meetings. “eChat” will solve this problem by combining these features in one application.
The customers will be enterprise companies. It will not target the general public.
- Users should be able to sign up with enterprise LDAP accounts.
- Users should be able to create ad hoc chat groups comprising sets of users and send private messages to individual users.
- Users should be able to have text chats that they can break into threads.
- The application should be able to handle group video chat of up to 100 users at a time.
These applications will connect to a REST API built with .NET Core to store and retrieve data from a MySQL database.
Authentication will be through existing LDAP installations.
The developers on the “eChat” team will be responsible for writing all the code for the application, developing the database, and managing releases.
User Class and Characteristics
There will be a class of users called admin that will have permissions to access all functionality of the app, including:
- Creating channels where multiple users can interact
- Making these channels public to the entire company or private for a group of people
- Deleting these channels
- Archiving these channels
Standard users will have access to all functionality of the app except those listed above.
- Users should be able to create ad hoc chat groups comprising sets of users and send private messages to other users.
- Users should be able to have text chats that they can break into threads.
- Chats should be able to be archived indefinitely so users can reference past chats.
- Users should be able to upload files to chats for reference.
- External Interface Requirements
- Front-end software: React Native
- Back-end software: .NET Core
- Database software: MySQL
- LDAP connection: Authentication in an enterprise environment
- Both Mac and Windows operating systems through their default web browser
- Non-Functional Requirements
- The application should load and be usable within 3 seconds
- The application should update the interface on interaction within 2 seconds
- The database should be normalized to prevent redundant data and improve performance
- The database should be distributed to prevent outages
- Databases should use sharding to be redundant to prevent loss of data.
- Backups of the databases should be done hourly and be kept for one week.
- Any keys used for the REST API should be stored securely.
- Only the REST API should be able to connect to the databases.
- Databases should be behind a firewall.
Software Quality Attributes
- Availability: Because this application is critical to business communication, we will have a goal of four nines(99.99%) availability.
- Correctness: The application should never allow anyone to read messages or discussions not intended for that person.
- Maintainability: The application should use continuous integration so that features and bug fixes can be deployed quickly without downtime.
- Usability: The interface should be easy to learn without a tutorial and allow users to accomplish their goals without errors.
An SRS document is a necessary part of completing a software development project. It is the roadmap that gives direction to everyone involved in the project, so the final product meets the user’s needs.
Without a complete SRS document in place before you start a project, it will be hard to tell when a project is finished and could sidetrack development into creating unintended features. An SRS document gives you the ability to estimate a project accurately and assign tasks efficiently.
Creating an SRS document can be a time-consuming, meticulous process. Fortunately, the team at Relevant has helped over 200 companies create SRS documents and launch new products. We are ready to help with your next software project, just drop us a line.
How to Write a Request Proposal (RFP) For Software Development#Product label
How do solicit bids for software development projects from reputable vendors? You create a detailed RFP to ensure you attract the right firm. To help with that, we’ve created a guide for writing a software development request for proposal (RFP).
What is an RFP?
The software development request for proposal is the initial document you create before you select a software development firm. An RFP can also be used for other projects. In it, you will outline specifics about the project, your requirements, even expected deliverable dates. Vendors will read this document. They will then submit a bid based on your request.
How do Software Development Companies Use RFP?
When a software company receives a properly composed RFP, they are more likely to respond appropriately. Companies that are interested in the work, and capable of doing it will respond with a detailed proposal. Your RFP is also a time-saving tool. Companies that don’t have the required staff or skill set will know to move onto the next solicitation.
Begin With an Executive Summary And Company Description
The executive summary is simply an overview of your overall goals, limitations, and requirements. Be brief, and make every word count. Don’t forget to mention your target audience. It usually helps to add some information about your company. Companies will be able to understand your needs better if they understand your organization.
When you write your project goals, keep one rule in mind. Think like a business person, not a software developer. That means stating your business needs and goals rather than listing technical specifications.
Next, consider how you will quantify your goals. For example, if you want a solution to improve your communication with workers in the field, consider what that will look like. Maybe it will be a 25% reduction in errors attributed to miscommunication.
Chances are, you will revisit this section before it’s perfected. If you have the following questions answered, you are off to a good start:
- What is your company’s mission as it relates to this project?
- What is your idea?
- How will it look?
- What processes would you like to improve or automate?
- Who will use the final product?
- What flaws exist in your current solution?
- Do you see any potential roadblocks (e.g., an outdated tech stack)?
Project Scope And Deliverables
This will be the longest and most detailed part of your RFP. Software development company reps will rely on this to create an accurate proposal. Here are some things you’ll address.
What does your project need to ensure reliability, security, and availability? This will define the infrastructure you need. Here, you’ll want to consider a few things.
- For self-hosted solutions, what is your current infrastructure?
- What changes will you need to make to your networks and server room?
- What do you need from a developer hosted solution?
- How will physical and data security concerns need to be addressed?
- What about intellectual property protections?
- How can access be limited?
How will your product function? Try to think in terms of:
- The user experience.
Write about what the user will see and be able to do. For example, ‘The user should be able to modify their preferences via their user profile.’
- Product capabilities.
Write about system related abilities. For example, ‘The system should send out a message to the warehouse manager when order exceeds more than 500 units.’
- Streamlining and optimization.
Detail things that should be automated so that users don’t have to take specific actions. For example, ‘The system should automatically submit a confirmation email for each order.’
- Entity details.
These are the characteristics of every entity that is part of the new development. For example, the entity, ‘Customer Service Ticket’ should have the following attributes: customer name, customer number, date and timestamp, explanation of the issue, assigned agent, urgency classification, tech representative, and resolution.
Mention any processes that need to happen, even if they aren’t seen or driven by user action. For example, ‘The system must synchronize manual orders with online orders each night.’
List of Experts
Who from your team will be able to add value to the process? This list might include users, business area experts, business analysts, and in-house designers and developers. This is where you’ll also mention the experts you are seeking from the software vendor as well.
This section will address questions, concerns, and expectations for project management. Yes, this does include methodologies such as Kanban or Scrum. This is also where you want to discuss project management tools, methods of communication, development platforms, and testing. This is also a good time to discuss whether you are interested in a fully remote solution, dedicated teams, or something hybrid.
Two other considerations are QA and documentation. Consider requesting information from each vendor on their QA and testing policies, as well as how they create both developer and user docs.
Timeline For Response
Your RFP should include a brief timeline for accepting proposals. Your timeline should include:
- Deadline for submitting an intention to bid.
- Date range for holding interviews or receiving preliminary questions.
- Deadline for submitting formal bids.
- Date for notifying final candidates.
- Date range of final interviews
- Deadline for candidate selection
Keep in mind that you’ll get the best responses if you can give developers as much time as possible to formulate their responses.
Bid Structure And Requirements
What information do you need from vendors to make a decision? Are there any restrictions you want to place on the businesses that respond to your request? Give detailed instructions on the information you need from each software company. If every vendor sends you the same information, structured the same way, you will be able to conduct a side by side comparison. Here’s a list of the data that is commonly included:
- Company name and background.
- Project management preferences.
- Qualifications of team members.
- A primary project plan.
- A vision of the final product.
- Plans for training and support
- Cost breakdown
Don’t forget to add any other criteria. For example, if you absolutely want developers to come in-house, then you’ll need to indicate that. Otherwise, you’ll be fielding bids from companies that don’t meet your needs.
There’s no standard template for writing an RFP for software development. Instead, we’ve provided you with some guidelines and important considerations. Keep these in mind while creating a request for a proposal that meets your project needs.
If you don’t want to bother yourself with writing a proposal or have trouble describing the technical part, you can schedule a call with our team. Relevant is a 7-years old software development company with excellent product development expertise. We will be glad to hear and write down your requirements.
How to Build Custom Employee Time Tracking Software#Product label
Choosing between off-the-shelf and custom software is like ordering pizza from the menu versus creating your own. What the waiter will bring you is going to be delicious, but you won’t be fully satisfied if this is not what you really want.
In this article, we’re going to answer all your questions about custom employee time tracking software: what it is, how it works, whether you should develop your own tool, and if yes, what it’s going to take.
Manual vs. automated time tracking methods
So there are two basic time tracking methods, manual and automated. But not a single of them is universally good for every business. Depending on the company size and a business model, some organizations can feel fine using manual systems, whereas others may desperately need automated solutions.
Manual time tracking systems
This time-tested and familiar method is going to be best for smaller organizations and teams working in the same office/ in the same field.
- Inexpensive compared to automated systems
- Easy to implement and manage
- Often inaccurate (depending on an employee);
- High possibility of human error;
- Still requires you to calculate payroll and write documentation;
- Doesn’t integrate with other tools.
Automated time tracking software
Automated software tools are going to be better for large organizations that have multiple teams scattered in many different locations.
- Minimal possibility of human error;
- Transparent performance tracking;
- Automatically calculates payroll and generates reports
- Integrates with other tools
- More expensive;
- Requires basic PC-user skills for all employees;
- May be harder to implement in remote rural areas.
Whereas both methods have their users, the automated systems are growing in popularity. And if your company is growing, you’ll inevitably hit the wall with manual tracking. When it’s no longer enough to cover your business needs, you’ll have to switch to an automated system, but you’re going to love it.
How does an employee time tracking software work?
Generally, all employee time tracking systems work the same way. User signs up and gets access to all/ some system features (based on the admin rights).
User creates/ selects a project
Admin users have access to more features. They can create projects, add tasks, add other users to the team, and so on. General users can access the projects/ tasks without the right to modify these.
User starts the timer or inputs manually the hours worked
Employees select the project/ task, start the timer when the work begins and stop it when the work ends. Usually, it’s also possible to leave project notes.
Software processes data
The software automatically tracks hours worked and records user data in the timesheet. This information can be later used to generate invoices.
Software generated reports
Besides invoices, it’s also possible to generate other user activity reports. This data can later be used by managers and team supervisors for analytics purposes.
Basic features of an employee time tracking software
Long gone are the times when employee tracking software would solely record the number of hours people spent at the workplace. Contemporary time tracking tools are versatile instruments with a variety of useful functions. Below are some common features of modern time trackers:
These are the attendance reports that show all the information regarding billable hours (present/absent, time off, holidays, and vacations).
This is the key feature of such software. It captures and keeps the record of total hours spent by the person at the workplace.
Project management features
Besides time tracking, this kind of software usually has additional project management tools, such as assigning tasks, setting deadlines, monitoring overall progress (daily tasks/ weekly, monthly goals).
Counting hours and preparing invoices is probably the biggest headache of most managers. Modern time tracking software does that automatically. It might even send invoices to the customer.
This feature allows managers to create teams, add/remove users from the groups, and so on. The system has various user types, each with different accessibility levels (e.g. admin user, general user)
The system will notify the user every time something happens. For example, if the workday has already started and the user forgot to check in, or if the important deadline is approaching, a notification will ping them.
Reporting and analytics
The ability to organize and interpret the data is just as important as collecting it. That’s why modern time tracking software usually has corresponding features (generating reports, graphs, and so on).
Integration with other tools
Time tracking software integrates with other managerial tools, making lots of things easier. As a result, tasks like accounting, payroll, project management, and so on are greatly simplified.
When it’s better to build a custom time tracking software
Let’s take time tracking for the construction industry as an example. Supposing, you’re a foreman, a construction site manager, and you have two teams working in different places. You want to find a better means to track their working hours and a more efficient way to prepare documentation.
Also, you could use some monitoring assistance since it’s impossible to be physically present in two places when you need to ensure that both clients are happy with the result. And of course, it would be amazing to have a tool that automatically counts hours worked and generates invoices because this routine work takes up too much of your time. Plus who wouldn’t like being able to track how much workers spend on the materials?
Whereas tracking hours and generating invoices is possible with any time tracking tool, monitoring spending on materials for construction (such as concrete, pipes, sand, broken stone) might be too much for an off-the-shelf software. You’ll probably need to combine several tools and juggle the data back and forth. Or you can have a custom software solution tailored to your specific needs, and it will provide you with all the necessary support and automate the most time-consuming routine tasks.
So how do you know when you should invest in custom software and when it’s better to use a ready-made solution? From our experience, you probably need a custom one if…
Your industry is very specific
To automate workflow management in more complicated industries like construction, it’s not sufficient to track time and generate invoices. There are several other important aspects, which you simply can’t cover without a proper customization.
Your business needs are growing
In case you need domain-specific time-tracking, or when some tasks in your expanding business theoretically could be automated, but require custom features, it’s better to have your own tool.
Your current software doesn’t cut it anymore
If your current out-of-the-box software doesn’t fully cater to your needs, or if it solves some of your problems only to some extent, you will benefit from some customization.
You have time to wait
Custom software development requires a lot of time. Depending on the complexity, it can last months or even years, so you have to be willing and ready to wait, as well as to actively participate in the process.
You have the budget
Compared with off-the-shelf software implementation, custom software development is way more expensive. You’ve got to be ready to invest in the team that will have enough expertise to get you covered.
Here’s a little mind map to help you figure it out:
Pros and cons of building a custom time-tracking solution
Custom software development has its benefits and drawbacks. So before you decide to go with this option, take a moment to evaluate your needs and expectations. There are quite a few factors you need to consider while making this choice, both beneficial and not so much.
Let’s start with the pros.
Custom development pros
- It’s custom
As the name implies, your software is going to be tailored to your specific requirements. Your tool is going to have everything you’ll ever want (as long as it’s technologically possible). It’s up to you to decide what features and modules to use.
- It’s scalable
If you know your company is going to grow in the near future, or if you’re planning to add more services, rest assured knowing that your custom piece is going to cover that. You’ll just need to request more updates and the team will do it for you.
- It’s smooth
Provided that you cooperate with an experienced team and communicate with them constantly, software implementation is not going to disrupt your business processes at all. Your employees won’t even feel the change.
- It’s reliable
Another great benefit of having custom software is the instant support you will get from the development team. Most vendors are fully accountable for the tech side of things and they will offer lifelong support and maintenance for their clients.
- It’s yours
You don’t need to purchase licenses and you don’t have to adjust to any unexpected changes as it often happens when using most SaaS products. Your software is 100% under your control.
Custom development cons
- It’s expensive
Custom employee time tracking software development requires high upfront investment plus potential extra expenses. Even though it’s going to pay off in the end, this may be too much for some organizations.
- It’s a long process
The vendor is going to build a unique solution from scratch, and the more complex the software is, the longer it will take to develop it. Some tools can be created in a few months whereas others may require years.
- It does not guarantee success
The whole process is going to take a lot of research and testing. But you can never be sure that it’s going to bring the results you’re hoping for. Like with every other aspect of virtually any business, there’ll always be some degree of uncertainty.
How we built custom time tracking software for construction industry
Here at Relevant, we’re helping companies around the world build software and scale their engineering teams. One of the companies we’ve worked with is a Norway-based startup 24Onoff. Their product is a custom time tracking software for the construction industry. The goal for this project, now successfully completed, was to come up with the solution that would track time, automate routine tasks, minimize paperwork and billing delays – all in a single software. Together with the 24Onoff team, we’ve developed an efficient and super convenient tool that now simplifies the workflow of many construction teams worldwide. Over the past four years, we’ve been constantly adding new features to this product, and today, 24Onoff is growing into a serious Procore competitor.
Features of 24Onoff
- Informative and easy to navigate dashboard with a detailed overview of the user’s current projects.
- A set of project management tools for tracking tasks, deadlines, assigned employees, and other project details.
- An accurate time tracker with optional logs (expenses, travel distance, lunchtimes, and so on).
- Custom reports generator with various filtering options and export formats (PDF, .XLS, .CSV).
- Invoice manager based on the time tracker and employees’ profiles, which calculates pay automatically and exports payment data to the payroll system.
- Offline mode in mobile apps, with the help of which it’s possible to use the app without internet connection (all the data will synchronize once the device gets connected to the network)
What technologies we used
To build this product, our devs used the following tech tools and solutions:
● Cron – the software utility Cron is a time-based job scheduler in Unix-like computer operating systems;
● AWS RDS – Amazon Relational Database Service;
● AWS S3 – Amazon S3 Object storage;
● AWS SQS – Amazon Simple Queue Service;
● AWS Lambda – Amazon service for running code without thinking about servers;
● AWS Step Functions – build distributed applications using visual workflows;
●Amazon Elastic Compute Cloud (Amazon EC2) – a web service that provides secure, resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers;
● Elasticsearch – an open-source distributed, RESTful search and analytics engine capable to solve the growing number of use cases;
● Amazon Elasticsearch Service – fully managed, scalable, and secure Elasticsearch service;
● DocumentDB – Amazon DocumentDB (with MongoDB compatibility);
● Kibana – your interface into the Elastic Stack;
● REST API – representational state transfer;
● PHP Framework – software and libraries on the PHP programming language;
● IaC – infrastructure as code;
● Terraform – open-source infrastructure as code software tool created by HashiCorp.
● IOS / Android / Web – presentation layer.
Time tracking software architecture
We’ve decided to go for microservices architecture – separate individual modules (time tracking, reports, ERP system integration, etc.) to increase overall platform efficiency. Our engineers divided Angular code into custom components and had separate services written on PHP and Node.js to make building and deploying code faster and more reliable. Below is the schema of the 24Onoff platform.
Top 5 Open Source Time Tracking Software
Do you think you could use time tracking software for your business? Check out our top 5 open source time tracking tools you can use now for free.
This is web-based software for time tracking and basic project management. With the help of Redmine, it’s possible to manage multiple tasks and several projects at once. This software is very flexible. It works on different platforms, supports role-based access control, and integrates with version control systems. Multiple languages are supported as well.
Simple software with an unlimited number of users and browser-based interface. You can use it on multiple devices, including mobile. The tool is super reliable and even if you quit your browser, Kimai will still track time. The only way you can stop it is manually. Check out its interface:
This time tracking tool helps companies record and analyze the time spent by their workers on different projects. It’s possible to use the hosted version or run software on-premise. eHour supports several languages and currencies, so it’s going to be most useful for companies that operate in various locations around the world. Here’s how it looks:
This is a powerful tool with various time tracking features. OpenProject would be great for project-based work, something like design or software development. It follows the team all the way through the project, which is great support for project managers.
#5 Project Hamster
Project Hamster also tracks the time spent on various tasks. This software will be most convenient for freelancers and individual employees. It’s possible to export or print out the timesheets with activity reporting. This is the Project Hamster’s interface:
Overall, it’s a good idea to build a custom solution provided that you know it’s going to simplify your growing business, you are ready to invest, and you have enough time to make it happen. If you are looking for a reliable software engineering team, Relevant can help! Contact us, let’s talk about how to make it happen.
Creating the Innovation Culture and Why It’s Important Today#Product label
Let’s be honest: without an active innovation culture, organizations fall into stagnation and lose to more innovative competitors. You know this all too well if you work for a corporate business that strives to compete with the likes of Tesla, Airbnb, or Uber. Every industry has startups like these, and they’re on a roll. The services and products they provide are not too different from those you offer — but why do they outperform established corporations?
Because these startups leverage the benefits of the continuous innovation culture, which helps them make decisions faster, select the most appropriate executors and toolsets for every task, implement processes, and adjust them based on feedback. Let’s take a look at the notion of the innovation culture and how it can apply to your business.
What Leaders Should Know About the Culture of Innovation
The culture of innovation boils down to perceiving creativity as a virtue, not a nuisance. It’s the freedom to express your ideas, regardless of how little experience you have, because there can be a seed of solution in a fresh look at the problem.
Sadly, though, we mostly see enterprises where employees are in a never-ending battle to meet the quarterly goals and keep the team motivated to do the same thing the same way, over and over again. Burnouts, loss of interest in self-development, passiveness are just some of the traits of the managerial body in large companies. And the larger the business, the bigger the scale of the problem. After all, it’s much safer to follow instructions than suggest new ideas and risk them becoming empty expenses.
Besides — and let’s be honest with ourselves here — while many companies state they are innovative, or at least assert the importance of innovation, few invest enough effort into it. Becoming innovative requires C-level executive buy-in, reallocation of resources within the company, updating processes, schedule adjustments, and a lot of daily work that doesn’t bear immediate fruit. That is why so many companies take their innovation culture initiatives halfheartedly or drop them along the way.
However, there are time-proven criteria and reliable tools that can help establish the culture of innovation in any organization large or small, foster this business innovation endeavor, and turn it into a driving force that will help your company stay ahead of competitors. Learning this information will help you become the transformational and innovative leader your company needs to survive and succeed long-term.
8 Pillars of Innovation
The first thing to understand is that innovation isn’t a one-time project — it is a continuous effort built of eight aspects, the so-called eight P-illars of the innovation culture:
- Processes. Designing, implementing, and adjusting innovation strategy, governance, performance measurement, innovation technology, and team structure.
- People. Finding the right talent and training them to work as a team.
- Projects. Taking the lean approach (short sprints, starting small, growing when needed).
- Problems. True innovation solves real-life problems; it’s not a C-suite’s pet project.
- Priorities. A long-term business innovation strategy, but one that can be adjusted based on the changing business needs and priorities.
- Progress. Measurable results and progress towards the goals set.
- Partnerships. External expertise and trends can help allocate internal effort with topmost efficiency.
- Places. Creating a workspace that stimulates creativity, mentally and physically.
Here’s how each of these components contributes to making your organization more innovative.
It’s hard to start innovating without previous experience. Innovation means changes, and executives fear that these changes may be for the worse. This is why building the right processes is essential: having the structure and strategy written down helps to ensure your efforts don’t go to waste.
The team is your greatest asset. But it’s not about headcount; it’s about motivation and dedication. To innovate, you need to attract external experts who’ve done it already and engage internal talents ready to give new ways and ideas a try. Find the right people both inside and outside your team and start rolling.
It’s impossible to do something new in an old way. You need to reform the project management approach from the start. Instead of planning the whole project at once, you need to start small, form lean teams (external + internal talents), work in short sprints, and build working processes before scaling them to the whole organization.
You need to ensure you get the most revenue possible with the biggest cost-efficiency. This means business innovation must be centered around the most pressing matters for your company, not some pivots or pet projects. Otherwise, it won’t get enough engagement from the team.
The bigger the company, the more problems it has to solve. It means there can be multiple areas to apply your effort to, and setting the priorities straight is one of the hardest steps of innovation. The best way to approach this is by forming an innovative thesis and sharing it with the managerial body across the company to make sure your innovative initiatives are aligned with the long-term company strategy. The stakeholders must see how doing things the new way will provide them with better results.
Setting measurable KPIs and tracking how your efforts push the company toward the desired goal is essential to get executive buy-in and confidence. Confidence means trust, and it comes with more resources, fewer approvals, faster processing of your requests, etc. This, in turn, leads to more rapid progress and more value delivered.
The biggest roadblock for many enterprises is the need to admit they cannot innovate on their own. It’s hard to believe that organizations with a lengthy record of mergers and acquisitions can be so stubborn in terms of forming partnerships with startups, external technology vendors, or research centers and universities. However, once the idea gets adopted, the pace of learning and training your team becomes much faster, and so does the transformation speed.
This aspect of innovation includes both physical and mental spaces. Strict offices with tiny cubicles weren’t designed to foster innovation and creativity. Take a look at the co-workings and innovative areas of other successful enterprise innovators. They have open spaces with bean bags, post-it walls, motivating quotes everywhere — areas where people feel equal and it’s easier to suggest new ideas.
However, it’s important to primarily build such spaces inside the heads of your coworkers by emphasizing that the innovation culture is all about trying, failing, and trying something else until it works.
These eight pillars of innovation are essential, but they require decent management tools to get moving and deliver value.
Top 5 Innovation Management Tools
Gartner provides a comprehensive list of innovation management tools covering such aspects as ideation, tracking of implementation, and results monitoring on various project phases. We listed the top five innovation management tools based on customer reviews.
Planview from Spigit
Planview is the top-end enterprise innovation management platform from Spigit. It offers extensive functionality and a vast variety of configuration options, allowing every customer to adjust it to their needs. The vendor provides ample onboarding and rollout assistance, knowledge base, training, and customer support. This resulted in 4.2 out of 5 stars, based on 17 reviews.
But there are downsides. Even the bare bones of the functionality take multiple hours to master, and you will need to invest several months to get everything configured the way your particular company needs.
Ideadrop provides a centralized idea governance platform that helps store, structure, and manage ideas from all stakeholders and team members, enable open discussions, and reduce the feedback loop. It’s quite easy to use, and the vendor possesses strong technical expertise in the innovation governance field.
The downsides of using Ideadrop include the somewhat long deployment and onboarding (up to six months) due to the in-depth configuration and a steep learning curve.
This solution is centered around increasing business agility, enhancing the decision-making process, and driving innovation across complex portfolios of organizations. While the off-the-shelf solution does not boast rich functionality, Itonics has quite a large number of integrations, and the vendor performs custom adjustments quite quickly. Itonics can be customized to meet the needs of any enterprise, allowing the product to become an integral decision-making part of any modern company.
The main potential downside of Itonics is the danger of lousy configuration due to miscommunication, so make sure your specs are precise. Otherwise, you risk investing in custom functionality you don’t need.
Brightidea Innovation Platform
This product provides integration with Active Directory, which is absolutely essential for global enterprises. It is very simple to use, and end-users need minimal training to start adding, tracking and managing their innovation initiatives and campaigns. This makes it an excellent choice for geographically distributed companies where staff training requires a lot of investment.
The biggest potential drawback of this platform is how long and complicated the initial integration and configuration are – up to nine months. However, the vendor provides in-depth help content and diligent technical support.
HYPE has proven to be a tool centered around capturing and cultivating ideas from inception to value. Customizable on both the front end and the back end, this platform can adapt to the needs of every organization. The vendor’s team is very customer-oriented, yet the full customization and implementation of the platform can take up to nine months.
The main downside of working with HYPE is its feature-richness and the lack of templated pipelines, so building the processes that work for your organization might require lots of trial and error and intense collaboration with the support center. However, the platform is being actively developed, and all customer feedback is noted.
Tips on Creating the Culture of Innovation
When you get all the basics covered and select the appropriate tools to oversee and govern your innovation culture, the final question remains: how can you keep innovating consistently without losing focus? Here are some tips from Revenant Software that will be useful in doing just that.
Treat innovation like a child
Treat the business innovation culture like a child: set strict limits, but let it play the way it wants. Innovation should be based on the overall organizational objectives, core capabilities, and focus areas, customer-centric services, and commitments to stakeholders. However, it should not be limited by budgets, deadlines, and micromanagement.
The innovators in your organization must understand what’s expected of them — delivering practical products and solutions that can be replicated and scaled affordably. But you should let them pursue their own approaches, make their own mistakes, and gain their own experience.
Follow the horizontal structure
Great ideas need to be conveyed to executives immediately – without intermediaries, or they risk dying along the way. If you want your company to become truly innovative, booking a meeting with an executive to discuss an idea should require no more effort than planning a lunch with a colleague.
Set the targets high to encourage creativity
When the scope of work is set higher, people start thinking outside the box, and instead of optimizing the existing routines, they can suggest a complete reconfiguration of the process, which can yield an efficiency increase that’s higher than you needed in the first place.
Don’t bite off more than you can chew
A company can indeed starve without new ideas. The contrary is also true — spreading thin to deliver dozens of projects can never yield tangible benefits. Your innovators must have two projects maximum on their hands, so they can switch back and forth if any roadblocks arise. But having over three projects will mean they won’t be able to concentrate on any of them effectively.
Remember: networking is essential
Your executives and employees should build external networks and partnerships in communities, conferences, and other knowledge exchange events. If they know many like-minded people, they can combine input from many of them and introduce better ideas.
Hire the best and do it quickly
Creative people don’t grow on trees, but they spring in startup incubators, university graduations, or hackathons. Maintaining good relations with universities allows you to get to know the best graduates. Grab them fast!
You can also hire ready teams from software development vendors to get instant access to a pool of talents that know how to build the business innovation culture from scratch. Such investments are likely to pay off very well.
How Relevant Can Help You Innovate
The innovation culture can be built like any other approach or initiative, but it cannot be bought like a product. Yes, it takes time, the constant engagement of all the parties involved, and investment of efforts and resources. But developing and nurturing the innovation culture is essential for the long-term survival of any organization that wishes to remain competitive in the fast-paced business world of the 21st century.
Ensure the eight pillars of innovation are present in your company and select the innovation management tool that meets your case best. Combine knowledge and approaches from creative employees and external experts. Put effort into restlessly fostering innovation and adjust as needed to maintain focus on the goal, instead of getting lost in procedures. And if you need help, we’re here for you.
Relevant helps tech companies and businesses innovate through technology, by providing workshops and brainstorming sessions, business analysis, and software development services. Contact us, and let’s transform your company together!
How to Manage Your Software Development Partners#Product label
Tech companies almost always use development partners, yet managing them to produce a polished, releasable product on time, is a challenge. The challenges multiply when projects involve multiple parties, each producing parts of a whole using Agile methodology.
We have seen companies manage partners effectively by using a lean and effective, small ‘a’ agile product development process. First, they define roles and responsibilities clearly and completely. Then they extend this small ‘a’ approach by putting a ‘ring fence’ around your development partners. In addition to any legal agreements, they generate an informal contract between partners. This agreement allows your partners to be creative and allows you to manage your project’s targets.
Partnership Life Cycle
The first step to managing development partners is to understand the life cycle of a partnership. This life cycle includes the search for potential partners, qualification, official engagement, achieving a symbiotic and optimum relationship, leveraging the partnership through the project and across the company, and then possible disengagement. The figure below illustrates these stages.
The pre-phase for any partner engagement is to search for the best possible partner for the project. Since the most fruitful collaborations may occur with partners located anywhere in the world, searches might be quite extensive and complex, and they are usually going on continuously among the development and procurement groups.
During the Qualification phase, you will select a potential partner and then go through a process to determine if that partner has the competencies, capabilities, capacity, and compatibility with your company to accomplish your goals. This phase might include executing a small development project to see how well the partner team works with your company’s team. For more on the partner selection process see Relevant Software’s ebook.
In the Engagement phase, you negotiate contracts and/or service agreements, which are often written by a professional from a procurement or a contract management function, and then reviewed by the legal departments of both companies. Both parties will select people or teams that will interact with one another. Then the partners establish communication protocols, and the work will begin.
When the first engagement is well underway, the relationship enters the Symbiosis phase, in which the teams on both sides optimize the working relationship for maximum effectiveness and efficiency. This phase might be very short if you have chosen your partner correctly; or it may take a considerable amount of time, and may include changes in personnel or roles, to get the relationship working well.
Finding, qualifying, and achieving a symbiotic and productive relationship with a partner company is a big investment. The best companies follow-on with a Leverage phase to find additional areas in which they can use the same partner for other valued contributions or for other projects. Note that the figure above has a dotted line indicating that engagement with the partner may wax and wane as projects start, end, or enter different phases. This variation is normal and healthy, providing your company with valuable flexibility.
Finally, there may be a Disengagement phase that can occur for a variety of reasons: Perhaps the next set of projects does not require the expertise of the partner, or your company decides to bring the partner’s core capability in-house, or there is a business change or dispute, etc. In most cases, there is a wind-down period; although in other cases it may be a very sharp cut-off of communications between partners.
Or it may be that there is never a disengagement phase, if it is truly a long-term symbiotic relationship. An example is the decades-long partnership between Hewlett-Packard and Canon to co-develop LaserJet printers.
Roles and Responsibilities in Partnerships
Working closely with a partner is seldom handled by just one person in your company. Much more often there are multiple people involved on both sides, leading to ample opportunities for mixed or crossed signals. The following are some typical roles, assuming a project or program that involves internal resources as well as one or more partners:
- Project Manager (PM): Responsible for the main deliverables, budget and schedule of the overall project.
- Partner Procurement Specialist (PPS): Responsible for the qualification, contracting and business management of the partner.
- Technical Lead (TL): The senior technical architect of the product under development – in some companies she doubles as the project manager.
- Functional Manager (FM): Manages a group of technical specialists, such as electrical engineers in companies that produce hardware.
- Executive Partner Manager (EPM): This person is usually a high-level executive manager (Director or VP of Engineering, for example) who has a side-job of acting as an overall executive contact to one or more key partners.
- Legal or Contracting (LC): Responsible for drawing up and possibly enforcing the legal terms of the contract.
Using a Modified RACI Chart to Clarify Roles
The roles and responsibilities of these titles vary depending upon the phase of the partner relationship. An excellent way to clarify all of the roles involved in a partnership is to use a modified RACI diagram, like the one below. In this figure, the roles are printed along the vertical axis and the major process responsibilities for a hypothetical company are written along the horizontal axis.
Wherever the roles and responsibilities cross on the matrix, you draw one of three types of circles or dots. A solid circle means that a person in that role has the lead role for the task in question. A hash-marked circle means that the person in that role is heavily involved in the process, but not in the lead. An open circle means that the person is informed, but not necessarily involved in decisions regarding the task. No circle means that the person is neither generally involved nor informed.
It is best practice to have one and only one person or group in the lead role for each major responsibility; situations where there are shared leads often result in conflicts. The stakeholders in your company should get together, list your major process responsibilities, and decide for each task which roles are in the lead, heavily involved, informed of what’s happening but not involved directly, or neither involved nor informed. It is important to have full agreement and buy-in from everyone concerned.
In many companies, the Functional Managers often take the lead in scanning and finding potential partner companies. They have the best combination of technical depth, awareness of the suppliers, and business maturity to develop the short list of contenders. After that, the leadership of the qualification process is handed-off to a Partner Procurement Specialist (PPS).
The Role of the Partner Procurement Specialist
The PPS takes the lead in training all employees who interface with the partner including their roles and responsibilities, accountabilities, and communication protocols. Early training and role definition by all team members can avoid much confusion and miscommunication during the project.
Also, the PPS leads the Qualification phase using the Functional Managers and Technical Leads to examine the partner’s technical capacity and capabilities. The PPS examines the partner’s business essentials, including the potential partner’s size, stability and track record. Many companies have a back-up partner in case the chosen partner fails to deliver or something goes wrong with the relationship.
Boundary Conditions: An Agreement Between Partners
At the beginning of each project, an agreement between you and your partner creates key parameters, boundary conditions for the project. These conditions define approximately five key aspects of a project. These include parameters like:
- Product Cost
The partners agree on quantitative measures for each boundary condition. For example, the boundary condition for the release schedule might tie to a trade show. These conditions bind the project to key success factors and set expectations. They quantify the project’s goals and, taken together, they measure its success. If the project meets these quantitative targets, then you have a clear way to measure the effectiveness of the partner.
Partners Empowered to Innovate
If the development partners foresee that they are on track to meet the targets, each partner minds their own business. Development partners are not harassed with requests for status updates and are free to innovate and use their own processes to get the job done. On the other side of the partnership, management can have confidence in the direction of the project, having defined with care its broader goals.
When the Boundary Conditions are Broken: Out-of-Bounds Review
If the partner perceives that they aren’t likely to hit the target – this is called “a boundary break” – then it is their responsibility to inform you which boundary or boundaries are likely to be broken. This triggers an out-of-bounds review (OOB), which is an escalation process, a means of resetting projects with a minimum of time wasted.
If the development partner perceives that there will be a boundary break, it sends a communication proposing a solution to the break. If you concur with the partner’s solution, then each side comes to an agreement around a new quantitative measure for the boundary condition(s) in question, and the project goes forward on that basis.
If you do not agree with your partner’s suggested solution to the boundary break, then that triggers a face-to-face meeting where the agreement is renegotiated. The partners will then agree to new boundary conditions, create new metrics, and move forward with these revised measures of success as the new baseline.
Keep Projects on the Boil
It is extremely important for you to respond immediately if your partner says a boundary break is likely. The out-of-bounds process, where you come to an agreement on new boundary conditions, should take hours or days, not weeks or months. Projects that are near an impasse because there is no clear escalation path are in deep trouble. The boundary conditions and out-of-bounds review approach is intended to keep projects on the boil.
After the out-of-bounds review is complete, the partners continue as before, assuming that the new agreement re-establishes the project’s targets. This ensures that partners aren’t micromanaged, while providing a simple escalation process for projects that stray from agreed upon bounds.
Getting The Details Right
The boundary conditions approach depends on getting roles and responsibilities right. For example, get clear on what subset of management oversees the partner. The process champions also have to define who gets informed when there is a boundary break.
Partners might also negotiate what exactly constitutes a boundary break, and the timing of communications around them. It is also important for the partner to understand that it is their responsibility to propose a solution in the event of a potential boundary break.
Partner Management: Competitive Leverage Point
Empowering partners, while managing to precise targets, is a challenge for many management teams. It requires a cultural shift in organizations where hands-on management likes to meddle.
For example, we had one client that insisted on weekly status meetings (in this case with their internal teams) even when it was clear that the team was well within bounds. There was no need. Why waste time meeting for an hour (plus prep) to explain to management that the team is proceeding as promised? Pure time waster. It’s the antithesis of lean and agile product development.
Defining roles and responsibilities using the modified RACI chart, and creating boundary conditions for your projects, eliminate waste and churn, freeing up a well of resources. Partners working to clear and defined specs require less managerial time and effort on your part. If projects start to go awry, there’s a relatively blame-free, pain-free way to set them back on track by focusing on quantitative goals that remain objective targets. This empowered approach improves relationships between partners.
Few companies manage dev partners well. It’s an area where you can grab an advantage, with a bit of planning, and a lean approach to developing apps with partners.
– John Carter, Founder, TCGen Inc.
What Agile Software Development Team Structure Looks Like#Dedicated teams
When partnering up with the software development team, many clients discover that quite a few people belong to its structure. And while it’s pretty clear with the responsibilities of developers, things tend to get confusing with BAs, PMs, and POs.
In this article, we’re going to explain to you how software development teams structure their work, what are the roles and responsibilities of each team member, and how to know whether your team is doing a good job with your product.
Three approaches to product team structure
Let’s start with the basics. There are several ways to go about the arrangement of an agile software development team – generalist, specialist, and hybrid.
A team that consists of individuals with broad skill sets and expertise is called the “generalist” one. Such teams are usually responsible for the end-to-end development of the whole project or individual feature. It’s the most common project team structure for outsourcing companies.
Generalist approach pros
- Every team member has a good understanding of the product so they can focus on improving it as a whole.
- Each person is competent enough to complete their work without dependency on others.
Generalist approach cons
- Since nobody has a specific knowledge, it’s sometimes necessary to onboard a new team member in the middle of the project.
A “specialist” product team structure involves experts with super-specific skill sets who are proficient in handling narrow tasks. Everyone is a pro is one’s niche and therefore is fully responsible for their element of the project. Such an arrangement is also fairly common for software development teams.
Specialist approach pros
- Profound knowledge of every project elements.
- The team can build complex high-quality systems very quickly.
Specialist approach cons
- Since everyone is working individually, there is a possibility that the components won’t fit from the first iterations.
- There might be communication gaps due to the lack of general knowledge.
A “hybrid” project team structure is basically a combination of generalists and specialists. Such teams work on a project as a whole but they can narrow down their focus whenever necessary. The hybrid approach is by far the best of both worlds.
Hybrid approach pros
- There are both specialists who build separate components and generalists that make sure that the system is integrated.
- The development process is maximally effective.
Hybrid approach cons
- It may be difficult to coordinate people with different approaches to workflow.
- Building a hybrid team is time-consuming and very expensive.
Typical software development team structure
In the ideal world, everybody would have a handful of generalists and specialists in-house and they would get on very well with each other. But the reality is that every business has limitations – time and budget. That’s why most outsourced software development teams are generalist ones.
So who exactly makes up these teams? Let’s go through the key positions.
- Business Analyst (BA)
This is someone who is responsible for formulating goals, analyzing and documenting the core processes and systems, and ensuring the alignment of business model and technology. BA is all things for everybody. They evaluate what works and what doesn’t work and set the direction for business development.
- Project Manager (PM)
This person is in charge of planning and execution. PM is responsible for getting things done. They also take care of building relationships among the client and various organization departments. PMs oversee all the processes, delegate the tasks among other team members, and ensure that everyone stays on track.
- UX Designer
This is someone who designs the way users will interact with the product. They ensure that all the features solve people’s problems and fulfill business goals. Namely, they determine how the product will look and how it will work. The main focus of a UX designer is functionality and usability.
- Developers (Front-end/ Back-end)
These are the people who do the actual coding. Whereas front-end developers work on the customer-facing elements of the product, back-end developers take care of its functionality, which is everything the user doesn’t see.
- Quality Assurance Engineer (QA)
This is someone who tests the product to make sure that it works well, meets the quality standards and client requirements. QA is like a final editor with meticulous attention to the smallest detail. They detect errors and bugs early on so that the team can fix it before it gets to the users.
Hire remote Agile team
Boost your development capacity, fit in a tight schedule, and spend no time on local hires by leveraging a dedicated Agile team.Learn more
How is the Agile software development team structure different?
On the surface, Agile team has a few more extra job roles. But let’s recall the Agile Manifesto for a second.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The core difference between the traditional and Agile team structure is in the way people cooperate with each other.
Traditional team vs Agile team
|Traditional team||Agile team|
|Top-down project management. The project manager is responsible for getting things done.||Self-organized and self-managed team.PM’s role is to coach the team, remove obstacles, and prevent distractions.|
|Teams may work on several projects simultaneously.||Teams focus on one project at a time.|
|An organization evaluates individual performance||An organization evaluates team performance|
|Distinct roles and job titles.||Cross-functional teams, skills matter more than titles.|
|No team size limits.||Three to nine people per team.|
|Employees are referred to as human resources.||Employees are referred to as talents.|
Roles and Responsibilities in the Agile software development team
Product Owner (PO)
PO is usually a key stakeholder of the project. This is someone who has profound knowledge of the user and the product and is responsible for the internal side of development. Their job is to make sure that the final product/ service meets the client’s needs. PO keeps an eye on the team, supports and coordinates their work, and ensures that all the product requirements are met.
First of all, let’s define Scrum. It’s a methodology that helps agile teams self-organize and adapt to changes following the Agile development principles. And Scrum master is a process owner who coordinates the team’s work. He facilitates and master manages everything that’s going on the team.
It’s a group of in-house or dedicated developers that work on the project together. Similarly to a traditional team, the Agile development team includes front-end/back-end developers, UX designers, and QA testers. They work on the product in close cooperation.
Characteristic of an effective software development team
Not a single outstanding product was ever built by a mediocre team. So the greatest challenge of every organization is to ensure that their people and motivated to perform to the best of their abilities. And while pretty much everyone can find skilled employees, not every organization manages to create empowering collaborative environments for their teams to thrive.
How to tell that your team is effective? Look for the following traits.
- They communicate well. Communication is always at the heart of teamwork regardless of the industry, and software development is no exception. In great teams, people have all the necessary tools and processes for regular healthy communication.
- They work for a common goal. Great teams don’t need strict top-down management. They have clear goals and a shared mission. In such environment, the success of the team is perceived as the success of each individual.
- They have well-defined responsibilities. Whereas the team shares a common goal, every person knows exactly what they need to do to make the whole thing work. The expectations, roles, and areas of responsibility are defined from the start and people hold each other accountable for making progress.
- They have a strong culture. Having a strong culture means developing professional bonds, supporting and respecting each other, and feeling comfortable in each others’ company. Such teams enjoy spending time together both at work and outside the office.
- They don’t need to be controlled. Top-down management is slowly becoming a thing of the past because great teams with common goals and shared vision don’t need to be pushed. They do their job well because they want to, not because they are forced to do so.
All in all, it’s not enough to hire people and get them in one room. Teamwork is complex. It requires the knowledge of software development team structure and a certain degree of understanding of how software development works. Here at Relevant, assembling dedicated teams for our clients is our specialty. Check out some of our case studies for more details.
Documents in Software Development Outsourcing You Absolutely Have to Know About#Product label
So, you decided to outsource software development. Congrats! But how can you make sure your product is protected? And how do you establish the terms of the partnership? The short answer is with the help of documents like NDA, MSA, SOW, and DPA. Taking your time to prepare these documents will help you establish the required terms, specify the responsibilities, the rights, and other collaboration terms.
Key Documents in Software Development Outsourcing
Let’s take a look at the basic documents for software development outsourcing. We will also define the key terms that can often be confusing or misleading. This will help you arrange a business relationship that is safe for both parties.
Non-Disclosure Agreement (NDA)
One of the primary documents at the initial stage is a Non-Disclosure Agreement or NDA. This agreement is signed if two companies (or a company and an individual) are going to exchange sensitive information. An NDA is signed to protect this information from being disclosed.
An NDA should contain the following:
- A clear definition of confidential information. All materials have to be determined as confidential or non-confidential. Information like processes and procedures, development strategies, passwords, customer databases, architecture, prototypes, source code are usually confidential.
- Confidentiality term. Make sure to determine the time frame for keeping information confidential. The period has to be long enough to keep your business safe but not too long not to scare away the other party. The confidentiality term usually varies from one to three years in the software development and outsourcing business.
- The disclosures/representatives clause. You should explicitly state with whom the confidential information can be shared. Are these people employees, business partners, freelancers? Don’t forget to include them in the NDA.
- The use of confidential information. It’s important to indicate how sensitive information can be used.
- Legal obligations to disclose. Any NDA is written to protect information disclosure. However, sometimes, it is required for legal proceedings or, in other cases, determined by the valid legislation.
- The return or destruction of confidential information. This section determines what each party should do with sensitive information after the collaboration is over. Consider all information bearers: USB storage devices, CDs, copies, hard drives, servers, and so on.
- The remedies clause. It indicates how a party that breaches the NDA should compensate for the disclosure of sensitive information.
Master Service Agreement (MSA)
A Master Service Agreement is signed if a company is going to work with a client repeatedly. This agreement allows to reduce legal expenses and facilitate the provision of services. Make sure to include the following clauses:
- Provision of services. The order of providing services.
- Acceptance and payment for services. The fees, taxes, timesheets, and other things related to the procedure or services acceptance and payments.
- Term and termination. The time frame during which the MSA is valid and the conditions when it can be terminated.
- Intellectual property rights and ownership: What intellectual property is and how it can be managed.
- Confidentiality. What confidential information is and how to handle it.
- Liability, warranties, representations. Party warranties, liability field, and representations (persons involved in the project: employees, partners who will be participating, etc.).
- Indemnification. The parties agree on how they are going to indemnify any harm if caused to each other.
- Notices. How the MSA will be delivered and which delivery notifications you are going to receive.
- Miscellaneous. Disputes and their resolution, data protection, governing law, benefit, assignment, amendments (indicate that there should be no amendments or modifications without being signed by the mentioned party), the severability clause (if any provision of the agreement is unenforceable, it doesn’t cancel the enforceability of other provisions of the agreement).
Statement of Work (SOW)
A Statement of Work is one of the most crucial documents in the software development business. This is where parties identify the details connected with the project, describe project stages, the features, acceptance criteria, risks, and so on.
In the SOW, you should provide a CI/CD pipeline diagram, the schedule of development procedures (visits, communication within the project, approval, objection, reporting procedures and order, deploying, and closing the project). A Statement of Work should additionally include details like the list of devices, screen resolutions, browsers, and their versions used for testing purposes.
In a special attachment to the Statement of Work, you can indicate information related to payment and payment models. Here, mention whether it is a fixed-price project or the company will pay for the time and materials applied. It’s also important to indicate the force majeure conditions, major risks, and their influence on the implementation of the current task or scope (not the entire project).
DPA (Data Processing/Confidentiality Agreement)
DPA, or Data Processing Agreement, is intended to regulate data processing by the parties as well as the relationship between the parties. It is an agreement between the data controller and the data processor. In the case of outsourcing, the contractor is the data processor, and the client is the data controller.
During software development, the vendor has access to the databases with customer data, processes, and stores it. That’s why it’s essential to agree on how this data is going to be stored, processed, protected.
Many companies ignore this document, but this is not our case. At Relevant Software, we have developed our own Data Processing Agreement template according to GDPR.
Details to Pay Attention to When Signing a Contract
The final and most crucial negotiation stage is the signing of the MSA and the SOW. These documents finalize the things that haven’t been settled for now. Let’s take a look at the typical contracts signed by vendors and the details you should pay attention to.
This kind of contract is the best option for smaller projects. With it, the software requirements are strictly defined. Fixed-price contracts work perfectly when the client needs to develop a solution but doesn’t have the capacity or in-house resources. The vendor guarantees to deliver a particular solution based on the client’s expectations within a set budget and is entirely responsible for the project results.
This contract type is not flexible, so it’s not frequently signed when it comes to software development. But if you are going to sign this kind of contract, determine every project detail. Make sure you agree on the pricing, the deadlines, the budget, and everything else that might be important.
The Dedicated Development Team Model
This is an optimal solution for a long-term project where the client hires a team of developers, pays a monthly fee, and manages the team.
Being an extensively flexible model, it allows adapting to changes rapidly. And based on our experience, we can assure you that the dedicated development team contract is the most efficient for software development projects.
The Time and Materials Model (T&M)
The time and materials contract requires payment based on an hourly rate. This contract is signed when the client needs a specialist to work on a project for a particular time. This contract type guarantees the transparency and the cost-efficiency of any project.
Clauses of Outsourcing Contracts You Can’t Ignore
Payment is a critical notion that has to be discussed at the very start of the negotiation. You have to be very clear about how much, when, and in what way the billing and the payments are processed. If a retainer is needed, it should also be indicated in the agreement.
In many cases, if a payment isn’t made on time, the vendor might stop providing services. It is inconvenient for both parties and can be avoided if all the details are defined clearly.
Liability & Warranties
Liability clauses are of particular importance in any IT outsourcing contract because they determine the extent to which both parties bear the responsibility. Make sure you check the liability cap: with it, parties mutually limit the liability of each other to some extent.
The liability cap helps to manage risks and control the financial exposure of a business.
The warranty clause is usually provided in a fixed-price contract. Within this clause, the vendor guarantees that products will be delivered within the deadline, and based on the client’s requirements.
A notice period is the time frame given to make changes in the development team. Notice periods influence the project’s smoothness and the quality of its implementation.
There are two main kinds of notices:
- The first one is connected with scaling the development team up and down. In this case, the notice period might vary from one to three months.
- The second one is connected with the termination of the contract. This notice is crucial for a vendor to organize all the processes efficiently. Usually, it varies from one to five months for shorter contracts and from six to 12 months for longer contracts.
Confidentiality and Data Protection
In the contract, you should determine the data protection matters within the enterprise. Software outsourcing companies usually have high standards for the protection of sensitive data. Security control and policies have to be established and followed. The company should perform regular audits to make sure that all the procedures comply with the accepted standards.
Intellectual Property Rights
The contract should clearly state that the client is the owner of all the intellectual property that has been created during the project. If the payment has been delayed or wasn’t made, the vendor has the right to use any intellectual property that was not paid for.
In this clause, you should define the fees the client pays if they hire the vendor’s specialists. The same applies if the vendor’s employees are hired by a third party.
A vendor spends a lot of resources to find, recruit, train a specialist. That’s why, if the specialist goes off to another company, the vendor should be compensated for it.
Another option is to agree on the conditions of how this collaboration will evolve.
In software development outsourcing services, the client and the vendor are located in different countries. So, it’s important to determine and agree upon the jurisdiction location in advance.
Finding an excellent software development vendor is hard. But considering all the collaboration details and arranging them into an exhaustive agreement that satisfies all parties is even harder. If a contract is poorly written, it might lead to a number of misunderstandings and issues that might influence the collaboration.
Take your time to prepare the documents. Make sure that your contract satisfies both parties, there’s an NDA, an SOW, and a DPA. They provide assurance in the vendor and guarantee that the product will be delivered on time according to the requirements. And if anything goes wrong, the parties will know what to expect and how to resolve the dispute.
Here at Relevant Software, we have the templates for all these documents. All our clients have to do is enter their contact details, and the documents are ready to be signed.
Statement of Work (SOW) in Software Development: Everything To Know#Product label
Let’s imagine that you finally picked a qualified outsourcing company with a dedicated team of software developers. You might be sure that the vendor you’ve chosen is reliable. Still, wouldn’t you want to make sure that a company you’re hiring has an understanding of your expectations before they start working on your project? If your answer is “yes” or “absolutely,” then keep reading to find out how to secure a successful collaboration and why Statement of Work (SOW) in software development plays such a crucial role.
What exactly is SOW, and why is it necessary for productive partnerships with IT-firms? Basically, it’s a document that clarifies every aspect of your contract with another company, including schedules, terms, work standards, payment method, as well as acceptance criteria for deliveries. As a matter of fact, a high-quality SOW should cover every critical point of the work. So, what exactly should this document include? Let’s take a closer look.
Purpose of Statement of Work (SOW)
Before starting a project, every party must make sure that they understand methodology, objectives, deadlines, payment, responsibilities, and requirements.
Statement of Work (SOW) in software development is a business document that covers every nuance of the agreement between the client and an outsourcing company to boost cooperation and minimize the chance of conflict or confusion between organizations.
Aside from the scope of job, schedule, project’s objectives, standards, and success definitions, SOW may include other miscellaneous information, like security considerations, hardware and software restrictions, post-project support, penalties for late or poor-quality deliveries, and clauses to terminate the contract early.
Although SOW is usually considered more of a business document than a legal one, you shouldn’t underestimate its importance because it defines the full extent of your collaboration with an outsourcing company. Therefore, SOW should be explicit, clear, and written in an understandable language, leaving as little to interpretation as possible.
Who Should Write the SOW
In software development, SOW is typically created by an outsourcing vendor. What makes this method conventional in the industry is the fact that software devs can write SOW with detailed project information and as a part of the documentation package. It’s difficult to find a writer qualified enough to understand the specificities of your contract. However, IT-company responsible for the project development is far more likely to compile a quality document promptly to give to the client.
At Relevant Software, we follow our custom SOW template and provide our clients with in-depth and comprehensive SOWs that include all necessary information for effective partnership.
What’s included in the SOW for software development projects
As a rule of thumb, the more information Statement of Work contains, the more chances the customer’s needs will be met in the most time- and cost-efficient manner. Formats may vary based on vendor, but the majority of SOWs adhere to proven guidelines where content is divided into the following sections.
Start by stating an objective and a list of parties involved in the project. It’s important to indicate the date and location of drafting the document to avoid concerns about its credibility and legitimacy.
Purpose (What is it?)
This section must state the goals of the project and the objectives that the client wants to accomplish. A clear understanding of the client’s expectations will increase the effectiveness of collaboration with your organization.
Scope and Description (What is going to be done?)
Given the complexity of this chapter of the SOW for software development, it’s more efficient to outline the project into several steps, like “project discovery phase,” “application development,” and “testing phase.” Then, these steps should be divided into extensive and comprehensive tasks, which you may want to further break into phases if the complexity of the product calls for it.
Upon reviewing, make sure that the Scope and Description section identifies the following information:
- General budget overview.
- Expected deliverables.
- The individual tasks.
- Phases of certain tasks.
- Responsibilities and roles of each party, including figures accountable for configurations and software input, supplied information, security, as well as approval of system maintenance and performance.
- Appointed project managers, representatives of each organization, and other key figures.
- People with an authority to accept the completed product provided by a software developer.
- Conditions about possible force majeure or issues in functionality implementation.
- Specifications and limitations for subcontracting development, and the company responsible for the quality of subcontractor’s work.
- Requirements or certifications for developers or sub-contractors.
Location of Operations (Where will it be done?)
When hiring an outsourcing company for software development, you can gain access to a worldwide pool of talented and vetted engineers. It means that some vendors can work for you from various countries with different jurisdictions. Therefore, it is essential to list facilities where the programmers operate from and time-zones under which they operate. If a customer wants to have real-life meetups with a vendor’s representatives, the SOW must specify the locations where meetings can take place.
Standards (How will it be done?)
If the Scope and Description sections are all about the nature of the project, this part of SOW is all about the process of operations, which includes the following information:
- Technological limitations (coding languages and platforms).
- Industry standards software dev should stick to.
- CI/CD pipeline diagram.
- Information about the testing of the product, involved parties, and necessary hardware or software.
- List of accepted devices, screen resolutions, and browsers for the testing process.
- Means and tools for communication between the client and the outsourcing vendor.
- Procedures for minor and major order changes.
- Penalties for late deliveries and bonuses for extra labour.
Deadlines and Schedule (When is it going to be done?)
I think you would agree that development shouldn’t be rushed. However, having a set of deadlines and tight timetables can improve the product’s quality and give the project more flexibility. Having a thorough schedule helps to keep the project moving forward with some room left for trial-and-error or potential issues during development.
Therefore, every SOW must state a start date and timeline for the project. To streamline the development, both sides need to have a detailed list of tasks and milestones with set dates of deliveries. Furthermore, the documentation should set a timeline for routine reviews of performance.
This section should also specify the contract’s duration, which measures by date or by a specific period. Additionally, this section may include the maximum weekly or monthly payable operating hours of the software development team.
Monitoring (How to control it?)
As mentioned above, the SOW should state deadlines for performance reviews if a company wants some control of the development. The software development vendor must adhere to his responsibilities and give regular reports. Companies can also implement management software. Some of the most popular applications for supervising and reviewing operations are Jira, Basecamp, Asana. Although all tools and applications for management should be clearly stated in the agreement.
Acceptance Criteria (How will we know the job is done?)
The document must clearly define success and failure, which means it should cover what criteria constitute successfully completed deliverables the client should accept and pay for. Also, it should include circumstances under which the company can terminate the agreement without paying the full price. A detailed description of the features’ acceptance criteria will also help to cover the risks of change requests.
Additionally, Statement of Work should include an attachment with information about the process of submission, as well as people authorized to review and accept deliverables.
Contract Mode and Payment Model (What does the payment process look like?)
After reaching an agreement about preferred payment terms, companies must outline them in as much detail as possible.
In software development outsourcing, there are usually two price models that vary based on the scope of your project:
- Fixed-price contracts are best suited for companies who have a detailed plan, strict delivery dates, and defined requirements. This model also fits smaller projects. With this type of contract, the vendor usually takes full responsibility for the results, but your project compromises flexibility. Payment is typically set up by schedule, or after reaching certain milestones or deliverables, or it can be conducted as a single-sum when the job’s done.
- Dedicated development team model is appropriate for long-term or complex projects with a non-identified scope, which can involve rapid changes during development. It’s a more efficient type of payment for both parties because it allows for shifter requirements adjustment, feature replacement, and allows the customer to effectively manage and monitor an engineering team. The client typically makes monthly payments based on hours programming team devotes to work.
Miscellaneous (What else should we clarify?)
Are there some questions left that you find useful for your collaboration that doesn’t suit the categories mentioned above? Some of these questions can be specific to your project and can include:
- Questions about security regulations and standards.
- Travel payment (in case a real-life meeting is needed).
- Details about code ownership.
- Composition of the engineering crew and program evaluation team.
- Post-completion support, communication with clients, and further testing.
- Final admin duties (how and where the document will be signed).
- Estimated effort level.
- Liability cap and warranties.
- Timeframe for applying changes in the engineering team composition.
In essence, the Statement of Work (SOW) is one of the pillars of collaboration between the client and a software development company. It provides both parties with planning, methodology, and, most importantly, clarity and understanding of the work that’s to be done. We would even go as far as to call it an essential document that can separate a successful collaboration from a failed one.
We at Relevant Software have supplied more than 200 organizations from over the world with dedicated teams of vetted engineers. In addition to outsourcing developers and creating products from the ground up, we managed to outline over 100 SOWs for our customers. If you are interested in our expertise, you can take a look at our cases.
How to Write an NDA for Software Development [Template Included]#Product label
NDA stands for a non-disclosure agreement. This document ensures that when you share your proprietary information (ideas, trade secrets, etc.) with another person, they will keep it a secret. In terms of software development, a non-disclosure agreement is usually signed between a client (a company owner) and an outsourcing company before they enter into a business relationship.
There are two types of an NDA: unilateral (only one party agrees to protect the other party’s information) and mutual (both parties agree to protect each other’s information). Unilateral NDAs are the most popular.
When Should I Ask Someone to Sign an NDA for Software Development?
An NDA for software development is often surrounded by controversy, but there are a few strong reasons to sign this document before sharing any confidential information with third parties:
- To secure your trade secrets. Trade secrets make your business stand out among its competitors. Whether it is your secret ingredients, original marketing strategy, or an innovative manufacturing technique, disclosure may ruin your business.
- To keep your project secret before release. An NDA for software development can also be very helpful when you are working on a novel product, and you don’t want your competitors to be aware of it before its release. Keeping it a secret will allow you to remain the “first-mover.”
- To protect other sensitive information. Even if your business doesn’t have any trade secrets, and there are no revolutionary products under the hood either, an NDA for software development can help you secure your financial, marketing, or other sensitive information.
You don’t always have to sign an NDA, though. For example, if you commission a software development company to build a generic mobile app or a website based on WordPress, the entire legalese thing will only slow down the process. If you don’t have to share any confidential information to complete your project, an NDA is not necessary either.
Look no further. Outsource to us.
Relevant is a software development company from Ukraine. For the past 7 years, we have helped 200+ companies outsource their software development.
Let's talk about your current needs and how we can help you.
What Does an NDA for Software Development Look Like?
There is no single, universal template of a non-disclosure agreement. Nevertheless, any NDA for software development should include the following information.
Parties to the Agreement
If it is a unilateral agreement, Parties to the agreement will include only the Disclosing and the Recipient parties. But there’s a catch: double-check whether you need the Recipient party to share confidential information with their affiliated companies, partners, or agents in order to complete your project successfully. If so, make sure that your NDA covers all of them.
In terms of software development, it is recommended to sign an NDA not just with developers but also with anybody who has access to the source code, mind maps, product features, and other sensitive information. These may include QA experts, designers, project managers, or product managers. It’s critical for outsourced experts to be the only recipients of confidential information. It’s also advisable to sign this agreement with your in-house team.
What Is Deemed Confidential?
This section of an NDA for software development identifies what kind of information is considered confidential. Is it only written information? Is oral information supposed to be kept a secret, too? As the Disclosing party, make this definition as broad as possible to prevent the Recipient party from using any loopholes. It’s essential to clearly identify what kind of information is confidential.
The Scope of Confidentiality
This section is the “main body” of your NDA. It consists of two types of obligations:
- The confidential information must be kept secret. This also means that the Recipient party is expected to take reasonable measures to keep the lid on sensitive information. For example, only certain employees of the Recipient’s company will have access to confidential information (the Recipient party should also make sure that these people are familiar with the restrictions outlined in your NDA for software development).
- The Recipient party may not use the confidential information themselves. This is one of the key reasons behind agreements like this. If you don’t want to wake up bankrupt, make sure that your NDA restricts the Recipient parties from using the confidential information for the purposes not outlined in the NDA.
Exclusions from Confidentiality
There are instances when keeping certain information secret is troublesome for the Recipient party. If the Recipient party discloses such information, they won’t be subject to lawsuits. These instances typically include:
- publicly accessible information
- information already known to the recipient
- information independently generated by the Recipient party without using any confidential information specified in the Agreement
- information disclosed to the Recipient party by another party without any NDA obligations.
Obligations of the Parties
This section of an NDA for software development usually covers the recipient’s obligation to maintain the confidentiality of the shared information and restricts its use. Restrictions might include:
- using the confidential information only for the purposes specified in the agreement
- sharing the confidential information only with persons who need this information to serve the purposes listed in the agreement
- making sure that these persons treat this information in line with the restrictions specified in the agreement
- taking appropriate measures to keep this information secret.
Consequences of Breaching the Contract
Your NDA for software development will be pointless unless you identify the implications of a possible breach.
Typically, the Disclosing party seeks financial compensation – a fixed amount set by the contract. Some include attorneys’ fees and court costs, too, which can be collected from the breaching party if the claimant wins the case. It’s best to avoid unrealistic penalties.
Additionally, it’s recommended to include a few methods of alternative dispute resolution. ADR that allows settling legal disputes out of court is classified into three types:
- Mediation. A neutral person helps the parties find a satisfactory solution
- Negotiation. The parties resolve the dispute themselves
- Arbitration. A “private” court where a neutral person listens to both parties and then finds a solution.
From a business viewpoint, ADR is more efficient than litigation, which is a public proceeding. ADR guarantees that your sensitive information will remain under wraps.
Software Development NDA Template
Creating an NDA for software development from scratch can be time-consuming. To avoid loopholes, you have to consider every single word carefully. But we are here for you to speed up this process.
At Relevant Software, we work with international clients and understand perfectly your urge to keep your valuable business information safe. We have an NDA template that we sign with our clients when building software for them. We can’t share it with you as it is our legal asset, but here is a good one from the Internet.
In software development, you often have to share confidential information with another person, team, or even company. The best way to secure this information is to sign an NDA for software development. With this document, you can protect your trade secrets, as well as financial, technological, marketing, and other sensitive information.
Even though there is no universal template, every NDA should cover the following details: information about the Parties, what information is considered confidential, the scope of confidentiality, the exclusions from confidentiality, the obligations of the Parties, and the consequences of breaching the contract.
If you’re looking for a software development vendor who takes legal documents very seriously, why not contact Relevant Software? We will help you bring your ideas to life, taking care of your valuable information along the way. Success stories of our clients are the best proof of our efficiency and expertise.
Master Service Agreement in IT Outsourcing#Product label
Imagine that you’ve found a suitable IT outsourcing vendor. You have a complex product that requires multiple phases of development, and your companies need to collaborate for an extended time. Maybe you already finished a project with the developer on a high note, and you’re positive about partnering up for next ventures. With the Master Service Agreement, companies can streamline software development by simplifying general contract regulations for ongoing projects, while still being able to make decisions during development.
With MSA, you can make the regulations clearer for both parties in advance to eliminate confusion. It also reduces legal expenses and bureaucracy associated with developing new documentation.
Let’s take a wild guess and assume you’ve already browsed the web for a high-quality MSA template. I wouldn’t be surprised if you didn’t find a good example so far. If so, you don’t need to worry, because below you’ll find the MSA template tailored for outsourcing development organizations.
What is a Master Service Agreement in software development?
Master Service Agreement (MSA) defines as a contract between IT-vendor and a client that outlines project expectations, responsibilities, roles, provided services, terms, and other essential agreements between parties.
What makes this document stand out from other agreements, like NDA, DPA, and SOW? The key difference is in the goal. MSA in software development can help the IT vendor and the client if they plan to work together repeatedly. Do you want to learn how exactly it boosts the firm’s collaboration in the IT field? Stick with the article to find out.
What is MSA needed for?
When a company and software vendor decides to work on a project over a prolonged period, the Master Service Agreement will make the process cleared out. It also helps to cut costs and save a lot of nerves for involved parties by removing the need to renegotiate and re-review most of the already approved conditions. MSA in software development is a complex document that takes a lot of time to draft. However, after sides reach consensus on it, it can be used as a template for the subsequent ventures.
It allows organizations to focus on essential concerns, like goals, objectives, and timetable of a separate project. Additionally, MSA helps software developers (outsourcing companies) and their clients to avoid contractual disputes or potential legal action. It can state who is going to be responsible for failures, unexpected costs, or intellectual damage, thus providing guarantees and indemnification for both sides. If some disputes do arise, meticulously outlined MSA aids in determining the guilty party faster, which helps with the risk allocation.
Given the importance and complexity of this document, your next question can be…
Who provides the Master Service Agreement?
In software development, MSA is usually written by an outsourcing vendor and then given to the client for a review. It’s a typical practice for the industry because software companies specialize in nuances and specificities of the project’s development. Additionally, an outsourcing company can compile a Master Service Agreement with other necessary agreements as a part of a documentation package.
It’s possible for the customer’s team to write the MSA and give it to the software company for examination, but there’s a high chance that the revision process can drag on for far too long. Outsourcing vendors, on the other hand, specialize in working with other companies and have more expertise compiling proper documentation.
For example, at Relevant Software, we have collaborated with more than 200 customers from over the world and provided most of them with all the necessary paperwork, including SOWs, NDAs, and MSAs.
Therefore, an experienced software company can effectively write the first draft of the Master Service Agreement in the course of days instead of weeks, and then present it to the client for examination. Outsourcing firm is also going to be swift with editing and adjusting the document to reach mutual consent faster.
What does the MSA consist of?
Simply put, a high-quality Master Service Agreement must state every important and minute detail to convey business expectations and provide financial guarantees to both parties. It should also be clear and understandable to guide project managers. For that reason, the MSA document is typically structured into the following sections.
Provision of services
After an introduction section with names of the participating parties, official contact information, and legal addresses, comes one of the most critical parts of the document with general conditions.
Provision of Services section of the MSA must contain:
- Overall goals and objectives for future projects.
- Client’s expectations.
- Services provided regarding individual SOW.
- Clauses, fees, and processes associated with order adjustments or SOW changes.
- Regulations for progress reporting.
- Description of the work model and weekly working hours standards with reference to the time zone under which the outsourcing agency operates.
- Rules and limitations for solicitation with other contractors during software development.
- Guarantees of independence for the IT vendor and the employer.
Payment and acceptance of services
There are three main methods of payment in software development:
- Fixed price method. Preferred method of work for projects with detailed plans and presupposed delivery dates. Payment is usually tied to milestones, completed tasks or phases, or it can be made as a one-time fee after employ accepts the product.
- Time and Materials (T&M). Suitable for flexible products with unidentified scope. In this contract model, the employer covers the costs of the materials and pays for actual hours engineers devote to work.
- Dedicated team model. Best payment type for multi-layered and complex products where the client can effectively manage the core development crew. The customer pays monthly based on the developer’s hourly project input.
MSA covers the acceptance process for the provided services, the causes for rejecting the work, or demanding a modification and revisions. The fees, taxes, timesheets, and causes for unplanned expenses compensation, as well as payment transfer methods, also go into this section.
Management and monitoring of performance
Individual projects should have the involvement of each side in operating processes and performance monitoring described in a separate SOW. However, the Master Service Agreement can mention the overall managemental structure of software development. Companies may even create a Management Guide attachment with the clarification of their administrative roles.
Terms and clauses for termination
Individual projects have their own deadlines and timeframes. The Master Service Agreement, however, states the duration of the developer’s and client’s partnership. MSA also describes causes under which a contract can be terminated prematurely. Alternatively, the document can establish an automatic renewal procedure if both sides deem it desirable.
Intellectual property rights and ownership
This MSA chapter lays out what results of work on projects under individual SOWs fall within the intellectual property and who retains ownership, copyrights, and other rights, associated with the contract deliverables. It also specifies which data and materials need to be delivered or transmitted to the customer. Meanwhile, the paper needs to state which software, inventions, technology, and data developed prior to or during collaboration, belongs to the software company.
To ensure the protection of data that became known during the collaboration, the agreement must clearly state what information should be considered confidential and is no subject for disclosure to public or third parties. The MSA needs to clarify if the software development vendor can refer to his partnership with the employer in advertisements.
Liability, warranties, and representations
Section that sets liability limitations. Usually, both sides aren’t responsible for indirect or consequential damages. However, if exceptions are made, then they should be listed in the MSA. Furthermore, the agreement lists employees and participating partners who assume the risks for operational incidents that lead to direct losses.
In case the client or software company fails to comply with the Master Service Agreement, which leads to the monetary losses, data breach, copyright infringement, or reputational damage, the contract explains how the responsible side compensates such harm. Additionally, it should mention exclusions from indemnities.
Communication and notices
To stay in touch during development, the MSA must state the representatives of each side, their preferred methods, and tools for communications, locations chosen for real-life meetings, as well as the process of receiving official notifications.
For example, the agreement can establish the process for delivering the MSA and its revisions. It can also cover the procedure of approval or rejection of the deliverables.
The paper can have other conditions that don’t fit the sections addressed above. However, if organizations consider them necessary, your MSA can also provide the following information:
- Disclosure about data protection.
- Governing laws and jurisdiction.
- Procedures for minute amendments to the documents.
- Clauses for severability of the agreement’s provisions.
- Revision process for deliverables, as well as the set review periods.
- Arrangement for post-production support and testing of the product.
Proper Master Service Agreement provides guidance for the IT outsourcing company and employing organization, forms the basis of their relationship, and streamlines future agreements.
Relevant Software provides software development services exclusively under MSA. Therefore, our company is very meticulous with documentation preparation to ensure ours and our client’s mutual satisfaction.
If you found our template useful and your company is interested in IT outsourcing services, feel free to drop us a line.
Things You Should Know About Data Process Agreement (DPA) In Software Development Outsourcing#Product label
In spring 2018, the European Union enforced a regulation that affected virtually every business dealing with the personal data of EU citizens ‒ the General Data Protection Regulation (GDPR). Under this legislation, every country-member of EU, as well any other country processing personal data of EU citizens must take serious measures to ensure its protection. A major component of GDPR compliance is signing a data processing agreement (DPA) between data controllers and data processors. What does it mean and how it applies in software development outsourcing? That’s what we’re going to talk about in this post.
What is DPA?
According to the European data protection law, personal data of EU citizens can be processed by another party outside of the European Union provided that they sign a legal agreement that regulates this processing. That’s what they call DPA ‒ Data Processing Agreement.
A data processing agreement (DPA) is a legal document signed by the controller and the processor either in written or in electronic form, the purpose of which is to regulate the terms and conditions of EU citizens’ personal data processing. Personal data means any information, with the help of which it’s possible to identify a person, i.e. first name and last name, date of birth, place of residence.
The aspects the DPA covers include:
- scope and purpose of data processing;
- what data is processed and how it should be protected;
- the relationship between the controller and the processor, and more.
Who is a data controller and data processor in software development outsourcing?
The data controller is the person or company that determines the conditions for data processing. In software development, it’s a client. A data processor is a person or company that processes data on behalf of a controller, in accordance with the controller’s instructions. In outsourcing, it’s a contractor.
Now, let’s take a closer look at how it works in Ukraine. Although we don’t belong to the European Union, all the regulations and directives of GDPR become applicable to our companies as soon as we come in contact with EU citizens’ data. It’s super common for IT outsourcing. Here’s an example.
Supposing, an IT outsourcing company X gets an assignment from an EU customer to develop some data management app for a healthcare facility. Clearly, they need access to patients’ personal (and sometimes sensitive) information. Even if they aren’t going to store it on any device, it still falls under the “personal data processing” category.
According to the GDPR, the organization that defines the purpose of data processing (i.e. the controller) has more legal obligations, but how the EU customer and the outsourcing company are going to protect this data becomes the responsibility of both parties ‒ the EU company that needs to get the app done and the outsourcing company that requires data to finish the project.
What happens after you sign the DPA with your EU customer?
It’s likely that your customer, who is also a data controller, will just tell you what to do. Also, you as a data processor would have to take all the organization’s measures and follow technical requirements spelled out in the DPA. In some cases, controllers might require a processor to pass some certification or develop corporate rules to be approved by EU regulatory agencies. However, there’s a very slim chance it’s going to happen because there is no standard GDPR-based certification yet, and all the available options are too complicated.
Why is DPA important while outsourcing?
If a data controller wants to outsource some data processing activities to an overseas contractor, they have to prove that their non-EU based partner is GDPR-compliant and can guarantee sufficient levels of data protection. That’s why signing a data processing agreement (DPA) is crucial, especially in software development outsourcing.
Regardless of the purpose of a software product, an outsourcing company develops code, through which they process data of their clients’ customers. Also, even if they aren’t storing any data, they have access to a database. That creates a need to agree on terms of how this data is protected, processed, stored and used. So, yeah, DPA is basically the outline of the conditions of the cooperation.
What to watch out for when signing a DPA?
When it comes to signing a DPA, there are a couple of things to be mindful of, such as:
Are there enough guarantees?
According to the GDPR, a controller may be held responsible for data breach even if it happened on the side of the processor. Therefore, it’s in the best interest of both parties to make sure that the processor has the bandwidth to provide decent protection to all the data transferred to them from the controller. The smaller the risks, the better. However, in case the breach takes place, the data processor should be able to take immediate measures to minimize its effect.
How the processor will use the data?
The data controller has to ensure that the range of the processor’s DPA doesn’t exceed the original legal basis for data processing. In other words, the outsourcing company should only be able to use data for purposes spelled out in the agreement. It’s the controller’s responsibility to check how the processor will use the data they transfer to them.
Is there any room for interpretation?
… because there shouldn’t be any. The text of a DPA should be straightforward and specific. For example, if the controller is going to audit the processor, all the details of the procedure must be specified. This will help to make sure that the processor and contractor are very clear with the expectations and that there are no weak spots in the agreement.
Relevant Software’s DPA template
Although GDPR has been around for a while, very few software development vendors have a DPA template. Those that don’t have it are technically not GDPR compliant. Also, the lack of a DPA template significantly slows down the cooperation process because it forces the client to worry about the legal issues more than about the actual software development.
Here at Relevant Software, we respect the time of our clients. That’s why we’ve developed a legal DPA template specifically for software development services. When starting a collaboration, a client should just fill in the details and we’re all set.
What Happens After Signing an MSA: Client Onboarding Process at Relevant#Product label
Need more developers but have second thoughts about outsourcing?
Being uncertain is absolutely normal, especially if you’ve never worked with a software development agency before.
As a software development services vendor, we understand the importance of transparency. And we believe it’s our responsibility to inform you about every step of the process and help you achieve your business goals.
Here at Relevant, we are convinced that client onboarding is essential. Here’s why.
As a software development company that prioritizes quality over everything else, we want to make sure that our cooperation with clients goes as smoothly and efficiently as possible. Our developers aren’t just freelancers with zero accountability. They are acting as an extension of your team, a business partner if you will. That’s why the relationships for us are extremely important.
As a client, you’ll probably have many questions. Onboarding is the best time to clarify everything, from the legal issues to the number of video calls per week. Having a well-defined yet flexible client onboarding process helps us ensure that our partnership is off to a great start.
In this article, we will talk about the process at Relevant Software and tell you more about how we onboard clients in our company.
Client Onboarding Process at Relevant Software on Product Development
There’s no industry standard as to what a client onboarding process should look like, but for more than years of serving clients all over the world, we came up with our own approach. Here’s how it looks.
Let’s talk about every step in detail.
Signing Statement of Work (SOW)
So what happens after we sign a Master Service Agreement (MSA)? First of all, we take care of the legal matters by signing SOW. It’s an important addition to MSA, another formal agreement between a company and a client that specifies all the details about the product or service to be delivered. In other words, SOW is a contract that will define the procedural terms and conditions of our business relationship.
SOW covers the following aspects:
- Project overview and expectations (requirements, standards, etc.);
- Project stages, their scope and criteria;
- Deadlines and deliverables;
- Estimates costs and payment details;
- Key KPIs.
The goal of SOW is to prevent any disagreements and misunderstandings between the parties. Dealing with all these questions early in the process gives both sides peace of mind and sets the whole thing up for success.
Requirement workshop is a collaborative event of key project stakeholders, the goal of which is to discover, validate, prioritize, and agree on the project requirements. We typically organize such workshops with our business analyst, project manager, and designer.
A typical workshop takes around 2-3 hours and the goal is to draw mockups and write project documentation. The next step is project re-estimation, which provides a more accurate timeline and resource estimation based on the prepared documentation and design.
At this point, we’re almost ready to start coding, but there are a few more things we need to take care of.
An artifact in software development refers to any project-related thing created by people involved in the process. First, a dedicated project manager develops a list of all the required artifacts that must be produced by different team members and then puts everything on a shared Google Drive for everyone to view and share.
Here are some of the typical artifacts, which are essential for every project.
Project Charter. It’s a statement of objectives in a project. This statement also sets out detailed project goals, roles and responsibilities, identifies the main stakeholders and the level of authority of a project manager.
RACI Matrix. RACI stands for Responsible, Accountable, Consulted, and Informed. It’s a linear responsibility chart that maps out every task, milestone or decision, as well as the roles of each person involved.
Change Request register. This is a file where we are tracking requests from any stakeholder. It usually consists of request number, date added, request description, field to implement (FE/BE/BA/PM/DevOps), who requested, and the requested due date.
Gantt chart. It’s a bar chart with project work breakdown structure (WBS), start and end date for each work.
Project roadmap. It’s a high-level strategic overview of the key project elements. It should include objectives, resources, deliverables, milestones, and planned timeline.
Release plan. In contrast to project roadmap, this is a simple scheme of task-level project details presented on a timeline. A project plan is used for assigning responsibilities and track progress.
Risks register. It looks like two tables with a list of all possible risks, both negative and positive. Risk register also includes qualitative and quantitative analysis and various action plans to be executed in case things go wrong.
User stories. It’s an informal description of one or more features of a software system. We can’t give an exact estimate until the full scope is described by our Business Analyst.
Setting up Jira
Here at Relevant, we use an Agile approach to software development, and to keep track of the process, we use Jira. It’s an issue tracking – slash – project management tool used for task management and reporting. We use it to visualize the progress and plan a working process for our team.
Developing a Strategy and Planning
Before the beginning of the work, a Project Manager must conduct risk identification and evaluation session with all team members, preferably with a customer, too. As a result of this session, we should have two Risks matrixes in a project folder ‒ positive and negative.
Project roadmap and release plan
The better the plan, the easier the execution. Our next steps involve spelling out a detailed project roadmap in a Gantt chart with dependencies and creating a step-by-step release plan. It’s going to be super helpful for the entire duration of the project.
Scheduling client meetings
Effective communication during the development process is key. We agree on all the details, such as the frequency of interactions (daily standups, weekly/monthly meetings), preferred communication channels (Slack, Skype, Google Hangouts), and the availability (if we’re in different time zones).
Setting up DevOps and development
This stage doesn’t require a client’s contribution but it’s an essential part of project planning and it’s critical for the success of the project. Our team creates CI/CD pipeline diagram, system description, and instructions for developers. We’re also setting up the environment and building the architecture of the project.
How Long the Onboarding Process Usually Take?
Depending on the amount of documentation we’ve managed to gather and the complexity of the project, it can take anything from one day to a couple of weeks. In the latter case, onboarding becomes “Sprint 0”, but that’s a highly unlikely scenario. Typically, onboarding doesn’t take more than a week.
What if I Just Want to Hire a Few Software Developers?
We still have an onboarding process, which includes the following steps:
- Signing SOW. The contract is necessary in any case.
- Artifacts creation, writing documentation and creating a roadmap (or requesting it). We have to know where the project is headed so that we can provide business analysis consultation if necessary. Moreover, we should see the load of employees and start looking for more resources when the client needs them.
- Jira setup, user stories, and tasks. Even if we only provide developers to be managed by the client, we also have to manage them internally to maximize their performance.
- Performance monitoring and code review. This stage is necessary since we want to ensure the highest quality of our services.
This is pretty much it when it comes to our client onboarding process. We’ve been developing and documenting it since 2013 to provide our clients with the swiftest and smoothest onboarding experience.