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 will try to state the options for the answers that he generated.
About myself
9 years - SAP ERP IT consultant. Responsibilities: design, team building, testing and debugging, training, piloting.
Applicability framework
He wrote based on projects from 3-4 months to 1 year with complex intersystem integration.
Having decided not to risk drowning in the achievement of perfectionism, having lost the initial passion for writing, I had to abandon the 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 the texts that were consonant on the topic before publication.
Therefore, to a certain extent, I am counting on commentators to, possibly, write a second edition, in which the above criteria were already at the proper level.
Glossary
BA - business analyst
BZ - knowledge base of the
BT project - business requirements
IT - architect and consultants of the project team
KP - key user
MK - junior consultant, enikeyschik
PR - design solution
Prod - productive system
Razrab - developer
ST - test scripts
SK - senior consultant,
TK designer - terms of reference
Keys to IT Project Success
The general message is smooth communication
It is necessary to achieve synchronicity between business and IT in the perception of business requirements, test scenarios, design solution and how it will look in implementation.
Detailed and thoughtful BT
BT must have a complete and synchronous understanding between business and IT. To do this, it should be BA and CP (ideally, when BA is a former CP).
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 in order 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’s 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 up to date:
- SK writes to the developer about the adjustments and puts the MK in a copy
- MK collects and reflects changes in edit mode using versioning
- SC accepts edits
- MK updates the documentation in the KB
Testing should also be delegated to MC.
I don’t know how it is outside of SAP, but the consultant-harvester principle is often used here, which does everything (design, testing, writing documentation).
As a result, quality, terms (and “money”) suffer and risks associated with everything being tied up for 1 person.
Testing Scripts Before Release
- Testing should be carried out in an environment close to the production (ideally in a copy of the sales).
- The participation of people who will directly work with the functionality is obligatory (it is advisable to conduct an educational program by decision before that).
Common space for teams integrating systems
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 one room. Otherwise, you need a separate person or a convenient tool that would provide synchronization between teams.
Host Technical Adequacy
Formal approval of the PR by the business is the scourge of the project. The receiving party must fully and in detail imagine the solution. If the project concerns a 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 an impulse, there is an idea to describe the problems that may arise if the described recommendations are not followed.