Career In Project Manager After Pursuing Your MBA

In Nov 2014, like many other students in reputed B-schools across India, I was also applying for job openings in the coming “Final Placements” season to get a worthy ROI on my academic spend (opportunity cost included!). Consulting firms and fast-growing E-Commerce players were obvious choices, offering eye-catching “packages”.

However, in the midst of hurry-and-flurry of job-applications, I also ended up with a “shortlist” in a reputed Global Banking behemoth, offering a Project Management profile to interested and suitable candidates. I was not sure if I was any of those. But it didn’t matter – I figured. The interviewer and I will find that out soon enough. A group-discussion, a case-study, and an interview later – I had the job offer in hand. I was excited (and relieved too) to finally have an offer. ROI was assured now. Mission accomplished!

In Apr 2015, I started my Project Management career with very limited understanding of, and practically no prior work-experience in, this field. You could ask me all about “BCG Growth Matrix”, or “Porter’s Five-Forces”. I had used those frameworks to death in MBA. On the other hand, I hadn’t applied critical-path-method, for example, outside of Operations Management lectures. My experience was not much different than that of my batch-mates.

Fortunately, no one was expecting me to be a Project Management expert either. For that, the bank attracted talent from the lateral hiring market. B-School grads were on-boarded for their ability to learn and apply new skills in a rapidly evolving landscape. With the benefit of hindsight, and looking at how much the industry and the domain has evolved over the last few years since I started my career, more and more hiring decisions will be driven by this reality.

Stage 1 (2015-2017)

Shu-Ha-Ri is a Japanese martial art concept of learning. An apprentice starts her learning journey by first practising a set of moves without bothering much about “Why”. This stage is called Shu. Then she starts to understand the underlying concepts of anatomy, defence, offence, balance, physics etc. This stage is called Ha. And finally, she attains enough mastery over the subject to not follow any prescribed methods (think frameworks) and pioneers her own methods.

My Shu guru was a PMBOK inspired framework. It was a good starting point, and helped me learn the ropes of change management practice within the safety of prescribed guidelines of Scope Management, Schedule Management, Cost Management, Risk Management, Quality Management and so on. My worst fears didn’t come true as long as I adhered to PMBOK – i.e. the project didn’t “Fail”.

https://www.pmi.org/pmbok-guide-standards

According to PMI,

“a project can be defined as a temporary endeavour undertaken to create a unique product or service. Projects are different from other ongoing operations in an organization because unlike operations, projects have a definite beginning and an end – projects have a limited duration. Projects are established to deliver specific outcomes, on time and on budget with 

• a set of clearly defined outputs, definite start and finish dates with a well-defined development/delivery path
• project manager and sponsors as well as a defined set of staff, financial and other resources allocated to it
• project plans which include activities to plan, measure and assess the benefits achieved by the project”

Now, what is meant by a “Successful” project? It could mean different things to different stakeholders. For the delivery team, it meant that the product was deployed to production successfully. For me, it meant that the “full scope” was delivered, on time (didn’t matter if the target release date was re-baselined more than once), and on a budget (which had to be increased as well after we realized that our initial delivery estimates were too low!).

To business, however, success meant the realization of envisaged benefits. ROI matters the most after all! Just delivery doesn’t ensure the realization of benefits. What good is a new Harley Davidson in your garage, if you don’t know how to ride it. To accommodate this reality, I as a Project Manager, had to expand my definition of the project’s success. And here enters a complementary set of guidelines on Change Management CMBOK (not to be confused with PMBOK). The goal of a comprehensive change management practice is not only to deliver a quality solution, but also to ensure that the change audience is ready and willing to adopt the change. This is managed by planning implementation and communication strategy which suits your change audience.

Stage 2 (2018-2019)

“Agile” started as a new buzz-word in my team. No one expected Agile to be a silver-bullet that would guarantee the success of all business transformation initiatives on its own. However, it had many clear advantages over traditional waterfall model of project management, that could improve the odds of achieving the desired business outcomes (i.e. benefits realization).

Agile is much less concerned about any particular delivery process or document (even though there are many Agile frameworks such as Scrum, Kanban, RUP, XP etc.). Instead, it places more value on team collaboration and incremental delivery of the solution. This facilitates the early realization of benefits and enables better response to emergent change.

Instead of committing to a Business Requirement Document (BRD) upfront, the business or customer is represented by an empowered Product Owner (PO) within an Agile team. The PO can always prioritize and re-prioritize the requirements (aka user-stories) according to their relative value to the business. These prioritized high-value user-stories stack on top of a long list of requirements called the Product Backlog. The target is not to deliver the entire backlog. Instead, an Agile team strives to deliver only the highest value user stories within the target delivery schedule and budget.

The project team picks up the items to work on from the top of the product backlog, in iterative cycles of fixed duration (usually called sprints). A user-story is deemed complete once it is developed and tested, and integrated into the core solution. The core solution, which is already deployed and available for use, gets further improved after each incremental release. The most basic version of the core solution which delivers some value to the customer is called Minimum Viable Product (MVP).

There are several pre-requisites for a project team before the successful adoption of Agile delivery methods

• Collaboration between team members is of utmost importance to ensure success in Agile. This is confirmed through many Agile ceremonies which should be diligently followed, till they become a team habit.
  • Daily standup meetings, which are no longer than 15-minutes per day, are spent discussing immediate blockers and priorities for each team member every day
  • Planning meetings which prioritize work for the entire team in the next iteration(s)
  • Demos provide the opportunity to demonstrate the work-in-progress product increment to the customers/users and gather valuable feedback
  • Retrospectives, which are used to improve ways-of-operating for the entire team so that future Agile practices accommodate lessons learnt from the past
• Product Owner should be available and accessible to the project team representing the voice of the customer
• Project Team should be empowered, and not micro-managed, to plan and manage delivery activities. Theory X with trust-deficit doesn’t work with Agile Teams
• Tools and technology that support transparency and collaboration certainly help. Tools like JIRA, Confluence, MS Project are commonly used. But none of the tools are must-haves. For smaller projects with co-located teams, old-school excel sheets, white-boards, and sticky-notes work just as well!

The roles in an Agile Team are significantly different from those in traditional project teams. With self-planning and self-managing empowered project teams in Agile, there was initially an identity crisis for me as a Project Manager. What was I supposed to do if not plan the end-to-end delivery roadmap for the entire duration of the project, detailing all the analysis, development, and testing activities that go between Initiation and Closure. The search for meaning and purpose in this reality of Agile pushed me towards re-skilling myself. I evolved from a domain-agnostic project manager into a multi-skilled and more comprehensive change management professional with a much better understanding of business domain as well – juggling the hats of Project Manager, Business Analyst, Product Owners (business knowledge is required for this role), and Scrum Master – sometimes wearing more than one hats at the same time!

Stage 3 (2020 – 20xx)

Agile manifesto was first published in 2001 in search of better ways to deliver software. The quest for eliminating waste and improving ways of operating stretches further back in the world of manufacturing. Henry Ford introduced several revolutionary practices in assembly-line production starting in 1913. Kiichiro Toyoda further propagated the innovation spirit in 1930’s introducing the world to Lean principles.

The Lean-Agile amalgamation is the newest trend (though neither Lean nor Agile is new!) in digital project management. Lean carries obsession to product quality (fitness for use) and Agile improves delivery quality. MVP in Lean-Agile context is the easiest, quickest, cheapest way to validate our hypothesis that what we intend to build as a solution to customer needs actually solves a real problem. That is the best way to ensure that the customer will actually value the product enough to pay for it and use it. After all, every user-story or requirement is a hypothesis i.e. we assume it will solve a real problem, and the customer will value it for that reason. Applying Design-Thinking principles, and religiously practising “customer empathy”, we can write better quality user stories by validating most of the assumptions upfront by talking to the end-customer.

By running frequent MVP driven experiments, which can vary from lo-fi wireframes to hi-fi proof of concepts, we can further validate the assumptions on customer value. And finally, applying Agile delivery principles, we substantially reduce the time-to-market and time-to-value.

With the Lean-Agile Project discipline, new skills are required. Now I wear a Product Manager’s hat as well. The skills and experience of a project manager are now less important than the mindset (fixed v/s growth) and commitment to do what’s right for our customers & communities. In this milieu, Project Management offers a great, challenging, dynamic, and exciting career for interested and suitable MBA candidates.

Are you?