Project stages


Initial inspection

Often, customers underestimate the importance of the initial project steps, which are the initial inspection (in fact – acquaintance) and description (understanding) of the current and future business process.

However, sometimes this stage can play a key role in shaping final requirements, and sometimes radically change the approach to implementation.

During the initial inspection, it is important for us to understand what business area will be automated, what place this business process in the overall structure of the company takes, what impact it has on related processes.

Also, this stage shows the general purpose and main goal of automation.

One of the most common mistakes in companies is the desire to automate a single task, not entire business process, which is inherently much wider, and perhaps goes beyond the structural unit making decisions about automation.

If a customer doesn't have an "architect" who can assess the needs correctly and set clear goals, the experience of our company can be very useful.

"Smart-Com" assigns a project Manager who will manage the entire process from beginning to end, meet periodically with customer representatives, adjust requirements, coordinate documentation changes, and discuss financial issues.

For the customer the project manager the only point of contact linking all the structures of the contractor.

AS-IS and TO-BE Business processes description

A unique feature of companies (even sometimes large International market players) is maintaining actual descriptions of their existing business processes in any form convenient for analysis.

Often it turns out that even if processes are described and documented, during implementation, in six months these descriptions become irrelevant (or at least inaccurate).

If we are mean any project, impacting key business processes dramatically, the process description at the initial stage is vitally important.

Usually it is carried out by "Smart-Com" analysts together with customer's key users who can describe the main process elements, their relations, the structure of interaction, the terms and regulations governing these processes, as well as the main participants in the process. As an output there occurs a document, confirmed by a customer this document becomes a starting point for the development start.

The second important element for the development start is the definition of the project final point or the project outcome.

In other words, it is a business process description that the customer wants to see at the end of the project. This is a kind of" ideal picture" aspire to. Close interaction with the customer is also important at this stage.

Sometimes after all the changes imagined the process may simply not be implemented for various reasons.

For example, a client wishes to have analytic report depending on many parameters in a system but does not have enough resources to input these parameters (or does not have integration with other systems).

Or the Client wants to get a high level of process automation but doesn't have enough fund for the hardware components of a system.

Functional specification development

A functional specification is a formalized description of a software product explaining what the system will do on certain a basis.

The functional specification answers the general question "what we implement", shows the structure of all modules and their interaction, taking into account design terms.

Typically, this document is not overloaded with technical details and describes system functions at the business level.

However, the creation of such a document can only be done by an experienced Project Manager.

Functional specification typical components:

  • The project basic information;
  • Project justification;
  • Assumptions;
  • Roles;
  • Procedures, restrictions;
  • Implementation requirements;
  • Data storage requirements;
  • Reporting requirement;
  • Interfaces;
  • Test scenarios, etc.

It is important that the Functional specification described all the requirements for implementation, and, outlined the project scope.

In other words, it should describe what is a part of the project and what is out of project scope. For example, if customer needs to transfer data from the old system to the new one, this should be specified.

Proper functional specification is the key to a harmonious relationship between the customer and the developer.

The customer will never be able to require more than it is written in the specification, and the developer – to perform less than it is supposed there.

On the contrary, the absence or poorly detailed functional specification is a possible cause of subsequent disagreements.

If there is a customer project manager in the organization, our experts help to formulate the implementation requirements to describe them correctly, point out the shortcomings in the specification, give other useful recommendations.

If necessary, we can provide the Functional specification development entirely. The final document must be confirmed by the customer.

Technical specification development

Technical specification is a technical document specifying a set of special requirements for the system and approved both by a Customer and Developer.

Technical specification answers the general question "how we implement", often contains system, architectural and testing requirements, describes in detail the structure of all modules, if necessary, the formats of interaction with existing systems modules.

Typically, technical specification is a product of interaction between the IT structures of the customer and the contractor, appearing after the formulation of all business requirements.

Mandatory components of the technical specifications according to GOST are as follows:

  • General information;
  • Purpose and objectives of the system;
  • Characteristics of automation objects;
  • System and implementation requirements;
  • Project composition and content of the work;
  • Control and System acceptance terms;
  • System technical requirements;
  • Documentation requirements;
  • Sources of development.

In an organization with a complex IT-infrastructure, the involvement of customer IT-specialists at this stage is simply necessary.

Small companies having installed standard software or, for some reason, not having their own IT-specialists, can involve "Smart-Com" experts to the technical requirements development.

During this stage, our specialists will conduct an additional existing systems inspection and offer you the best option for integrating the new system or module into the existing infrastructure.

Development

After all the previous steps, the development process itself starts.

The approved functional and technical specification gets to the Project Department, where the project gets the Lead developer, as well as the necessary resources.

"Smart-Com" company uses a modern project management methodology.

For the development process, we apply advanced SCRUM methodology, which allows us to apply the most effective approach to the development and control of the software product.

The essence of this method is the split of the whole project into a set of quite small tasks, their distribution among programmers and allocation of a short period of time for their implementation.

This period of time is called Sprint.

Usually it takes from 1 to 4 weeks, depending on the task size, and is rigidly limited in time. After each Sprint, the Lead developer (sometimes together with the Project Manager) monitors the completed tasks, the results, and, if necessary, makes adjustments to the next steps.

Essentially, a Sprint is one iteration in SCRUM, during which we develop a software product constantly.

SCRUM is often referred to as the "agile software development methodology".

Advantages of this approach:

  • Continuous individual tasks timing and quality monitoring;
  • Understanding the overall project picture, timing the project as a whole;
  • Ability to demonstrate the separate functionality performance to the Customer;
  • Getting feedback already during development;
  • Timely changes in the course of the project;
  • Reducing the number of errors due to their early detection.

In addition, for the developer it also provides internal advantages, such as:

  • Effective organization of the team and each of its members;
  • Building effective communication among the team members;
  • Ability to evaluate the individual employees’ performance;
  • Simplify the entry of newcomers into the team due to the clarity of the process.

Implementation Support

The logical step after the development complete is the stage of the system implementation into production.

At this point, the ready-to-implement version of the system is deployed to the customer for testing*.

Upon agreement, the "Smart-Com" specialists can develop user and system administrator manuals, other supporting documentation, as well as conduct training the customer's employees.

Testing is usually carried out by a dedicated group of the most competent key users, who are able to describe a problem or error correctly and submit it to the developer.

In most cases, testing is performed according to the scenarios specified in the Functional specification. In addition, special tests or tests under certain conditions can be performed (e.g. loading testing).

Ideally, if these steps are specified in writing technical specification (paragraph "System control and acceptance").

Usually, all the problems and recommendations identified at this stage can be divided by the following groups:

  • Errors, "bugs" — small or minor errors in the system that the Developer can be fixed easily at its own expense before the system deploy into productive operation;
  • Critical errors (also called ”show stoppers") — errors when the system operation is impossible or does not make sense. This can be both incorrect software implementation or design gaps that were not considered in describing the TO-BE process. Such errors should also be corrected before the start. Often, they delay the system startup in operation;
  • Non-critical errors — errors that do not affect the overall system performance, but allow it to deliver its main results. However, they can affect some secondary processes or reduce the user’s efficiency. Typically, these errors are prioritized and corrected after the system startup;
  • Improvements — wishes, suggestions, obvious ideas that improve the system, increase its efficiency. They should not delay the planned start and are usually implemented within the CIP (Continuous Improvement Process).

After the end of testing, the decision on the startup date is agreed between the Customer and Developer teams.

However, there are a number of activities that need to be completed before this event:

  • Production infrastructure installation and configuration,
  • Input or import of master data (if necessary, other information),
  • Roles and users setup,
  • Employee training,
  • Support model agreement and more.

The key point in the implementation of any new process in the company is the participation of senior management.

The fact is that any processes changes in the organization are invariably faced with the resistance of employees to these changes.

And the deeper and more radical changes are implemented, the higher the probability and strength of resistance.

Overcoming these changes is usually not within the duty of the developer and, moreover, is not within its authority. Therefore, at this stage, it is very important for management not only to eliminate resistance to changes, but also to ensure that the new process is not just formally established, but the system would be accepted by the organization staff and become a new reality.

*In fact, as it is indicated in the "Development" section, the customer has the opportunity to get acquainted with the individual system modules or part of it at the development stage. When using the SCRUM methodology, demonstration of the functionally completed modules takes place according to availability of the product. This allows considering some Customer requirements and making adjustments to the process, without waiting for the full completion of the entire development process. .

Further support

System startup and the beginning of its productive work is the key stage of the project.

And here it is important to take care of the future - technical and functional support.

Functional support is usually provided by the Customer itself.

Even before the start support structure, which is essentially the center of expertise should be approved. It is usually a team that includes functional experts and key users.

Its structure is determined by the size of the system and its criticality. The main functions of this team are training and support of end users, the first line of support, escalation of problems, making proposals for the functional development, their implementation.

Technical support is provided by customer IT-teams and is aimed at maintaining the system performance throughout its operation.

It consists of periodical maintenance works (a complex of operations on software check and update), system troubleshooting, issues escalation to the Developer.

The most effective (and most common) way to support has a three-tier structure:

  • Level 1 — Functional experts, Key users;
  • Level 2 — Customer IT-department (if exists);
  • Level 3 — Developer support team.

All the internal "calls" go to the first level. Here they classify and filter all the issues.

Usually to solve the user's problem the elementary help of the expert is enough.

In practice, about 70% of incoming "calls" are solved at the level of Functional support. If necessary, the problem escalates to a higher level.

The customer's IT service "localizes" the problem, thus again performing filtering. From the point of view of technical expertise, they clarify the cause and place of its occurrence. If the problem is not inside the local infrastructure, the problem is passed to the third level.

"Smart-Com" has its own technical support service

Our specialists register incoming problems using various methods (phone, e-mail, special tools, such as TFS) and forward them to the technical experts.

Working on the problem resolution, support specialists notify the customer about the current status of the issue.

All incoming "calls", root of issues, their resolution, as well as all the results are noted in a separate system, which allows to assess the level of service and service efficiency after the reporting period.

The support availability, problem resolution time and the scope of maintenance works are determined by a separate agreement, which describes all the conditions:

  • Support model, operation hours;
  • SLA (Service Level Agreement) - maximum time to resolve an incident;
  • Release management (new versions deployment);
  • Planned system shutdown;
  • System monitoring;
  • Consulting.

The required level of support is determined by the customer, and usually depends on the operation requirements to the system and its criticality for the work of the business unit.

We create effective IT solutions in different business areas