In this article, I want to share my experience and present the biggest obstacles you can encounter when launching a new IT project. I’ll tell you what to include in your preliminary documentation (such as an RFP), show you the steps you can take before the start of a software development project and describe the benefits they bring.
Additionally, I’ve carried out a poll among the Pretius analysts – asking them about the things they want to have in preliminary documentation and problems they often encounter – and included some of the answers in the article. The idea is to help you understand what business analysts consider to be helpful and necessary, and what is often overlooked by managers who plan their first software development projects.
Image source: Pexels.
Let’s start from the beginning, i.e. the idea of creating software for your company. You just came up with one. So what now?
Sometimes, it may seem that developing software will solve all or most of the organization’s problems. In most cases, however, you create a solution to achieve very specific goals. So, the very first step of your software development project plan should be to define these objectives clearly.
You need to know exactly what you want to achieve through a given software project. I also recommend verifying these goals with the help from other people in your company. It may seem trivial, but we often encounter a situation when the client’s employees don’t understand why they have to switch from their favorite, well-known Excel to a new, unfamiliar software solution. You need to explain everything to them, show them the anticipated benefits, and make sure that you all agree on the defined business goals.
Some examples of well-defined and badly-defined goals:
Now, are you ready to design your new system? Not yet. There’s a few other important steps you should take before you start the actual software development process.
Sometimes optimizing a business process requires something as simple as adding an automatic reply to an e-mail or improving the way data is displayed in Excel. Such a solution may seem like a naive oversimplification, but when you look at the costs and the time required to implement a new solution, it can actually be the rational choice.
But lets assume that – after conducting many interviews with employees and verifying things appropriately – you’re sure you need to introduce a new software solution. What’s the next step?
Before you commit to developing a custom piece of software from scratch, you should google ready-made solutions, verify their feature sets, and see whether any of them can help you in your case. While a license for off-the-shelf software might seem like a big investment, it may actually be a good option. There are several reasons for that:
Of course, there are also downsides of choosing ready-made software products:
If you’ve checked the existing, out-of-the-box software products, and the development of a custom solution seems like a better option, then I invite you to the next chapter in which I will tell you everything you need to know about the stages of preparing for an IT project.
In this section, I’ll provide a few tips that should help you coordinate your work efforts with the project team members responsible for designing, developing and implementing your future software.
The information often missing in the preliminary documentation. Source: a poll we conducted among analysts working at Pretius.
The first very important step is revising the current system. Unfortunately, quite often we encounter situations where our clients focus on the new solution so much that they forget about the current one. And the software you currently use is important for several reasons:
The software development project teams often don’t have knowledge about the current system.
The knowledge about the current solution can be divided into technical and business areas. Let’s look at them in more detail.
The main benefit of understanding the business area: structuring the knowledge about the current solution. If a document with the above information has been prepared, it can be used both internally (by people joining the project) and externally (to build an understanding of the business and current business processes). If multiple people have worked on different parts of this document and you have multiple files, you can merge PDF files to create a single, consolidated document.
The description fo business processes is the single most helpful piece of information to be found in the preliminary documentation, according to Pretius analysts
To collect information about this area, you may need people with technical knowledge, ideally ones who were involved in the launch and stabilization of the current solution.
Knowledge that may be useful:
The main benefit about understanding the technical area: structuring the knowledge about a technical solution. As a software company working with various enterprises, we understand that it is not always possible to obtain this knowledge, but the more information we have, the better we will be able to understand the technical situation and adjust the new solution appriopriately.
It is often the case that companies (or whole industries) create their own terms for objects, processes, systems, etc. Industry terms that have a different meaning in everyday life can be particularly difficult for outsiders. You can find some examples of such words in the table below.
| Word | Everyday use (Wikipedia) | Possible meaning in the project |
| Technology | A method of preparing and conducting the process of producing or processing some good or information | A PDF document that contains information about the manufactured product and the method of production |
| Campaign | A series of organized activities aimed at achieving a goal | A series of marketing emails sent to all end customers |
Keeping all the names and definitions in memory can be extremely difficult for people who are just starting the project (e.g., the software development vendor). Therefore, we suggest creating a dictionary. A good practice is to create one at the beginning of the project and then develop it successively. It should include information about words and their meaning in the organization, but also about how these words are used interchangeably.
The main benefit of creating a dictionary: establishing one language between the business and the software development team. It helps avoid misunderstandings in the future. The dictionary can also be used by new people joining the team (on both the business and the software development side).
It is also important to identify stakeholders before you start the project. This can be hard, because sometimes work isn’t carried out by one, specific person who’s responsible for the task. One good way to track stakeholders is to identify the person (or people) responsible for each step of the process.
When you know who stakeholders are, it’s also important to plan their involvement in the development of the new solution and provide them with the necessary knowledge about the project. In addition, you should also appoint people who will be responsible for the entire project (in case of larger systems, maybe even a few people responsible for specific areas)). Also, assign someone to maintain ongoing communication with stakeholders to keep them updated about the project using email, and consider using secure, encrypted communication channels and DMARC record generator to ensure secure and trusted communication.
Unfortunately, we often encounter the following situations:
Problems that result from the above scenarios:
Each of these issues can result in longer project times and/or higher costs.
Also, remember to choose the correct stakeholders for a particular meeting. The easiest way to do it is by creating an agenda which outlines the goals and topics for discussion for that specific meeting. It’ll help you understand who should be present. For more tips on organizing meetings see this meeting room management guide.
The main benefit of involving the stakeholders early: Building the knowledge and awareness about the development of a new system/product/project. Avoiding indecisiveness.
Since we already know what the goal is, we can move on to defining more detailed needs and requirements for the new system.
The current systems are often described too broadly, without necessary details.
What do I mean by “needs” and “requirements”? You should look at this from the perspective of end users, instead of designing the solution from a bird’s eye view. Needs are the things people want from a new solution, the problems they want to address, whereas requirements are the specific features you’ll need to implement to meet those needs.
If you start designing a system without defining the needs first, you may simply end up with a piece of software that doesn’t fit your business.
A few effective ways of identifying the needs are: talking to the stakeholders, conducting initial research with end-users, and doing so-called competitive research (examining existing competitive solutions). After preparing a list of needs, it’s good to prioritize them – it’ll guide you towards the right solution.
Requirements are created based on needs, either by the client, or by the software house – depending on the situation. Of course, if building requirements falls to the software vendor, the team needs to have the time necessary to carry out a comprehensive analysis.
The main benefit of defining needs: avoiding a situation where the solution does not meet the expectations of stakeholders.
Here are some additional tips you might find helpful during your IT project:
The development team often doesn’t have access to the testing environment.
Creating software requires a lot of work, both on the side of the client (the so-called business team) and the vendor (the development team). I hope that this article will guide you through the specific actions you need to take before lanching a software project, and will help you facilitate the work both internally and externally. These few crucial steps can smooth things out significantly during the early stages of the project development process and make the lives of project managers much easier.
And if you’re looking for a software vendor that will guide you through the whole process of designing and developing a new software solution, write to us at hello@pretius.com (or use the simple contact form below). We’ll see what we can do to help.
Here are answers to some common questions regarding software planning and early steps of software development that you can find on the Internet.
A Request for Proposal (RFP) is a document used to solicit proposals from vendors for goods or services. It is commonly used when a company is seeking to outsource a particular project or service and wants to identify the most suitable vendor to complete the project. RFPs are usually issued by government agencies, non-profit organizations and large corporations.
RFI (Request for Information) is a document used by organizations to gather information from potential vendors and suppliers. It summarizes what these companies can provide and allows you to compare their offerings against the organization’s needs.
The software development life cycle is the process of developing a program or application. It involves the planning, analysis, design, coding and testing of the software.
RFQ stands for Request for Quotation. It’s a document that is created by a business when it is looking to purchase a good or service from another business. It contains details about what the business wants and the quantity of the item or service they need. The purpose of an RFQ is to get an accurate price estimate from potential suppliers.
