Tag Archives: Project Management

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

 

|

How our Developers Provide the Project Estimate

In over ten years of existence we’ve picked up a fair share of expert knowledge on many different projects. This makes our team of over 50 developers and systems administrators all highly experienced and dedicated professionals. All of whom possess Brainbench, Retratech, MCP, RHCE and MCSE certification and are backed by an expert, PMI/UPMA certified management team.

Why is this important when it comes to an accurate quotation that genuinely reflects the quality and complexity of work you require? When using inexperienced developers (or those with irrelevant qualifications), they will almost always send back a quote that – when broken down – shows a lack of understanding for the project’s wants and needs in terms of their time and expertise. This is often down to a lack of confidence on the part of the ill-experienced contractor that ultimately means large risks on the part of you – the client. This is true with all kinds of freelancers and contractors that lack the skills and quality to provide the assurances you need to make sure your project comes in on time, on budget and to your exact specifications.

A similar problem can occur with lone freelancers, who may have the relevant skills, but not the time to properly dedicate themselves to a project; once again leading to costs over and above the original estimate.

Conversely, a good developer, working with a strong team can accurately match and compare the skillset of the team to the various aspects of the works. Assigning various packages to the most suitable and able members regardless of experience, common problems that can affect project estimation will always include:

  • Simply extending and building on a previous project, meaning a break in code and unity,
  • Integrating unknown third party services to another API with unreliable updates and patches,
  • Unpredictable system behavior once the changes have been made,
  • Complex custom tasks for niche markets, and the difficulty in finding people with the right experience.

This wide gap in experience and quality is generally the reason behind the discrepancy in estimated costs you may see. Contractor “X” may have offered the cheapest, but have they covered all the needs and outcomes you require, furthermore taking into account the points above. These are the questions you need to ask when faced with widely disparate quotes for the same piece of work.

All of these hurdles can be overcome by choosing a highly qualified, and widely sourced team, who take an individual and flexible approach to every client and every job, to provide your quotation. That’s why, by working closely with you, we at Itera Research will always pick the best and most appropriate methodology; as a result all estimates take into account your bespoke requirements.

 

Sincerely,

Itera Research team

 

|

When and Why Do You Need a Project Manager?

While negotiating with our prospects and clients, we were frequently asked about the role and necessity of a Project Manager. We saw that they had the wrong impression of what a project manager actually does and didn’t fully recognize how important of a part project management plays. In order to get all the benefits of utilizing a Project Manager, it is important to identify and understand a situation when one is needed.

Let’s consider several cases.

You have a range of projects

or

You want to create a website or mobile app from scratch.

Please check our previous articles  “How to Start Your Website” and “4 Steps to Starting a Mobile App Development”.

These cases lead to the situation when a Project team or even several teams will be involved. The Project team may include a variable number of members based on the project requirements. For example, a Graphics Designer, Front-end developers, Back-end developers, iOS/Android developers, QA engineers, System Administrator, SEO specialist etc. could be brought in, if necessary. The role of the project manager here is to plan and coordinate work flow in order to make the process as smooth as possible. Some aspects of the project can only be executed one at a time or simultaneously. In a nutshell, the Project Manager’s responsibility is to organize the process efficiently in terms of time and a worker’s ability to accomplish a specific task.

But what if you have several tasks to handle or a list of bugs to fix?

You have a small project.

Isn’t it easier to address the issues directly to the developer? Our answer is a resounding “No”, and here is the reason why.

In most organizations, unless you have a Dedicated team or professionals (more about Business models can be found here), then team members are not assigned full time to any given project, but only part time. Human nature, unfortunately, is such that we tend to focus on the activities that we are reminded of – those that seem “urgent”. In this case, a Project Manager takes control over the work being done on your project so that it gets prioritized above other activities that they have been tasked to do, allowing the project to progress.

The Project Manager’s role in our company consists of handling the overall responsibility for the successful planning, execution, monitoring, control and closure of a project, regardless of the size or scope.

 

Sincerely,

Itera Research team

|