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.

Choosing how to implement the idea and creating an effective software development plan

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.

Step 1. Define short-term and long-term goals

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:

• Bad: Developing software for sales – it’s broad, unclear and doesn’t mention any actual advantages
• Good: Reducing the customer service time at a sale point from 20 minutes to 5 minutes – it describes a specific benefit you want to achieve

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.

Step 2. Checking whether using/creating new software is really necessary

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?

Step 3. Checking how other people/companies deal with your problem

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:

1. The process of creating custom-made software can take several months or even years, while an off-the-shelf solution could be available as soon as right now, after a quick configuration.
2. The development of a bespoke software solution is pretty costly, almost always more expensive than using an off-the-shelf product.
3. Implementation and maintenance of this custom-made system may also involve additional, hidden costs, which will drive the overall investment even higher. For example:
   • License costs of additional required software
   • The time and commitment of your employees – our clients often forget about this, but to build a quality solution we must have constant contact with the stakeholders. It means your people will need to find time for workshops, meetings and other types of activities
   • Hiring additional people to run UAT tests, project management, staff training in new software, and more
4. Ready-made boxed solutions are often battle-tested, secure and supported by large, active communities

Of course, there are also downsides of choosing ready-made software products:

1. No impact on the direction of development – usually, you’ll be unable to steer the changes made in the off-the-shelf solution
2. Lack of ownership of the purchased software – most likely, you won’t get access to the code of the ready-made solution, and if the company goes out of business or decides to discontinue cooperation for any reason, you’re left high and dry. You’ll also have limited options when it comes to branding or scalability

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.

Getting ready to work with the development team

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.

A crucial step towards project success – revising and understanding the “as is” state

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:

• Understanding users – understanding the current habits and problems of users will help to model a solution that takes into account their needs
• Key business knowledge – the business processes and domain model are usually left unchanged, and while you probably know them very well, the software development team does not. Help them understand your processes to make the development faster and the new software better adjusted to your business goals
• Migration – an often overlooked element that is required in most cases. What I mean by this point is not only the transfer of data from system A to system B, but also the transition state between solutions, which is also often required (especially in large projects). In order to plan the entire software development process – so that your employees aren’t left without tools needed for work during the migration –  your vendor must know how everything works now

The knowledge about the current solution can be divided into technical and business areas. Let’s look at them in more detail.

The business area

• Business processes – the current solution (whether it’s an Excel spreadsheet, paper documents or software) is based on your company’s business processes. Thus, when analyzing current processes, you can often come across elements that you could miss while simply writing down the new app’s requirements. It will help you prepare for questions that may arise during workshops with the new software vendor. Identifying the persons/roles who are responsible for or participate in each step of the process will also be helpful. Remember: when developing new software, the core processes usually remain unchanged – you just change the tools used to carry them out
• Domain model – a list of the main objects in your business (depends on the industry, for example, for an eCommerce company the objects would be things like order, item, manufacturer, or discount voucher) and a description of the relationships between them can be very helpful, especially if you want to remodel the current solution. It’s important to focus on the business facilities that are actually in the company, and not on how they are designed in the current system
• Currently available functionalities – knowledge about your current solution’s functionalities can be very helpful when preparing proposals for an MVP (Minimum Viable Product) and for the transition state. Of course, it’s possible to add new features in the new software product (as well as remove some of those that aren’t used anymore), however, the basic set of features will probably stay the same

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).

The technical area

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:

• Integrations with external systems – understanding how systems are connected with external solutions, and also how and why it sends and receives data
• Current architecture/infrastructure of the solution – learning how the solution is built and where it’s physically running (e.g., on an on-premise server, the cloud). In addition, it’s important to know why this specific architecture was chosen – it may be due to the specifics of the project/data storage or other important factors

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.

The vocabulary problem

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.

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).

Stakeholder involvement

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)).

Unfortunately, we often encounter the following situations:

1. Stakeholders learn about the existence of the project and its goals during the first workshop with the development team
2. Stakeholders don’t know the project’s purpose and don’t understand its value
3. People who work in other areas of the organization don’t have time scheduled for meetings/workshops
4. In effect, relevant stakeholders aren’t present at important project meetings
5. There’s no one, specified person responsible for making decisions

Problems that result from the above scenarios:

1. Extended waiting time for decisions/meetings with stakeholders
2. Changing requirements during the project
3. Lack of unambiguous requirements

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.

The main benefit of involving the stakeholders early: Building the knowledge and awareness about the development of a new system/product/project. Avoiding indecisiveness.

Defining the needs and requirements

Since we already know what the goal is, we can move on to defining more detailed needs and requirements for the new system.

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.

• Example of a well-defined need: I don’t want to remember three different passwords for different company systems
• An example of a requirement: Allowing secure login to three company systems without having to enter a password

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.

Additional helpful tips

Here are some additional tips you might find helpful during your IT project:

• Access – make sure the development team has all the necessary passes, access to the test environment, source code, etc. In our experience, this can take a long time, especially in the case of large corporations
• Perspective – keep both short-term and long-term goals in mind
• Goals of the meetings/workshops – remember about establishing the goals and writing down an agenda for specific meetings or workshops. It will help avoid a situation when the time has been used up, but the meeting did not bring the expected results

Software development plan – a invaluable tool for every project manager

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. 

Software project plan FAQ

Here are answers to some common questions regarding software planning and early steps of software development that you can find on the Internet.

What is RFP?

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.

What is RFI?

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.

How does a software development life cycle look like?

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.

What is RFQ?

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.