Month: September 2023

How to NOT RUN SAP Integration Project – Case 1

“Once upon a time…” a Huge Client, hired a Huge Consulting company to run their cloud integration project. The consulting company did not have all necessary resources, therefore they hired a cloud consulting company, and since the cloud consulting company did not have integration resources available, another company was hired to run the integration part, between on-premise system and the cloud. Both data migration and replication were in the scope of the integration part. Adding to that, Huge Client had not a department, but an IT department that was turned into an IT company, and they were responsible to oversee the project on behalf of the Huge Client. Just so you don’t loose track of all stakeholders involved, I’ll list them below.

  • Huge Client
  • Huge Client’s IT Division
  • Huge Consulting Company
  • Cloud Consulting Company providing cloud implementation experts
  • Consulting Company providing integration experts

With that in mind, project was initially started, with goal of 4 to 6 months implementation until the go´-live. I joined this project after 6 months it was started, and at this point debut date had been rescheduled once. Initial impression when I started was ok, everyone very engage. Two weeks later, in a daily meeting I got a little surprised, between PM of Huge Consulting giving a small speech that “hey, if you’re in the call and not talking, I don’t need to say that you must continue working in whatever subject you’re working”. From these day on, I started noticing small advices” from this PM that to my point of view were very unnecessary, adding more bad feelings than good, especially looking at the level of professionals involved. A few days later in there was a small discution between PM 2. In another “moral” speech it was said that team was lacking commitment to the project, how could the project could be delivered if people were responding timely all questions being sent by business users, etc. On this day, lead consulting of Cloud Consulting Company argued that her and her team had been fully dedicated for the past six months or so, working multiple weekends, therefore it was not lack of dedication, and they also needed to rest. PM2 took a step back trying to fix what she said, saying that they were in a key point of the project and a “final” push was necessary and so on. At the end of this meeting general feeling was bad, including for me who had just started.

Punch bag of the day

You never expect to be the punch bag of a meeting in a project like this, but it’s just a matter of time.

Weekend tension

Weekends started to be for me much more appreciated than ever. I would not know if I would be called to work until the end of Friday mostly.

They are also victims

PM1, PM2 and maybe PM3 are also victims of situation that seemed to spiral out of control. They were under immense pressure from the Huge Client, who was eager to see results and probably expected a seamless transition to the cloud.

The initial optimism had given way to a series of unrealistic expectations, combined with a complex web of subcontractors. Each company brought its own set of priorities, timelines, and resources, leading to a clash of interests. The project’s complexities had surpassed what anyone had initially anticipated.

To be continued…

Junior vs. Senior: Sharing Personal Mobile Number in the E-mail Signature

In the fast-paced world of software development, emergencies can strike at any time. When a critical issue arises, it’s essential to have a reliable support system in place. This often leads to a crucial distinction between junior developers, who are typically more willing to share their personal numbers for emergencies, and senior resources who might be more reluctant.

Junior Developers: Eager to Help

Junior developers are often filled with enthusiasm and a strong desire to learn and contribute. They recognize that sharing their personal contact information for emergencies can be a means to learn and grow in their roles. Here’s why many junior developers are willing to be on-call:

  1. Eager to Prove Themselves: Junior developers understand the need to prove their worth in a competitive field. Being available for emergencies is a way to demonstrate their commitment and reliability.
  2. Learning Opportunity: They see emergencies as learning opportunities. By facing critical issues head-on, junior developers gain valuable experience and problem-solving skills.
  3. Building Trust: Junior developers aim to build trust within their teams. Being available during critical moments helps establish credibility and fosters good relationships with colleagues.
  4. Sense of Responsibility: Many junior developers feel a strong sense of responsibility toward their work and the team. They genuinely care about the success of the projects they are involved in.

Senior Resources: Balancing Experience and Boundaries

Senior developers and resources, on the other hand, often have more experience under their belts. This experience can lead to a different perspective on sharing personal numbers:

  1. Work-Life Balance: Senior resources have typically experienced the toll that constant on-call availability can take on work-life balance. They may be more protective of their personal time.
  2. Delegation and Trust: Senior developers tend to delegate tasks and responsibilities to junior team members. They may trust their colleagues’ abilities to handle emergencies without their direct involvement.
  3. Prioritization: With experience, senior resources are better at identifying and prioritizing critical issues. They may feel that their intervention is only necessary in the most severe cases.
  4. Mentorship: Senior developers often prioritize mentorship and guiding junior team members over handling emergencies themselves. They see value in empowering others to handle these situations.

Balancing Act: Bridging the Gap

To foster a productive work environment, it’s crucial to strike a balance between the enthusiasm of junior developers and the experience of senior resources:

  1. Clear Communication: Encourage open communication within the team regarding on-call responsibilities and expectations. This clarity ensures that everyone is on the same page.
  2. Rotation System: Implement a rotation system for on-call duties. This allows senior resources to share the load while giving junior developers opportunities to learn.
  3. Mentorship: Senior developers can use emergencies as mentoring moments. They can guide junior developers through the process, imparting their wisdom and experience.
  4. Respect for Boundaries: Respect the personal boundaries of senior resources. Acknowledge their expertise and allow them to step in when truly necessary.

In conclusion, the willingness to share personal numbers for emergencies varies between junior developers and senior resources. Junior developers often embrace this responsibility as an opportunity to grow and prove their worth, while senior resources may be more cautious due to their experience and a desire to maintain work-life balance. Striking a balance between these perspectives is essential for building a cohesive and efficient development team. By fostering open communication and mutual respect, teams can leverage the strengths of both junior and senior members to navigate the challenges of the ever-evolving IT landscape.