Hello everyone!

After a “hot” piloting last week, the brain apparently relaxed and got hooked on the question: “And what had to be done so that everything went smoothly and without all these nerves?”
I’ll try to explain the possible answers that he generated.

ITKarma picture

About me

9 years - IT Consultant SAP ERP. Responsibilities: design, team building, testing and debugging, training, piloting.

Framework of applicability

He wrote focusing on projects from 3-4 months to 1 year with complex intersystem integration.

Having decided not to risk drowning in achieving perfectionism, having lost the initial fuse for writing, I had to abandon claims to a high level of structure, consistency and completeness. For the same reasons, the text was written only "from personal experience", I did not read texts on the topic before publication.

Therefore, to a certain extent, I rely on commentators to perhaps write a second edition, in which the above criteria were already up to the mark.


BA - Business Analyst
BZ - project knowledge base
BT - Business Requirements
IT Architect and Project Team Consultants
KP - Key User
MK - Junior Consultant, Enikeyschik
PR - design solution
Prod - Productive System
Razrab - Developer
ST - Testing Scenarios
SK - Senior Consultant, Designer
TK - Terms of Reference

Keys to IT Project Success

General message - good communication

It is necessary to achieve synchronization between business and IT in the perception of business requirements, test scenarios, design decisions and how it will look in implementation.

Detailed and thoughtful BT

For BT, there needs to be a complete and synchronous understanding between business and IT. To do this, it should be BA and KP (ideally, when BA is a former KP).

Complete set of test scripts

The maximum number of maximally detailed scenarios should be known and worked out before writing the solution. Scripts should be written, starting from the most common to the rarest. The latter, in the case of their expensive automation, must have thoughtful manual control.

Division of labor within IT

The project team should have a division according to the intellectual complexity of the work. It is good if the designer has the skill, without unnecessary expenses, to style the documents stylistically accurately. Otherwise, it is better to give the guidance of “beauty” to a person with a junior position.

The same applies to the content of TK/PR in the current state:

  1. SK writes to the developer about the adjustments and puts the MK in a copy
  2. MK collects and reflects changes in the editing mode using versioning
  3. SK accepts edits
  4. MK updates the documentation in the KB

Testing should also be delegated to MK.

I don’t know well how is it outside of SAP, but the consultant-harvester principle that does everything (design, testing, writing documentation) is very often used here
As a result, quality, terms (and “money”) suffer and risks associated with the fact that everything is tied to 1 person increase.

Testing Scripts Before Release

  1. Testing should be carried out in an environment close to the product environment (ideally in a copy of the product).
  2. The participation of people who will directly work with the functionality is mandatory (it is advisable to conduct an educational program before the decision).

Common space for integrating system teams

In the presence of complex integration on the project, it is extremely important to create a common field of the project context and ensure “proximity to the body”. Ideally, the entire project team should be in the same room. Otherwise, you need a separate person or a convenient tool to ensure synchronization between teams.

Host Technical Adequacy

Formal reconciliation by business PR is the scourge of the project. The host should fully and in detail imagine the decision.If the project concerns the deep modernization of existing functionality, then the business should know it well.

Ideally, if the host is a perfectly knowledgeable business person with consistent and structured logic.

Pilot moderator

A neutral person for IT and business with the makings of an arbitrator. Builds a piloting plan, draws up test reports, keeps track of comments and their corrections.

If there is a rush, there is an idea to describe the problems that may arise if the recommendations described are not followed.