By Nagaraja Gundappa
October 23, 2024
Now that PMI is aligning PMBoK to value delivery and relegated the old Knowledge Area – Process group structure to a non-PMBoK document, the question that arises is – if this old structure is still relevant or dead?
Ever since Scaled Agile (SAFe ) defined software development as continuous delivery pipeline and did away with the concept of project as a temporary endeavor with unique deliverables, more and more people are aligning their work and organization towards value delivery based view. Even outside the SAFe framework, value streams are still popular as this concept is central to lean methods and lean has a global popularity. It was inevitable that PMI also fell in line and aligned PMBoK to a value delivery view. I too am an enthusiast of this new view and love Lean methods whether in combination with Six Sigma and Scaled Agile or without.
However, a recent experience that I went through made me realize the value of the old PMBoK structure in certain contexts and the purpose of this article is to illustrate the context in which Knowledge area – Process group view of projects hold more value compared to value stream-based view.
Nepal Vacation Experience
The comparative analysis of the two views of project management needs detailing of this experience and here we go with the details. I lead a group of 22 people into a pilgrimage tour to a destination called Muktinath which is located on one of the high-altitude valleys (3800 meters) of Himalayan mountain range in Nepal. We reached Kathmandu, the capital city of Nepal by flight and from then on, we were taken care off by a tourist company all the way back to Kathmandu from where we flew back to India. After completing most part of the itinerary, when we were returning by a bus to Kathmandu we were caught amidst landslides and had to be rescued by government rescue-teams through a tunnel way. We all reached back safely without a dent but had to go through some hardships. This incident forced us to take an entire relook at our planning and being a passionate project management professional, I viewed the whole vacation from both value delivery perspective as well as process group and knowledge area perspective and am sharing the learnings here.
The Itinerary
The itinerary was as depicted in diagram 1. Our destination was Muktinath and once we were dropped off at this destination, then, we are on our own to enjoy our experience in the destination.
Diagram 1: Itinerary
Value Delivery View
If we viewed this itinerary through value delivery perspective, following would be the value stream:
Diagram 2: Value stream for drop off at destination
When we view this tour as a value stream, the final drop-off is the value delivered by the tour operator to the customers as shown in diagram 2. And the previous stages are steps to deliver the value. This value stream view of the tour has several disadvantages to plan and execute the tour:
- It is not an ever-ongoing continuous delivery as envisaged in Scaled Agile. It conforms to PMI definition of a project as a temporary endeavor with a specific start and end date.
- The teams are not longstanding. They are temporary formations. The stakeholder team (tourists) as well as the human resources (guide, drivers etc.) gel as a team only for this tour and are then disbanded. So, resource assignment is temporary and is on per project basis.
- This value stream-based view doesn’t help us break down the project into subcomponents and carry out effective scheduling, costing, risk management etc.
- According to the Agile Manifesto, only the final deliverable is considered to be value and intermediate deliverables are not considered as value. In software projects, it is the working software that is considered value and not intermediate deliverables such as the design document or the requirements document. This view doesn’t work for this tour-project as each intermediate step is delivering experience to the tourists and is of value. The journey, food, and stay are not just steps to reach the final destination but are experiences by themselves.
For instance, as images 1, 2, 3 & 4 depict, each step was an experience by itself. For instance, the place where we stopped over for lunch was so picturesque (Image 1) that having lunch there itself was an experience. Similarly, having local special cuisine was another experience and was of value by itself. Road journey (image 2) was so picturesque that it was an experience and value by itself. And Pokhara-Jomsom flight (Image 3 ) is considered a lifetime experience and is not just a step to reach Muktinath. And even landing at Jomsom airport (Image 4) was an experience. So, the whole itinerary was value and it is not the case that value was delivered only at the end.
Image 1: View from the place where we stopped over for lunch
Image 2: View enjoyed during bus journey
Image 3: View captured from Pokhara – Jomsom flight.
Image 4: View outside Jomsom airport
Knowledge Area Based View
Let us now examine how a Knowledge Area based view can help us in better planning and execution:
- Scope: The tour vendor had clearly identified scope that included all transport after we reach Kathmandu till we are dropped off at Kathmandu airport back. It included overnight stays and breakfast. Venue visits, lunch and dinner was excluded from scope.
- Schedule: It was a 7-day tour and costing was done accordingly. At stage of signoff, day-wise schedule was made, and a rolling wave method was used to arrive at hourly plan for the day at the beginning of each day. This way, we preserved option and made just in time decisions.
- Cost: Costing was based on project costing and not value stream budgeting and we followed bottom-up method. We added stay, transport, food and venue expenses and arrived at the costing per person.
- Quality: We had done due diligence in terms of checking the ratings before the journey. We had discussed the specifications in terms of type of hotel rooms, type of vehicles and food hygiene and verified through ratings on internet.
- Resources: Preassigned team by tour operator
- Communication: Two stand ups per day for group announcements, one at the beginning and one at the end of day with intermediate announcements covered through WhatsApp group messages
- Risk Management: Known risks had been planned for. We had contingencies for sickness, food unavailability (due to reaching a specific destination late), flight cancellations due to poor weather etc., but had not factored in unknown risks. This did impact our project.
On the penultimate day, we were supposed to travel from Pokhara back to Kathmandu by flight. However, due to heavy rains, the flight was cancelled. This was a known risk, and we had a fall back option of travelling by bus. And a spare day had also been factored in into the schedule so there was no problem. However, as we were nearing Kathmandu, we were caught amidst landslides and all the vehicles on the road were stranded there for 3 days. Along with the vehicles, we were also stranded and had spent nearly 24 hours in the bus. Luckily for us, there was a new tunnel way being constructed nearby and the Nepal Government arranged for a rescue operation where we walked down to this under-construction tunnel way and were transported to safety. We still had enough time to catch our return flight and did not miss it. However, the lesson learnt is that we hadn’t factored in the unknown risk. If we did, we would have booked flights that are cancellable / changeable and built additional buffer in our schedule so that if needed we could stay back. - Vendor management: We had selected the vendor based on multiple parameters including quality, cost, knowledge, efficiency and so on.
- Stakeholder Management: We had to interact with a number of stakeholders including government officers while managing the unknown risks.
As can be seen, the entire tour perfectly fits into the template of knowledge-area based view of a project. This view offers all the details that we need to plan and execute the tour. When we look back at all the people involved and all the activities we carried out, it can easily be retrofit into this KA based template as well. On the contrary, the value stream-based view was a complete misfit for conducting this tour.
Conclusion
The knowledge area and process group structure of PMBoK is not dead and is still relevant. In event management projects as evident from our Nepal tour, the KA based view is very apt and value stream-based view is inappropriate for planning and execution. Extending this example, we can conclude that wherever the processes are as valuable as the end results are, KA based project management will be more suitable than value delivery-based project management.
Nagaraja Gundappa will be speaking at International Project Management Day 2024! Learn more here!
Nagaraja Gundappa, whom you can call Naga is a Digital Transformation expert and software delivery transformation is his special area of interest. He covers most areas in the Digital Transformation Canvas that includes process transformation, Agile Delivery, Design Thinking, AI, Data Science, Platform Technologies, and Enterprise Architecture. He is a trainer and consultant and has been associated with IIL for more than 10 years.
He is an M.Tech. Degree holder in computer science and started his career in Artificial Intelligence as applied to fault tolerant flight control systems. He then has served in IT service sector and delivered large complex projects and programs for global customers that include General Motors, Deloitte, Honeywell and so on. As a General Manager, Wipro Technologies, he has led a delivery excellence program where 1200 project managers were trained, assessed, and mentored and the program resulted in cost reduction by 13%. He conducts training in the areas of complex project management, SAFe 6.0, Kanban, Scrum, many PMI courses, Design Thinking and Business Analysis. He is a speaker at many industry forums and has many publications and presentations to his credit.
You can connect with him at: https://www.linkedin.com/in/nagarajagundappa/
