Software engineering and choosing an IT partner: Things to keep in mind

If your company is looking for help with software engineering, you may find it extremely hard choosing between the various software engineering companies offering their services on the market nowadays. Deciding who to partner with is an important and complex decision.

A quality IT partnership should provide software reliability, fast time to market and a product in the agreed time and budget. While not easy, this is crucial for success.

Technologies are tools your IT partner uses to create a practical solution that will help you solve real problems across the economy. 

Let’s illustrate this with the example of track and trace software engineering:

With constant technological development, consumers can buy goods through multiple touchpoints, from onsite shops to social media platforms. Now, their expectations have become immediacy and availability of information — they want guaranteed quality of the product they're buying. They should be able to get proof that the product is indeed manufactured in a certain factory and is fraud-free.  

On the other hand, companies need the possibility of controlling their distribution process and to easily recall products if any flaws are determined.

For this to be possible, companies need visibility of stock across all channels and locations for both staff and customers. This is specifically valuable in industries that face high levels of product forging, such as tobacco, pharmaceutical, or liquor. 

The solution to these problems is a system which you can read more about in our previous post about building a track and trace system.

The key questions are: How do you make sure your software provider can deliver what you need for the money you invest? Even if they have adequate knowledge and skills, how can you make sure the quality of the product will be satisfactory? How can you trust your IT partner? 

How to know if your IT partner can guarantee quality software engineering?

Another thing you should look at when choosing your IT partner other than their technological knowledge, skills, experience and expertise is their way of working and the processes and procedures they have in place. 

If you want to keep an eye on your project, have transparent insight into which phase is being developed and be certain that you’ll get what you need within the agreed time, you should find out how that company works. Visibility into software engineering operations has been poor for too long, as illustrated by Forbes.

It’s not enough that they only have knowledge, skills and know-how — that’s a pre-requisite. Having just the right know-how might get you what you asked for, but that might not be what you really need, and you risk being frustrated during the software development process. 

Therefore, your IT partner must have:

• clear and established processes and procedures for both software engineering and communication with you, their client. 
• deep understanding of your industry and especially your business, to assess the needs and get the correct and precise requirements for the software solution you need.
• the right team - people with the knowledge and expertise needed for your specific project. 
• structure and use clear procedures to make sure they deliver what’s agreed when it’s agreed, and to have a multi-way communication during the software engineering process to keep it agile and be able to react fast if changes or updates are needed. \

Structured software engineering in practice and why it matters

Let’s take a look at our example:

When the sales process is over and we agree to establish a partnership, we start by filling out Initchecklist. This list is an incredibly detailed way to collect all project requirements.

This first part must be done thoroughly. When done correctly, it will give us a real and deep understanding of your issues and needs, as well as specifics of your business and industry. 

Your only job is to tell us what you need, and ours is to engineer not just the software solution but also the way of working and how we’ll get there. 

A good software engineer is the one who gives you what you ask for. A great software engineer is one who can assess your needs and give you what you need and what will solve your issues in the best possible way.

Sometimes, what you think you need and what you really need are not the same. We see our job as your partner and consultant, and our responsibility is to be proactive, give you advice and suggest the best solution for your issues. 

That’s why we begin from your perspective, and then we come to internal processes. The structure and processes are tailor-made for your specific project and adapted to your needs. There is no one-size-fits-all approach.

After we understand you, we make sure you understand our process and way of working so that it can give you clarity of what’s going to be happening and you have full transparency and control over the project. 

Our structured approach consists of two key aspects. The first one is organizational, and it is based on Project Management Live Cycle — PMLC, and the second one is technical, which is based on Software Development Live Cycle — SDLC. 

These two aspects allow us to have:

• Effectiveness: This means we’re doing the right things. You, as a client, get the right value and what you need
• Efficiency: This means we’re doing things in the right way. We create value in the best way, with optimized resources
• Good relationship and constant communication with you and other project stakeholders

Software engineering for your project — how to choose the best methodology?

We use the best Software Development Lifecycle practices and help our clients decide which methodology is best for them for a specific project we’re working on

We’ll use Kanban (lean) and Scrum as an example of how we’re assisting clients to decide which methodologies to use. 

Kanban is more of a pull model, and Scrum is considered a push model. What does that mean? 

Kanban is oriented around a Kanban board, which is divided into columns that represent phases of the project. We write the tasks on cards that move along the board until they are completed. This method is more fluid and flexible, as the project is divided into small tasks and making changes along the way doesn’t interfere with the progress. 

Scrum, on the other hand, requires more discipline and planning and is more suitable for complex projects, as it consists of development cycles called sprints which typically last from one to four weeks. 

We consider a set of determinants, such as the expected frequency of changes or the size of the project, when choosing the best methodology for developing your software.

For example, this is a simple yet useful questionnaire to decide which methodology to use:

• Is it expected that the priorities will change often? (YES: Kanban, NO: Scrum)
• Is it expected from the team to optimize the responsiveness to change requests? (YES: Kanban, NO: Scrum)
• Are frequent change requests expected and is it hard to lock sprint for changes? (YES: Kanban, NO: Scrum)
• Is the team engaged in a small project (short-term project)? YES: Kanban, NO: Scrum)

This example is just a short and simple illustration. In real life, we’re getting into a lot more details. For example, we get deep into details to determine the degree of process automation needed for specific project requirements, all while keeping in mind the budget. 

The processes we have established regarding software development, project management and client relationship management allow us to ensure the quality of a product on 3 levels: 

• strategic though our Key Account Managers, regular communication with you as a client
• project through documenting the entire software development process and using project management methodologies
• and software‍

Software engineering and communication among stakeholders — how to make sure it happens in the right amount?‍

Based on our experience and organizational knowledge, we have created a structure consisting of 6 basic communication processes: 

1. Development Team – Client. This is the most intensive process which can take up to 90% of all communication. Our development teams communicate with you – our client – on a daily basis about operational matters since they work on creating the optimal solution and value for you every day of the project's duration.

2. Team Lead (TL) – Key Account Manager (KAM) – Chief Engineer (CE). This internal meeting is organized every two weeks by CE and its purpose is to exchange key information and monitor progress. TL presents the state of the team through a set of indicators – technical, organizational and HR-related – as well as the key findings about the project itself. KAM presents the input from you and communicates any request or feedback you may have to the TL. On the other hand, TL communicates all findings you should be aware of to KAM, since TL might foresee certain issues before they arise, but doesn’t have the authority to act on them. The result of this meeting is a set of action items directed at the Team, KAM or our company itself.

3. KAM – Client. Once a month KAM meets with a higher-level manager from your company to exchange business-related information and discuss expectations and plans for the future. The purpose is for KAM to get your feedback, make sure you are satisfied with our service or bring up any input they received from TL.

4. Team – Chief Engineer – Chief Operation Officer. We call this meeting a quarterly retrospective and the main thing about it is that the whole team participates in it. It’s organized as a workshop led by CE where the team openly discusses all the relevant aspects of the project. Team participation is important because sometimes the Team Lead may oversee some relevant aspects that can be discovered during this workshop. Again, the result of this meeting are action items that also present the input for the biweekly TL-KAM-CE meeting.

5. KAM – COO – CE. The input for this meeting, which is held every two weeks, are all the items from the action item list for all our clients and projects, while the output is a focus list for the next two weeks. The purpose of this meeting is to determine what to focus on for the next two weeks, according to project priorities and action items list from meetings (2) and (4). All KAMs participate in this meeting and receive directives for their work in the two following weeks.

6. Executive Management (EM) – Chief Finance Officer (CFO) – CE – KAM. This is a strategic meeting where the Executive Management receives necessary input in order to create a report for each project. The meeting is led by the COO and the output is the report which includes information from all relevant stakeholders: CFO provides financial input; CE provides technical input, Head of KAM provides business input, and HR gives people data. The report that comes out of this allows us to make strategic decisions, such as increasing the number of engineers, closing the project or changing team seniority.

All of these processes are interconnected, and they enable us to ensure the right information is communicated to the right people at the right time. There can be no transparency without properly conducted communication, so having regular meetings and receiving valuable feedback will impact on your satisfaction with the final product to a great extent. 

How does knowing the internal processes of a software engineering company help you choose better IT partners?

We see our structured approach and defined processes as key proof of our capabilities and a guarantee that you will be satisfied with the product you receive and it’s quality. 

Here at Enlight Engineering, our practices have slowly evolved into the processes we use today. This is why they are the reality of our company, and not just an empty phrase or rules nobody follows. They came from our team’s experience and organizational knowledge, and they were created bottom-up, not top-down. We didn’t invent any of these methodologies, we just collected the best practices, put them together and created a concept that allows us to deliver the best possible solutions and outcomes for our clients. 

The benefits of a clear and structured software engineering approach are:

• shorter product development period — faster time to market
• reduced number of complaints thanks to continual communication on all company and team levels
• less time needed for refactoring
• greater understanding of your business needs and your industry
• cost-effectiveness - we’re able to deliver everything we agreed on within an agreed budget and within the agreed time 
• transparency - you’re able to track all projects’ activities during the entire project duration

Why am I sharing all of these? People are usually afraid that someone will copy their way of working and knowledge, but not me. 

Michael Porter said it’s easy to copy one activity or a process, but to copy an entire system of activities is extremely difficult. This is why we see our structured approach as our unique advantage compared to other software engineering companies on the market. 

When choosing your software partner, always consider the structure of their approach (or lack thereof). It can tell you a lot about their ability to deliver the optimal solution to your problems. 

Conclusion: A clear and defined structure guarantees transparency and a return on your software engineering investment. 

Regular communication with your software provider is important, but even more so when you understand exactly which phase of the process it takes place in. 

Having a clear vision of your IT partner’s structure will allow you to understand where the information comes from and ensure that the input you provide will be distributed in due process. 

In case you feel our approach would be a desirable choice for your problems needing software solutions, we would love to hear from you and discuss partnership possibilities.