This guide tries to answer the questions bothering many programmers with certain baggage of professional experience who want to continue their professional path towards managing both development projects and project teams. Repeatedly playing the role of the leader of the development team, I lacked information, advice, or suggestions on how to solve emerging problems regarding the team itself, budget, project scope, or knowledge. I came up with most of the answers on my own, so I will try to at least partially suggest what to pay attention to, to become an increasingly effective ABAP leading consultant and a programming team leader in SAP development and implementation projects.
Establish the rules of cooperation at the very beginning
If you build a team that you will lead, try to choose the most competent people in terms of the budget you have.
The advantage in the team of people with a lot of knowledge supported by many years of experience may result, on the one hand, in more interesting ideas, and, on the other hand, may cause conflicts when building a vision of a solution. Additionally, employing highly qualified employees entails adequate costs. In turn, the team consisting mostly of juniors means lower costs, but longer implementation time of extensions and the need for increased substantive supervision.
As soon as possible, arrange a kick-off meeting with the team. If they don't know each other, introduce the team members to each other and then set up rules of cooperation and communication, both between them and with you. Pay attention to the precise definition of reporting rules (when, what, in what form) and for reporting problems and threats. Remember about the risk of not completing the work on time and within the assumed budget. Don't be afraid to introduce your own rules, even harsh or demanding. If you are a leader, be a leader!
Zig Ziglar: "You cannot act in a way that is not who you think you are".
Study business requirements and participate in the development of functional specifications
One of the first parts of any implementation or development project is the meeting of end-users or business experts to understand the business requirements that must be implemented in the SAP system during the execution phase. The best way to collect all business requirements is to conduct a workshop. Make sure that if a given SAP module is implemented, a consultant from that module will be involved in such meeting. Once all business requirements are collected, SAP module consultants and/or business experts will create a detailed functional specification. Be sure to read all such specifications.
Make sure that the documents provided by consultants contain all necessary and identifiable technical details, various business scenarios, and clearly defined expected goals. A well-defined functional specification document, in addition to the description of processes, should contain diagrams in the form of UML diagrams and test cases. Such a document must be agreed upon and signed by the client before the next steps of designing and implementing the solution.
Don't be afraid to send your consultants back badly written specifications! Remember that you are personally responsible for providing a solution according to what they prepare.
Prepare a document of programming standards and naming of ABAP extensions
The creation of the ABAP extension programming and naming standards document is a mandatory task of the ABAP development team manager. Prepare such a document in the form of a guide, in which you include all standards and guidelines for creating programming solutions, printouts, or interfaces. Such a set should contain established naming conventions for all created programming objects that will be used in the project, i.e. design classes, programs, function modules, classes, ABAP dictionary objects, namespaces, etc. Additionally, the document should contain the rules of code modularization depending on the complexity of the solution.
It is a good practice to create a program template with comments and predefined sections (subroutines, events) and to establish the naming rules used in the program code (setting variable prefixes, parameters, names of procedures, and subroutines, etc.). Remember to pay attention to the team to comment on the code fully and clearly. This is especially true for larger teams that often work on the same facilities in the system. On the one hand, establishing a naming convention helps to maintain a consistent approach to programming, and on the other, it helps other developers and functional and technical analysts to decode and debug the code.
If the implementation company you represent has established and proven programming standards, use them naturally for design purposes.
Andrzej Majewski: "The fewer rules, the easier it is to abandon them".
Assign the appropriate competencies to specific tasks
An important element of the success of a programming project is the adaptation of competences understood as the ability to use skills and knowledge in practice, fully sufficient to independently perform a specific task in the project. Proper use of a person's competencies in project activities translates into the degree of achievement of that person's goals, which in turn affects the degree of achievement of the goals of the entire team, and going further - the entire project.
To concretize - use highly qualified people to design the architecture of solutions, analyze applications or more technologically advanced transactions (e.g. fully object-oriented) or create highly specialized complex client extensions. The knowledge of the specifics of the involved system modules, in particular the logic of the operation of the points of contact, which integrate processes both between modules and between SAP and external systems, plays a significant role here. Unfortunately, people with the lowest competencies are doomed to create simpler reports or printouts.
In the case of larger solutions, consider whether it is worth dividing the task implementation among several people. Assign easier subtasks to juniors, more difficult and integrating to consultants with more experience. Note that too much fragmentation of tasks is not conducive to speeding up the implementation of the whole thing. I know from my own experience how uncomfortable it was for a dozen interlocking programmers to work on one transaction...
Henry Ford: "No task is particularly difficult if you break it down into smaller subtasks".
Take care of an additional incentive budget
A manager without an incentive budget is like a striker without one leg. He has to flex well to achieve his goals. But why make your life difficult? Ask the project management team for the so-called incentive budget. However, if the design procedures do not provide for this, and you do not have sufficient clout, you have to find it yourself.
Analyze your budget as a whole. Collect all the tasks and scrupulously assess their actual effort. Find out among functional consultants and programmers or check-in your previous experience whether someone has not carried out similar tasks in the past - maybe they have an almost ready-made solution that you only need to adapt, and you will be able to save.
Before handing over budgets for individual tasks to team members, adjust each of them by 10-15% and create something like a reserve. Why all this? In the project cycle, there is usually a moment when, in the multitude of tasks and impending deadlines, some team members begin to complain about their fatigue and the enormity of work they have had to do. In particular, when the situation requires working overtime or on days off, motivation drops drastically. It is at this point that you should use the reserve budget and motivate the team to work hard.
Oliver Wendell Holmes: "We have to sail sometimes downwind, sometimes upwind, but we must sail, not drift or anchor".
Meet with your team regularly
Regular (e.g. weekly) meetings of the leader with the team are aimed at taking care of several important aspects of the cooperation of its members improving the effectiveness of the group. First of all, they improve communication within the group, allowing each of its members to express both fears and doubts on the forum, as well as share positive impressions of the solution being developed. At the same time, such meetings should identify any difficulties encountered by programmers, especially those less experienced. You, as a group leader, can guide such people by using your knowledge and experience. You can also assign them a more experienced 'tutor' and define the scope of the support provided.
In the process of team integration, it is important to build trust between its members, which leads to an open and relaxed atmosphere within the group that favors the generation of more creative ideas.
The meetings are also aimed at setting further goals (tasks) and controlling their implementation. Make sure that everyone contributes equally to the achievement of the common goal, which is usually the timely and high-quality completion of design work.
At meetings, establish and clearly express roles and responsibilities, especially when several people are working on one solution.
Guy de Maupassant: "Meeting people makes life worth living".
Set short and long-term tasks. Prioritize.
At the beginning of the project, build a tool with which you will be able to determine the status of your team's work at any point in the project. Project management often asks these questions when they least expect them. This tool can be, in its simplest form, a spreadsheet - we include a list of prioritized tasks, deadlines, and assigned supervisors and contractors.
Try to track the performance of individual tasks by assigning responsible persons periodic reports on the progress of work. Remember to check both the degree of implementation of the task (e.g. percentage) and the use of the budget of a given task, as these two parameters do not always go hand in hand.
Before starting the implementation phase, try to determine the commitment of each team member and communicate to everyone how much workload they will be over the long term. Then assign short-term tasks at subsequent meetings. I do not recommend assigning all short-term tasks simultaneously at the beginning of the project. There are situations when the programmer does not start with the tasks with the highest priority, but with the tasks that he considers the easiest to perform. The second negative situation is the parallel implementation of several tasks, which does not allow you to focus on the quality of the work performed.
Of course, you can define substitute tasks, e.g. in the case when you have to wait for a consultant or client to specify the specification. However, remember to clearly communicate this to the person performing it.
Tim Ferriss: "Lack of time is really a lack of priorities".
Make sure to commit changes to the scope
The task of the ABAP team manager in the project is to ensure that any changes made to the scope of development tasks are approved by the client before implementation. If you take care of the appropriate signature on the document that will be the approval of a given extension or development task, it will certainly help you synchronize tasks with both other implementation teams and the project management. And this, in turn, will have an impact on keeping your part of the project within a defined time and budget.
Julio Cortázar: "The only thing unchanging about a person is his willingness to change".
As an ABAP developer, you must have encountered technical problems more than once. If possible, try to help less experienced teammates. Answer the questions, and if you do not know the answer immediately, analyze the problem and indicate possible solutions to it.
Look out for inexperienced people who ask nothing or say they have no problems. It doesn't mean that they know everything and their work goes smoothly. Take the initiative and check the progress of their work yourself. The cost of reviewing the code and testing its optimization and performance at the design stage is much lower than later, in the testing and patch phase, and even worse after the productive launch.
It is a good practice to schedule short meetings with less experienced people to review their code. You can run them yourself or appoint senior consultants for them. Remember that they are not intended to show young programmers how little they still know, but to help them develop faster and ensure their work consistency and efficiency.
Wiesław Trzaskalski: "Sometimes you give someone a helping hand to keep them in your hand".
Think about yourself
An important element of managing the implementation of tasks in the project is communication with superior authorities, i.e. project management. If we are dealing with a smaller development project, you can be the unit in direct contact with the client.
As a person responsible for the timely and quality delivery of the product within the assumed budget, you are obliged to take care of the above aspects. Remember to ensure proper and timely communication with the project management and the client at every stage of the project.
If you are unable to resolve problems yourself or meet the deadline, stay ahead of the facts and inform your superiors. If you lack any information to complete the task, ask for the specification or concept details as soon as possible, preferably in writing (e-mail). If you do not receive a response on time, consider escalating the problem to a higher level immediately. Create notes and protocols from meetings in which you can include deadlines and assign people from outside your team responsible for carrying out tasks. Monitor the execution of tasks by these people.
Albert Einstein: "Protecting from lynching is one of the most pressing tasks facing our generation".
Don't distract the team
The worst thing that a team leader can do is keep drawing team members away from their tasks. With tight deadlines remind you of their workload, don't make your people spend too much time reporting on the status. Let them run. Do not mix phases - when we create a solution, we create, not test or document. The exception is when, for independent reasons, we do not have complete information to continue working on the tasks. Remember that everything has its place and its time.
Take care of the documentation
If you have prepared an appropriate template for project documentation in advance, your task is only to ensure that it is filled in by programmers at the right moment in the project. Check the substantive content of each documentation. Put yourself in the shoes of someone who will continue to work on a solution based on the knowledge contained in the documentation. Based on this document, will you be able to understand the solution and easily make further changes?
I have come across dozens of different technical documentation forms. From complicated, containing a place to insert the program code (why move the code available in the system into a document?), to very simple ones, in which a few sentences about the solution are enough (will these few sentences help someone understand the technical aspects of the solution?).
The best solution is the golden mean - a technical description with a list of created/modified objects, at most with meta code elements, about the problem (extension) in functional terms. In other words, show clearly what the solution is to serve and in what situation, and not just focus on the technical details of the solution.
The above points, of course, do not exhaust the topic, and some aspects of management barely touch. I also intentionally did not include some of the more obvious points, but at the same time, less important to me.
About the author
Marek Garbacz - Director of the SAP SI-Consulting Technology Department
For several years he has been participating in SAP system implementation projects for various industries, acting as both a programmer - senior ABAP consultant, a developer team leader, and a leading ABAP consultant. Several times he was the coordinator of the implementation of programming solutions based on SAP technologies, as well as solutions, several of which can be described as products. He has also experience in managing technological projects.