I had just returned from an assignment in South Africa, and there was another project waiting for me to join as a Project Manager. The senior project manager interviewed me in another ODC, which is where this requirement for a techno PM came from. I have a technical background, but for the past five years, I have focused on consulting and project management. Because of my Project Management experience, I had my PMP certification and was well-versed in project management principles and concepts.
The manager briefed me on the project and inquired about my background; he was convinced and had me start right away. The client was a major Australian bank. The project had only recently begun, and I was given the SOW (Statement of Work), as well as the HLD (High-Level Diagram) and LLDs (Low-Level Diagrams) for the project. It was overly technical and difficult for me to understand. In the Daily Huddle Meeting on the first day, I was introduced to the offshore and onsite teams. The project team began talking, and the technical jargon they were using was going over my head.
I met with my RM (Reporting Manager) and asked him to give me a project overview. He started a session the next day that was extremely high level; I was still bogged down in the details of the project. I summoned the team’s technical lead and senior architect for a meeting and asked them to provide me with an overview of the architecture. The lead provided me with a thorough understanding of Project Architecture, demonstrating over the projector how the various applications and technology interact.
The project was a web services SOA (Service Oriented Architecture) project that required the delivery of code for these services and adapters. If you are technically savvy, you may be able to deduce what technology and architecture were used in this project. I was up to speed by the end of the first week, thanks to daily huddle meetings and team meetings. I began facilitating huddle meetings between the onsite and offshore teams the following week. I began preparing daily MOMs (Minutes of Meeting) in which I recorded individual tasks, daily progress, action items, issues, and dependencies. I created the ‘Action Items Tracker,’ which was to be updated daily and distributed to the team.
Do you want to make a name for yourself in the Project Management field? If so, sign up for the Project Management for Beginners Program right away and take a step closer to your career goal!
I was starting to feel better. My RM increased my responsibilities beginning with the second week. He requested that I send the Weekly Status Report to the Onsite Project Manager from the client-side every Friday and that I hold a Progress Update Meeting with the client PM every week. Furthermore, he handed me a PDF document containing the Project Plan created in Microsoft Project in a draft state. He also gave me a Delivery Schedule format from previous projects, and I had to create the final version of both documents.
Throughout the day, I sat with the team’s senior members to develop the project plan, effort estimates, and delivery schedule. To finalize it, I had to retake it with the team for iteration the next day. It was difficult, so I divided the project into components such as services and adapters, and then further divided it into sub-components such as Design, Coding, Testing – UT (Unit Testing), and ST (System Testing) (System Testing). Under each of these, there were additional tasks and sub-tasks. We developed effort estimates for each deliverable to determine how many man-days would be required to complete each of these activities with the available resources. I assigned start and end dates to each component, sub-component, task, and sub-task, as well as predecessors and dependencies to each of these. I also assigned roles to each of them, indicating who will do what with each of them.
I reviewed my project plan for the major delivery milestones in order to optimize resource utilization and meet the target delivery dates. I devised objectives such as phased delivery of operations and components. Whoops! This week was intense, and I was overly challenged! The project’s execution phase began next. I had twelve offshore developers, two technical leads, four senior design architects onsite, and eight testers. It wasn’t a large team to manage, but believe me, it wasn’t easy either.
We had daily targets and dependencies, the onsite team yelling at the offshore team, poor code quality, daily delays, and so on. A manager must deal with situations, especially when teams are geographically dispersed; the manager must effectively coordinate between teams. Here comes the manager’s quality; I had to handle the conflict in the huddles diplomatically. I went over everything and found the dependencies that are causing the delay. The team relied heavily on input from the client’s SMEs, as well as the design and technical specs provided by the project’s onsite stakeholders.
A dependency tracker would have come in handy here. It was billing time by the end of the month, and the account team got to work. I had to create detailed estimates and actuals for effort and resource costs, complete the Work Order with cost components and send the invoice to the customer. Well, I finally finished it with the help of my reporting manager and input from the onsite project coordinator. Because the project was time-sensitive, team performance was a major concern. Some of the resources were inexperienced and took a long time to deliver; I planned to use senior resources from another project to mentor them.
Another project management overhead was keeping the team’s leave plans up to date. The project used high-end servers and applications, and I had four BAU resources managing it. Another significant challenge was server failure; we had three servers pointing to development, testing, and production. Furthermore, software upgrades, software installations, deployments tracking, and library tracking were not networking overheads, but project management overheads. I used my delegation skills to assign each of these tasks, as well as to update and maintain trackers and report to me on a regular basis. So, I was a little more relaxed when I used this key skill. It wasn’t enough; we had requirements for new onsite and offshore resources, as well as project management overheads such as negotiating resources, managing visas for onsite resources, onboarding new joiners, gaining access to the secured network, raising requests, and closing requisitions.
At the end of the day, it was time to celebrate after the team had put in long hours working late and on weekends, and we had completed the first phase successfully. As the project came to a close, I began preparing to store the project artifacts and documenting the closure documents with lessons learned. The project was completed, and the team was overjoyed with the positive feedback from customers! So you’ve now seen the project’s journey.
I hope this article is useful to many Project Managers who are making their first deliveries. I’d also like to provide you with a list of questions that will be useful if you ever have to go through an interview. How did you handle your most recent project? What were your main project management deliverables? What were the challenges you faced during the project, and how did you overcome them? According to the PMBOK®, what are the key skills you used as a project manager in your project? How did you handle disagreements in your project?
Are you a professional looking to advance your career as a project manager? Assess yourself by answering these PMP® Practice Questions.
What estimation techniques did you employ? What are the elements of your project strategy? How do you plan and track your project using Microsoft Project? What method did you employ to communicate with the stakeholders? How did you find the project’s completion? I hope you found all of your answers in the preceding article. I wish you success and happiness!
