Tag Archives: Case Study

Case study: Are Third Party Developers Worth Including?

How does the use of new technologies and third-party developers cause problems even though they look great “on paper”? The answer is that it creates poor communication between the customer and the launch teams.

 

Itera Research’s rule of thumb: If analysis can be done, do it. 

In this case study, we explore exactly why we adhere to such a policy, and what information it can give us.

 

May the stars show you the way!

Our study starts with a mobile application for astrologers. This app provides various horoscopes, tips, parting words, and checking the compatibility of the horoscopes between people.

The client has a subscription which includes 3 levels – Basic, Student and Master. Each level gives more and more benefits. The subscription can be either monthly or yearly and includes built-in awards, amulets and pendants (but only their digital counterpart).

The user buys all sorts of virtual amulets in the game and puts them on himself in this application. It also monetizes through advertisements.

 

Which platform to use as a framework

In the process of discussing platforms, we came to the conclusion that we will make a UWP application that will be released for two platforms at once – iOS and Android. The reason – after analysis such a decision was dictated by the cost – the development of one UWP application was equal to only 120% of the cost of one application for one platform.

To do this, we decided to use the Flutter framework, which already has everything you need to create applications for all popular platforms.

For first-time listeners, Flutter is an open-source development kit and framework for building mobile apps for Android and iOS, web apps, and native apps for Windows, macOS, and Linux using the Dart programming language, developed and maintained by Google Corporation…

 

Our main problem…

Developers from different companies worked on the project. Toward the end of development, when the application itself was finished, we began to add various libraries to it: analytics, payments, advertising, etc., and that is when difficulties began to arise.

The main cause of the problems was the third-party team – we did not have access to the programs themselves, or the code, making it impossible to fix anything or help them in any way. We spent a lot of time setting up and sorting through various libraries to make everything work at least at an acceptable level.

But the real difficulty was communication and timely resolution of problems that arose since we were back-end developers, while the other two developers were third-party. They were engaged in writing applications on Flutter directly on platforms (Android and iOS)

The project manager and tester were also from Itera Research, but it was still a long and painful process for both the development team and testers, as well as for the customer. The process of setting up the libraries lasted three weeks, which was agreeable to the client.

 

Why was it important for us to set this up?

Since this is a mobile application, operating systems prohibit the connection of payment using third-party services – MasterCard, Visa, etc.

All mobile apps work using internal payments with which Google and Apple work. This makes it, so they have their dashboard, settings, and subscriptions, and all payments go through their services only.

This library allowed the application to send requests to Google and Apple pay points and make payments within their services, that is, a kind of payment connector.  Such technology is called “In-App purchases”.

 

Timing is everything…

We were severely limited by the deadlines due to constant delays in the work process adding a level of challenge. Another problem was in the technical part – the server was not ready. We could not properly test the application or interact with it, even at a basic level. There were not enough resources from third-party developers, creating a significant amount of time we sat idle. Additionally, the third-party developers were also frequently idle due to the inability to check the performance of their applications. As a result, this downtime greatly interfered with the development process.

In such a situation, it is always important to devote time to work and communication with the client. Try not to panic him, but competently discuss the current state of affairs, show the results already made, and let the client test his application with his own hands. It was this approach that helped us maintain relations with the customer and complete the project, albeit with difficulties and missed deadlines.

The project itself was designed in two months, and we provided the finished product after 4 months, but only the Android version. With the publication of the application in iOS, we had to do a lot of magic. You can read about it here.

 

What else did we include in the development process?

We experimented a lot with payment, advertising, and analytics libraries. We constantly tried new options and changed existing ones until the result satisfied us. There were technical difficulties in making the functionality that the customer wanted. And, we had to make a lot of effort to make it all consistently work correctly.

Therefore, you might say that at first glance there appeared to be simple solutions given ready-made libraries, but this brought complexity that had to be adapted to a new project.

 

Native app or Cross-Platform?

If we talk not only about money but about the manufacturability of the application itself, in terms of convenience and other things, we might ask which is better. 

With native applications, it would be easier to integrate third-party services, as there is more documentation and ways to work with code and programming languages.

If the customer had chosen native applications, then it would be easier for the development team, and it would take less time to test. But in the end, we found that a cross-platform application was cheaper for the client. It takes a little longer and is more expensive to make native applications, while the cross-platform application causes less stress, nerves and risks. Since it was stressful for both the development team and the client, because many things did not work, we had to allocate a budget to fix and adapt all this.

 

Astrologers sum up…

Our team faced a lot of difficulties both technically and with communication. The biggest challenges were caused by the fact that there were outsourced developers to include. They worked remotely, which made the process of communication and interaction more difficult.

In the project itself, we had to take on the role of leaders in development. We gave recommendations and advice, issued technical specifications to all teams, and constantly communicated with the customer. 

Taking on a leadership role, while at the same time taking full responsibility for the project, it paid off – the product was completed, and the customer was satisfied.

|

Case study: How our client hired developers

Every year, the importance of digitalization is felt more and more strongly, and primarily it is felt by non-IT companies. When a company decides to digitize their company, a dilemma arises: do you hire your IT staff or use outsourcing? 

Today, we will talk about the benefits and challenges that companies can face by using an example of one customer story.

 

We will make our own web platform

We deliberately removed the company name, but we will share the specifics of their work. The company was engaged in collecting data on partner violations, doing reviews, and solving the legal problems of their customer. The key problem was the lack of automation in certain areas of work. That is, the operator receiving the call had to fill out a questionnaire and describe the problem to conduct a review and give feedback. All of this took a lot of time and human resources that should be optimized.

This is how the idea of ​​creating a platform arose, where the client could fill out an application and transfer it to specialists in an already prepared form. By Simply adding this platform would significantly reduce the burden on the support department and make it possible to unify the application system.

But an idea remains an idea until it is realized. Once implemented, the company’s management decided to hire one developer per staff, as it initially appeared to be less expensive.

 

Recruitment difficulties

The client conducted interviews with various specialists but came to the conclusion that they lacked an understanding of how to select the appropriate specialist, how to verify that they would deliver the required work, what technologies they should know, and so on.

This often becomes a significant challenge, as it can be quite difficult for someone unfamiliar with the implementation of a task to evaluate the competencies necessary for its completion.

In addition to hiring difficulties, our clients have voiced concerns regarding retaining specialists who work with different cultures. The specifics of developers’ work are different from those of other employees, making it challenging for developers and IT specialists to work in teams where they are not well understood.

 

Let’s hire a freelancer

As a next step, the hero in our story decided to seek out a freelancer who could assume responsibility for delivering the final product, enabling the client to avoid becoming embroiled in the intricacies of the code and its implementation.

This approach could have worked. After some time, they were able to find a specialist who was willing to take on the task. The developer asked for technical specifications to understand what needed to be done, as developers typically do.

The development tasks were set by one of the best managers in the company. Unfortunately, he did not have the knowledge or experience in developing software solutions, resulting in tasks being set as he understood them. The freelancer did as requested and as he understood, but delivering the software product was ultimately impossible. The client spent tens of thousands of dollars and a year of time.

 

How did our story end?

Unfortunately, this is a typical story that we encounter in our experience. Writing good code is only part of the project’s success.

Ultimately, our client turned to an outsourcing company, which conducted a business analysis stage where they mapped out all the platform’s functionality, determined the requirements, created a prototype, and clarified which parts required development by the developer and what type of specialist was required.

Not everything went smoothly this time, and choosing the right outsourcing company is always challenging. We will talk about this in the next article.

 

The story’s moral is simple: employees, freelancers, and outsourcing companies all have different approaches to implementing business tasks. It is crucial to carefully evaluate one’s strengths and weaknesses and choose tools and approaches that will lead to the result you need to get.

Further information on the business analysis can access through the link.

 

|

How long does it take to publish to the App Store: Our client’s months-long story

The history of our interaction with the giant of the mobile industry – AppStore – was a long and winding road. Our client had created a fantastic and useful mobile application for those who are interested in astrology. It produced and shared various horoscopes, advice, and parting words, and even offered a function to check the compatibility of people using their horoscopes.

 

The App

The client has a tiered subscription of 3 levels – basic, student and master and offered either for a month or a year. Each level promises to offer more benefits than the last.  The application also includes built-in amulets – pendants, as a digital counterpart.

 

The Process

At first, our application was refused to be published in the Apple app store due to the issue of redundancy, the fact that there are already so many similar applications with our apps current functionality. App Store’s stance – it simply is not needed there.

 

Of course, this response did not suit our client, and we set about attempting to provide alternative solutions to solving this issue and helping our client.

 

While looking for different ways to solve the problem, we first tried to change the application itself, its positioning and its functions so that it looked less like astrology, and more like an application within the “healthy habits” category. Then, after additional thought, we proposed to change the topic from astrology to psychology.

 

The Result

The Application was submitted four times for review, but only three times appealed… We worked collaboratively with the team and Apple technical support about why our application was unique.

 

As a result, we changed the theme of the application and its functionality to better suit what the users would enjoy. New options and features were added, and although they extended the functions of the application, they did not change the essence of the application itself. 

 

Additionally, it was proposed to republish the application on behalf of another company from another country, but in the end, all our actions and efforts yielded our desired results, before this step was necessary. In the end, Apple approved the application in its marketplace.

 

After a difficult and long journey spanning 10 months of trying to publish the application, it was approved. 

 

The road will be mastered by the one who walks it.

 

|

Case study: How, against all odds, we created an IoT device for cities

Implementing new technologies is a complex process. In addition to creating the technology itself, there is the human factor. People are not always able to immediately grasp the essence of changes and accept them, even if it makes their life easier. This idea was especially noticeable in the project to create an ISA device. This project aimed at developing cities according to the Smart City principle and focused on simplifying the control of meter readings collected by housing and communal services.

 

The city wants to develop, but what about its inhabitants?

When we got a project idea, we had been working in the software development market for more than ten years and tried to do hardware development. We had a customer with a software project. During our long-term work, we learned that our client could not solve the problem with hardware development. He turned to various hardware developers. Every other convinced him that it was impossible to make an acceptable or inexpensive solution, that they were experts, and nothing would come of this venture. So we wondered since we have already worked with software for this domain.

You will learn how we implemented this project below, but the result deserves interest. We created our hardware development department, created a device for the customer and continue to work on this project.

Are you sure you want to hear all the details?

The qualitative implementation of the project requires a business analysis stage, which is particularly important for a serious task. We started with BA. We learned that in residential buildings, there is a planned replacement of old meters with smart ones. The plan was as follows: to install 500 units per year. It was possible to install 250 units, and it was necessary to install 10,000 units. At such a pace, the plan in 20 years turned, at best, into 40, or even never at all. In addition, the same scheme for collecting indicators looked “slightly” outdated.

It turned out that some “unknown” number of people were walking around the city and taking meter data. At the same time, the city’s power company is doing the same. Due to the difference in the removal dates, the indicators do not match, leading to conflicts and the inability to track the amount of electricity consumed.

During the verification process, it turned out that some metering devices were not installed at the facilities in principle, but data were regularly taken from them. Because of such situations, the relevance of all data tended to zero.

If it were necessary to make the most unreliable system for the operation of something, then this would be its example.

 

How to solve the data transfer issue and not pay several billion for it?

The idea of the project was simple – to simplify the data transfer procedure into three steps: take a picture, recognize and transfer the data to the server. The critical problem was cost reduction. Otherwise, there is zero practical sense in such a solution.

The situation turned out to be interesting. In the process of in-depth market research, we found the following: most meters are either induction or already smart. They have a digital interface and the possibility of remote transmission. But in both cases, there were nuances. Smart – super expensive, and induction gave a significant error.

 

If the others can’t, we’ll do it ourselves

The solution was to use the standard set of components. That is, hardware engineers (in Ukraine, by the way, these are electronic engineers) used a relatively common set of parts for the board.

In searching for the correct answer, we were so carried away by the idea that we already intuitively felt this could be done. Having hired our hardware-electronic engineer, we set him a task. By the way, our new teammate was very optimistic.

A hot young engineer calculated everything, and we concluded that two months would be enough. And as a result… we spent more than a year on the first version. A few more months were spent adapting the device for operation in actual conditions.

 

Half the battle is to invent, and half the competition is to implement

Having reached the stage of practical use, the question arose – which camera to choose. It seemed like the best option was to select the cheapest one, but then we failed. It turned out that the form factor of the cameras is very different. As a result, they went through hundreds of cameras but found the necessary one. We installed it. And then, it turned out that you need to read the readings but do not remove the device from the meter. We will not describe the entire path of searches, selection of the required dimensions of the device, calculation of the focal length, and struggle with exposure. One of the main problems was the lack of connection at the counter installation sites. Many meters are located in the basement.

After the first report, it turned out that half of the devices could not send information. Of particular pleasure were the public utility workers. The illuminated meter became a topic of conversation for them for a long time.

 

What did we finally get?

Throughout the project’s development, there were many reasons to refuse and stop, but we did not give up. We took on this project and confidently moved forward with our clients, supporting each other through tricky development turns. Fighting humidity and temperature regulators, setting up a data recognition system using neural networks, fighting with the local population so that new technologies are not hyped for spare parts, and much more.

Not to mention the manufacture of the devices themselves using 3D printers. Of the required five, there were only two, but it must be necessary. Then our 3D printers appeared in our arsenal.

Now, ISA devices are actively used by the state energy company “Oblenergo” to take meter readings. In the future, it is planned to develop systems to transition all city services to the concept of using smart devices.

And perhaps, the central insight of the project was thinking out of the box. In an attempt to find outsourced performers, we often encounter blinders. At the same time, our goal was to complete the project in any way and fulfil our obligations to our client. Therefore, despite the beliefs of hardware engineers, software engineers and neuroscientists, the project was successful and integrated into urban systems’ operation.

 

|

Case study: Help to save a project in 30 days

There are situations when the deadline is not just burning, but specifically, the chair on which the customer is sitting is already being burned. Taking on a project that is a month away from delivery, and the process has barely crossed the starting line, is not an easy task. Most experienced teams refuse such projects because these are big risks, but our team knows how, as they say, to play at limits and bring any business to the end.

 

What is all the salt?

The customer, – we will not divulge the name, let it be John, – met the team a couple of years before the “hot” situation at one of the conferences. After talking more closely, he handed over his project for an estimate, but in the end, he chose another contractor due to the lower cost. In fact, our team estimated the project twice as expensive, taking into account all the difficulties and risks.

The story could have ended there, but after a personal visit to the Ukrainian office and a closer acquaintance, John takes on a small team for another project. A month later, he asks to pick up another project, which we have estimated earlier. It turned out that there was only one month left before the completion of the year-long task, and 30% of the work still had to be completed.

 

Take or refuse?

Such situations in the development market are not uncommon. All because of basic mistakes in planning (we talked about this in another article, which can be found on the blog).

Finding himself in such a situation, John asked for help, because in case of failure he faced heavy fines since the customer company is a large enterprise. After conducting a preliminary assessment, our team assessed the starting conditions and came to the conclusion that to finish the project in 3-4 weeks, one of which will be spent on coordination with the client, the collection and onboarding of the team is a very big risk. Risky, but, as our PM said, it is not impossible. The system was written by a different team, the available documentation was in chaos, and there is no direct communication with the client – all of these reduces the chances of closing it on time, and our team tries not to take on the project if it cannot guarantee successful completion.

Even realizing the likelihood of failure, John asked to take on the project, since the professional team was his straw. In this case, it was better to try something than to do nothing at all.

Like any customer, John was worried about what the budget would be, and what would be needed, and asked for estimates for completion. There was no time to make an estimate in such conditions, and the work was carried out in the support mode and research with “gestures”. All for the sake of minimal planning, with the transition to further full-fledged analysis.

To give an estimate, it was necessary to understand the project, to understand all the functionality, modules, and a complex data structure, to conduct an assessment, and there was simply no time for it. As a result, we calculated the budget based on the number of people in the team and the number of weeks before the deadline.

Now there was a new problem.

 

How to beat time? Gather a good team

In such situations, without a good team, as without hands. In the literal sense of the word. When work on the system started, a huge number of problems emerged, ranging from lack of documentation to lack of staging, unstructured code, and an absolute break in communication.

In fact, the problem was much more global than can be described. Due to the fact that the code was written by many developers, while everyone wrote as he wanted, there were simply an uncountable number of bugs not fixed in the tracking system. The functionality was isolated within a certain page, there was one thing in the mockups, but in reality something else.

Despite the enterprise level, there was no documentation, not even the design of the system. To say that difficulties arose because of this is to say nothing. Even the same button was implemented differently in different parts. There is even nothing to say about testing, no one has done this a priori.

There was a lot of work, so we rolled up our sleeves and got down to business.

 

What was done?

To ensure minimal planning, we switched to Scrum with short sprints. Organized dev, demo, test, and production development environments, and implemented CI / CD.

Since the transfer of knowledge on the technical organization of the project and the business component was carried out in the development process, the following decisions were made:

 

Planning

Estimation of tasks by the developers was made on the basis of their previous experience in developing such systems without being tied to the existing code.

The resulting estimates were modified by coefficients related to the developer’s current level of boarding in the project and the individual performance of each developer.

We have simplified the estimate approval system: everything that was less than 4 hours was done without confirmation.

 

Testing

The final testing and preliminary analysis were taken to the client’s side since we could not fully accept the project in such a short time.

 

Systematization of development

To get quick results, the development was initially carried out without changing the architecture and refactoring. In parallel, an analysis and description of the architecture were carried out, a system of requirements was organized and a list of technical debt was formed.

 

After 4 weeks …

All planned tasks were completed on time, the system was stabilized, and the team was assembled and onbordered. In addition, the foundations were laid for the further systematic development of the project. The guys worked overtime and did the simply impossible, especially considering all the difficulties in development, which only increased the term of work. But in the end, the team backed up what John promised the client by the end of development.

In this case, the PM did a great job of team building. The guys were from different teams, and it was very important to create an atmosphere for productive work. As a result, the whole team was ready to work overtime.

The customer liked the project, and after it came the next proposal for cooperation at a more relaxed pace.

 

|

Case study: Redo cannot be updated

Why throw a system away if it works?

This dilemma exists not only in the post-Soviet space but throughout the world. Inevitably,  there comes a moment when a company needs to decide that “it’s time”; when the complete replacement of an obsolete mechanism or process will make a striking difference.

Understandably, not everyone is ready to take the step of completely replacing older systems, at least not all at once, because it means investing money and time. An internal rule of Itera Research is: if you can do the money/time analysis – do it. In this article, we examine the reason why we adhere to such a policy and what it tells us. 

Starting point

This case was particularly difficult, primarily because the ERP system was written using outdated Microsoft technologies. The task was to uncover missing functionalities and provide further support and development. There were two options for development: 

  1. To refine the existing system OR
  2. Transfer the functionality to a new platform and continue development on new software.

The customer company for which the system was developed has been producing prototypes for precision sheet metal components for mobile, automotive, medical and industrial products since 1995. As it turned out, the customer lacked essential functionality to meet the current needs of the industry. In addition, the code was developed so long ago that there were simply no specialists who could support the current systems in place. These are rare dinosaurs that are difficult to find, to put it mildly. It had undergone several changes and been updated and refined by different developers and, ultimately, no longer satisfied the business owner’s needs.

As stated before, the system was very old. It was developed 15 years prior, at the start of the business. We easily uncovered several issues. Not only was the system developed and maintained by different developers, but there was also no documentation of the updates. So, in this case, it was simply impossible to evaluate the project. It was also extremely challenging to evaluate the development of a new system because it was not clear what was needed and what could be eliminated.

Furthermore, the purchase of ready-made software, in addition to the high price, did not meet the needs of the company. As a result, it was decided that it would be more cost-efficient and timely to create a completely new system.

Why Business Analysis Matters

Before starting the work, it was necessary to choose an approach: Evaluate time and materials or walk through the stages of business analysis, with additional technical analysis included.

This initial evaluation found the following: a lack of documentation, tasks that were superficially constructed, and no time to clarify details. When working with someone else’s code, it is difficult to determine the weaknesses and vulnerabilities in the architecture, which in turn, can lead to latency. Upon initial analysis of the current system, it was found that the segment of missing information was too large, thus it was decided to conduct a business analysis. 

Consistent communication is crucial throughout the stages of business analysis. We conducted a number of workshops, where our business analysts communicated with different departments, collected user experience, and found out, in detail, the flow for each employee. The client and his staff came to our office to improve the process several times throughout this process.

In addition, we conducted a full analysis of the competitors’ systems in order to find out all the disadvantages and advantages of the current functionality and find ways to improve those.

As a result, the customer understood the following:

  1. The approximate level of costs
  2. The duration of possible development 
  3. They received 
    1. an understanding of the details of the system
    2. an outline of the functionality 
    3. Documentation of the plans, assuring any development company could understand what it is and how it works, regardless of who is involved in the project.

Find. Throw it away. Refresh.

Our cooperation began in July 2019. After a series of workshops, we plunged into business processes to think over the addition of old modules and the functionality of new ones. In the process of studying the technical side of the implementation, the architect found a number of technical problems that, in the case of using the old system, resulted in future business problems.

This information was a clear sign that development of a new system was necessary. After providing all the necessary documentation for the new modules and calculating the number of hours for new development, in the case of working with both the old and the new system, we transferred the data to the client.

Having jointly assessed the risks, and the pros and cons of each of the options, it turned out that the development of a new system was even more profitable than adapting the old one.

As a result, a new ERP system was created.

Outcome

Thanks to timely business analysis, the client saw the positive and negative sides of the existing system, estimated the risks and costs, and made a balanced and rational choice.

 

|

Greening Up the Office Through Sorting and Recycling

The Story of One Bottle

Once upon a time, there was a bottle. She was sad and lonely because as soon as she was emptied she was thrown under the table where she rolled into a dark corner. The cleaning lady could not find her, so she lay there in the dark. One lonely bottle.

She was very sad there, because she could not fulfill her destiny of being filled once again, but only lay uselessly covered with dust. But, on one of the endless days, someone’s foot accidentally touched her. The bottle was delighted and for good reason. She was found! She was washed, lid removed, and sent to the sorting center. There she saw other bottles, and in the future, she was able to fulfill her destiny by being refilled and becoming a new bottle again.

How the office got into a good habit

If you haven’t figured it out yet, the history of the bottle has taught us a lesson about the importance of recycling by the use of a kind of “sorting station” within the office setting. Originally, our waste removal system could not be called a “sorting station”, as there were only a few containers exclusively for garbage, so this was rather a useful initiative in our office.

The “sorting movement” itself began in our office two years ago. As you know, these things start with some kind of personal pain. One old-timer of sorting Dima, (a team lead of a project not related to ecology), said this: When we go to the forest, to nature, or to the lake, we constantly see garbage, it is depressing and frustrating. Landfills on the outskirts and rubbish left by “outdoor enthusiasts” are destroying the environment and we understand the importance of such initiatives.

The first step was the installation of a plastic collection box, then more were added for tetra packs and glass. In the future a plan to add more containers, but for now these are the solution.

How habits are formed

Understanding the importance of this matter seems obvious, and really, what is so difficult about sorting garbage? But, if we said that it was enough to install the containers and everyone immediately became aware of what to do – we would be lying.

It all started with one of our office colleagues who were concerned about the problem of environmental pollution. Then a couple more people joined, but there were still difficulties in communicating the importance of sorting.

In order to help people understand we implemented a variety of strategies. At first, we made public mailings, made announcements, and pasted stickers. We asked everyone we caught in the kitchen to be conscientious and sort the garbage. Of course, not everyone was immediately convinced by this, but gradually people got used to it and realized that it’s easy and helpful.

What happens to office waste?

Today, more and more companies are trying to implement a sorting system within their offices, because of the realization that environmental problems are becoming more and more real. Furthermore, such initiatives have shown to have a positive effect on teams, work environments and even make an impression on job seekers. Green is good!

Of course, in our reality, sadly more often than not napkins lie in mountains on tables, bottles “hide” under the tables, and the bins are filled with garbage that will never reach the recycling centers. But this does not mean that we are not trying. Before the quarantine, every two weeks our main initiator Dima took out a couple of bags of PET bottles to the sorting base. Now, while we work mainly remotely, there are fewer people in the office, therefore, there is also garbage and Dima still takes care of this issue.

What do we end up with?

While the garbage sorting initiative has taken root, we are still actively encouraging sorting and recycling with every new team member. For people who have unknowingly thrown away garbage most of their lives, it is difficult to rebuild and start washing used containers. Old habits die hard, as they say. But every month the amount of garbage in the bins is shrinking, which means that the initiative has had its intended effect. In general, this can be considered a good sign. In fact, it is especially gratifying when we see someone implement sorting in their daily life and pay attention to this at home.

In general, so far, our efforts are paying off. We will continue to motivate ourselves and others, because if we don’t take care of our planet, who will?

|

Case Study: How creating a startup improved the education system

Over the past ten years, the number of educational startups has grown immensely. We understand that interest in developments in the field of education is directly related to digitalization. As such, we decided to share one of the recent case studies related to the educational system in Germany.

You never know for certain where a problem will arise, and what will delay the release of the MVP (Minimum Viable Product) for presentation to investors. Inevitably things change, and more often than not they change more than a few times. These changes can start with the MVP itself and end with changes in the goals of the project.

 

Let’s analyze the situation

Let’s say there is a client with a fixed budget, tight deadlines, and bloated functionality. 

Prior to the investor’s arrival, there was a clear deadline for the implementation of the MVP and its demonstration to investors. But without the investors, further, development was impossible, because a large chunk of work was related to the development of APIs (Applicable Programming Interfaces) for providing third-party services. The API itself was very crude and untested, and funding was needed to perform necessary tests and adaptations.

Thus, the work had not yet begun, and things were already getting tense.

This is how the development of an educational startup, “My German University” began. It started as a web application for students looking for a master’s degree program in Germany.

 

There are no unsolvable problems, there is only a bad BA (business analysis)

Before connecting all resources, our Business Analyst, based on client prototypes, formulated a brief for “User Stories”. 

It was with a short and understandable description of the functionality in hand, that we were able to define a scope. After that, our experienced Project Manager formulated a task prioritization and a tracking plan for all intermediate stages of work.

To keep the project within the budget and finish on time, we proposed simplifying the non-critical functionality. This allowed us to create a working application that could be easily demonstrated to interested parties.

To optimize budget and speed up development, we used an iterative approach with weekly sprints and releases.

 

We know what to do and how to reduce risks

In the beginning, we warned the client about the risks of integrating third-party services that do not have documentation for their API, and whose actual performance is unknown. We discussed the risks of changes, clarified the requirements, and potential adjustments.

After assessing all potential risks, we took responsibility and started development. For continuous monitoring, we proposed a task tracking system and regular meetings, and in the end the project was a huge success.

 

Eventually (In the end)

In the end, having won in early 2020 InnoRampUp (IFB Innovationsstarter GmbH), one of the most attractive government grants in Germany – the company moved from Berlin to Hamburg. 

According to their website, in May 2021 the number of unique search queries exceeded 237 thousand, and the number of views approached a million, while the viewing time was 05.08! The number of current programs has grown from 1660 at the time of launch to 2231, and 30 universities have already signed an agreement to provide unique offers to students.

We are proud to be involved in the success of such fulfilling projects, this creates a passion for us to continue to take on new ideas and improve our own skills.

 

|

Case Study. TeamOutLoud: Facebook for Employee Recognition

Project

TeamOutLoud is a social app for companies (hotels, in particular) with a powerful employee engagement system. Just like in LinkedIn or Facebook, employees here are able to evaluate professional and interpersonal skills of each other, post news and comment other updates, add and take photos of their work activities. The app is dedicated to increasing employees engagement, retention, and happiness.

Problem

The end customers of our clients once came up with the problem. They had an idea to create an app that could solve it, so they came to us, as we already have some cooperation with them. The app should be a simple, user-friendly tool to involve employees into evaluating skills and build a friendly corporate culture, leveraging the human resource potential. What was required to consider is:

  • The quick result to test the market;
  • A convenient interface for users not to waste time on the functionality search;
  • A quick response, as it is a social app connecting people with one another. It was extremely needed to shorten the timeout and show new info immediately.

Solution

  • We decided to make a PhoneGap application. PhoneGap reduces application development time for iOS and Android to 30%.  Our company has worked with PhoneGap plugins before. It also allows reducing the budget by 20-25%, which is important for startups.
  • Standard patterns for unique solutions.
  • Firstly, as we had a considerable experience working with AngularJS, we started designing the solution using this framework. However, its efficiency didn’t match project needs. To make our social app operating as quickly as Facebook, we developed our own ReactJs-like library. Such a solution made it possible to build an in-app news feed quickly and show the changes instantly.

Result

TeamOutLoud is already have a rich success story. It is used by The Ritz-Carlton, Corinthia, Intercontinental, Sheraton hotels and serves more than 6000 users in total. IR is a development partner of the TeamOutLoud startup featured at WebSummit 2015 in Dublin, which then proceeded to the pre-accelerator stage and finally to startup accelerator which takes place in Lisbon in November during Websummit 2016.

|

Case Study: How To Simply Add A Static Page To The Navigation Menu in Magento

Magento is a perfect solution for E-commerce. There are plenty of features included to meet any requirements and needs of sellers. However, there is a problem when displaying common static pages, such as the About Us and Contact pages, which is called CMS pages in Magento.

There is an option to edit and add them in the Admin panel, but when a user needed to display links on the main navigation bar, there was a problem.

It was impossible to accomplish without code customization, which required a great deal of time and effort. Given how frequently we were asked about this type of development, we decided to create an extension to simplify the process.

The solution we found is based on using a catalogue categories menu, which allows one to render CMS page links and titles instead of category link and category name. To ensure user-friendly management, we reached a solution of adding a new tab to the CMS page edit section following the Meta Data tab. Our custom tab contains a categories tree, like on a product edit page in categories tab, so we can assign a CMS page by clicking checkboxes on the tree nodes. We had to completely rewrite the cms/page model and implement our custom “after save and before delete” logic.

At first sight, it would seem that all we need is to create a reference to cms_page_edit_tabs  block and insert our categories tree inside. However, tabs in the product edit page and cms page edit page are different. We could not use the adminhtml/catalog_product_edit_tab_categories block as a tab in the CMS page edit, because it requires that the tab block calls  the Mage_Adminhtml_Block_Widget_Tab_Interface interface, but the catalogue categories tree doesn’t implement this interface. Therefore, we created a custom adminhtml block and extended the categories tree block. Then, we overrode the methods specific for categories tree view.

We’ve spent about 80 hours on development, but now it will only take a few minutes to install the extension. It creates a new tab in the edit section, where an Admin can simply assign a CMS page to a selected category without using any URL rewrite management or redirects. Moreover, this extension supports multiple stores, which is quite important due to its growing popularity.

If this is something you were looking for, please visit the Itera Research account on Magento Connect

 

Sincerely,

Itera Research team

|