IT outsourcing: Java, С#/С++, .NET, Python, JavaScript, React, Go

Project for Federal Air Transport Agency (FAA)

Creating a budgeting system for FAA projects (creating, adjusting, approving budget requests)
Objective: to develop a system of project budgeting management
Project website: closed corporate budgeting system.

  • Development of system business logic
  • Development of architecture (microservices) and implementation of server and client parts
  • Integration with external systems
  • Stack of technologies: Java, React, PostgreSQL

Project duration: November 2019-June 2020
Team: 2 business analysts, a team leader, 4 developers

The global task was to automate the budgeting tasks of all FAA departments, namely approval of the budget for various federal, regional and local programs. The initiators of changes conceived a powerful automation, and we joined to a part of its implementation. We were entrusted to develop the sixth stage of this big system (the first five steps have been performed by another contractor). Our task was technically difficult, and we were the 4th team to tackle it. At that time the general contractor was running out of time. In fact, it depended on us, whether he stayed in the project or not.

The business task set before us was to create a process-based system where users on one side could submit budget requests and send them along the approval route, and the budget owner could reject, edit and approve these requests. Requests had certain attributes: to which division it refers, request period (the request can be created now but its execution can be stretched over the years). The totality of these requests should have become filterable budget plans for different departments.

During our time on the project (from November 2019 to June 2020), a detailed business analysis was conducted, an architectural blueprint was produced, and we went through several implementation scenarios. In fact, during this period we created a working system from scratch that could be demonstrated to the customer (a demo version was created).

By the summer of 2020, FAA had changed the general contractor, and the new general contractor came with his large team.  In connection with this, we handed over all the documentation, and all our know-how to the new team. We helped them get involved in the process and brought them up to speed as much as possible.

We started this project with a large team: in the beginning there were two business analysts, a project manager and a supervisor, an architect, a team of 4 developers. In the process of work there remained one front-end developer, one back-end developer, and one DevOps engineer who joined depending on the tasks.

Project specifics

During the work on the project, the important and interesting things for us were business processes of budgeting in the state corporation: how this works, how it is all done manually in a global structure on such a huge territory as the Russian Federation.

As every government project, of course, the work involved a huge amount of documentation. This is why the role of the business analyst was extremely important. His job was to help the development team understand the processes to be automated. Generally, this was the work with the screen forms. To translate all of this into screen forms, you had to read all of the documentation and talk to the people who owned the information about how the automation was originally conceived.

As it often happens, the Product Owner changed priorities in the process. In fact, this is one of the reasons why ITQuick only works according to Time & Material, not the fix-priced SOW. We are willing to respond flexibly to changing conditions. On the other hand, maximum efficiency can be achieved if the team can plan the scope of work for a period of 2 weeks. Changing priorities more often reduces productivity.

Another distinctive feature of this project was the daily consultation with the customer. We were literally on call all the time.

There were complications in setting up the data exchange with 1C, but that was solved too.

For the project transfer to the new general contractor, a large conference was organized, where the system and the scenarios were shown. We demonstrated how a user moves through the stages of budget approval and the corresponding windows, what is available to him, how he can handle data. DEMO. The meeting was attended by the new development team, the general contractor who had been in charge of the work, and, of course, our development team. We gave full access to our documentation, collected and developed in the process of work, they were given access to the program itself, to the source code, to any source files. So we handed over to the new team everything we had developed. In addition, we stayed in touch and gave the necessary explanations. And then the new contractor went on its own.

One of our principles is that ITQuick is ready to transfer all the developments, all source code and other source materials to the customer at any time.

So, we were tasked to create a system where the initiation and all the stages of budget coordination take place. And we have developed this system (most part of this product was created from scratch). And then we handed it over to the next performer as fully as possible without losing any time or data.

Other cases