Tag Archives: Project Management

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.

 

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.

 

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

 

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