Inspiring Careers – Jayapal Chandrasenan, Associate Infrastructure Designer, Urban Planning

Here is an exciting interview with Mr. Jaypal Chadrasenan, Associate Infrastructure Design at Department of Urban Planning and Municipalities, United Arab Emirates. In this interview with Abrachan Pudussery, Director of PMRI, he shares his exciting journey starting from his campus life to the present position and about the key success factors that governed his professional journey.

About Jaypal Chandrasenan

Experienced Associate Power Planner, Urban Planning, with a demonstrated history of working in the Power and Infrastructure Design and Construction Engineering Industry. Skilled in Renewable and Conventional Power Generation, Transmission and Distribution Networks, Metro, LRT, Tram Highways, Project Control, Engineering, and EPC. Strong consulting professional with a Engineering Masters Degree – Electrical Engineering degree from College Of Engineering Trivandrum , CET,Kerala- BSc ( Engg), Bits Pilani MTech , Graduateship in Industrial Engineering NIET Mumba,MIET( UK),CEng (IET UK )PMP, PQP.

Linkedin profile

Quick bridge to PMBOK7 from PMBOK6

Who should read this?

  • Those who prepared for PMP exam using PMBOK6 and writing the exam now
  • Those who know PMBOK6 and want to update their knowledge of PMBOK7 without going through all the pages of PMBOK7

If you fall into anyone of the above categories, please read further….

PMBOK7 is structured into;

  • Principles
  • Project Performance Domains
  • Models
  • Methods
  • Artifacts

If you want to know more about the structure and principles of PMBOK7, I request you to read the two earlier articles, before reading this one;

Unboxing PMBOK7 – Article1

Unboxing PMBOK7 – Article2

12 governing principles

  1. Stewardship – Be a diligent, respectful, and caring steward
  2. Team – Build a culture of accountability and respect
  3. Stakeholders – Engage stakeholders to understand their interests and needs.
  4. Value – Focus on value.
  5. Holistic Thinking – Recognize and respond to systems’ interactions.
  6. Leadership – Motivate, influence, coach, and learn.
  7. Tailoring – Tailor the delivery approach based on context.
  8. Quality – Build quality into processes and results.
  9. Complexity – Address complexity using knowledge, experience, and learning.
  10. Opportunities & Threats – Address opportunities and threats.
  11. Adaptability & Resilience – Be adaptable and resilient.
  12. Change Management – Enable change to achieve the envisioned future state.

8 Performance domains

  1. Stakeholders
  2. Team
  3. Development approach and life cycle
  4. Planning
  5. Project work
  6. Delivery
  7. Measurement
  8. Uncertainty

The governing principles and the performance domains are supported by the Models, Methods and Artifacts. If you know PMBOK6, you have already covered all the Methods & Artifacts of PMBOK7. Hence, our primary focus is on the Models, followed by some of the methods and artifacts.

True to the spirit of Agile, we want to reduce the amount of unwanted work not done. Hence we are not repeating the topics again, instead we are providing you with the page numbers of PMBOK7, which will help you to get familiarized with the new terms of PMBOK7.

Here are the list of topics with page numbers of PMBOK7, for your quick reference.

Now open PMBOK7, and skim through these topics, instead of reading the entire PMBOK7.

  • Emotional intelligence – Page 25
  • Conflict management – Page 29
  • Delivery cadence – Page 33
  • Hybrid approach – Page 36
  • Explicit and tacit knowledge – Page 77
  • Done drift – Page 85 last paragraph
  • Leading indicators, Lagging indicators – Page 96
  • Cycle time – Page 99
  • Que size – Page 99
  • Batch size – Page 99
  • Process efficiency – Page 99
  • Net promoter score – Page 103
  • Mood chart – Page 103
  • Regression analysis – Page 105
  • Throughput analysis – Page 105
  • Information radiators, Big visible charts – Page 108
  • Hawthorne effect – Page 112
  • Vanity metric – Page 112
  • Decoupling – Page 120
  • Tailoring – Page 137
  • Situational leadership II Page – 156
  • OSCAR model – Page 156
  • Rich communication – Page 157
  • Gulf of Execution and Evaluation – Page 158
  • Hygiene and motivational factors – Page 158
  • Intrinsic Vs Extrinsic motivation – Page 159
  • Theory of needs – Page 159
  • Theory X, Theory Y and Theory Z – Page 160
  • Managing change in organizations – Page 161
  • ADKAR Model – Page 161
  • 8 step process for leading change – Page 162
  • Virginia Satir Change Model – Page 163
  • Transition model – Page 163
  • Cynefin framework – Page 164
  • Stacy matrix – Page 165
  • Tuckman ladder – Page 166
  • Drexler/Sibbet team performance model – Page 167
  • Conflict model – Page 168
  • Think Win-Win – Stephen covey – Page 169
  • Planning – Page 170
  • Process groups – Page 170
  • Salience model – Page 171
  • Story map – Page 190
  • Infinite delivery infinite quantity (IDIQ) – Page 191

At the end of this exercise, you can be almost sure that there is no gap between your knowledge and PMBOK7 provided your knowledge about PMBOK6 is good.

Point to note

Do not delete PMBOK6. It is still a valuable reference document along with PMBOK7.

Best wishes

PMRI team

Unboxing PMBOK7 Article#1

This is the first of a series of unboxing PMBOK7 articles explaining PMBOK7 which will help the readers to bridge between PMBOK6 and Agile to PMBOK7 very easily. Again I want to reiterate the fact that the foundations of project management cannot be disrupted very easily. If you know the basics of predictive project management and agile project management, then it is only a matter of establishing a traceability to the PMBOK7 structure. PMI, the publishers of PMBOK have time and again highlighting the fact that PMBOK is only a reference material and need not be mastered and remembered end to end like every other reference material. With these Unboxing PMBOK7 articles, my goal is to make the transition from PMBOK6 to PMBOK7 as smooth as possible.

Structure of PMBOK 7

From PMBOK version 6 onwards, PMI was trying to catch up with Agile Project Management (APM) which is the most suitable for managing certain types of projects, especially those ones where the scope is continuously evolving and the technology component is fast changing. PMBOK Version 7 can be seen as a natural progression of it. Like the 12 Agile Principles, which are the foundation of all agile frameworks, PMBOK7 also has 12 governing principles at the apex level followed by other components as shown in the diagram below.

Click on the diagram to zoom

12 Governing Principles

At the apex level are the 12 governing principles. These 12 principles based on the project management professions ethics governs the actions and behaviors of project management practice regardless of whether one is following predictive or adaptive project management styles.

  1. Stewardship – Be a diligent, respectful, and caring steward
  2. Team – Build a culture of accountability and respect
  3. Stakeholders – Engage stakeholders to understand their interests and needs.
  4. Value – Focus on value.
  5. Holistic Thinking – Recognize and respond to systems’ interactions.
  6. Leadership – Motivate, influence, coach, and learn.
  7. Tailoring – Tailor the delivery approach based on context.
  8. Quality – Build quality into processes and results.
  9. Complexity – Address complexity using knowledge, experience, and learning.
  10. Opportunities & Threats – Address opportunities and threats.
  11. Adaptability & Resilience – Be adaptable and resilient.
  12. Change Management – Enable change to achieve the envisioned future state.

Project performance domains

The second level comprises of the project performance domains;

  1. Team
  2. Stakeholders
  3. Life cycle
  4. Planning
  5. Navigating uncertainty and ambiguity
  6. Delivery
  7. Performance
  8. Project work

Models, methods & artifacts for enabling outcomes

This section at the third level more or less looks like the Inputs, Tools & Techniques and Outputs re-grouped as models, methods and artifacts. For each project outcome we have a set of models, methods and artifacts which help to achieve the project outcome.

At the fourth level is the PMIstandards+ digital platform which will guide on the application of Models, methods and artifacts based on project type, development approach and industry sector.

changes-to-pmbok-guide-7th-edition PMBOK 7th Edition - Coming in August 2021 - What is changing?
Courtesy – Project Management Institute (PMI), USA

New 10 Week PMdistilled PMP Plan / Program based on PMBOK7

The Hybrid Manifesto

Projects are neither completely predictive nor agile any more. They are hybrid in nature. That is the reality. So far, project management had two distinct streams, the Adaptive (Agile) and the Predictive (traditional). The purists believed in any one of the streams. They are busy justifying their views. Now, the industry has changed. Irrespective of the type of work, majority are working from home and that demands adoption of both agile and predictive best practices in the day to day work. That trend is here to stay. The Project Management Institute (PMI) was the front runner in this by including Agile in the Project Management Body of Knowledge four years back. This was followed by the new Scrum Guide 2021, which has become more generic. Scrum is the most popular among the Agile frameworks because of it’s adaptability to various disciplines of project management. According to Ken Schwaber and Jeff Sutherland, the founders of Scrum, they made the Scrum Guide 2021 more generic so that it becomes easier for all types of projects to adopt it. The trend is very clear. The boundaries between agile and predictive is vanishing, if not yet vanished.

Unfortunately, when I visited the Agile Manifesto Page, it still reads as ‘Agile manifesto for developing software’. From an EPC project practitioner’s perspective this is very demotivating. The engineering phases of any EPC project is a good candidate for agile adoption, but still the agile manifesto is maintained exclusively for software development. Like every other EPC person wanting to leverage agile I feel stranded and unsupported.

These two factors leads to the need for the Hybrid Project Management Manifesto;

The Hybrid Project Management Manifesto

As practitioners of Professional Project Management, We believe that;

All projects are unique in nature,
Tailoring the processes, by incorporating the best from every project management framework is better for project success, than relying on any single framework. 

For this;
We will continuously update our knowledge and skills without any bias to any one particular project management framework,
We will always maintain an independent open view in all our actions to ensure project success. 


I am very optimistic about this, because there are many who opposes this view as well as those support this view. It is high time we stopped saying ‘Agile Vs Waterfall’, instead we must learn to say ‘Agile and Waterfall’ and for that the apt word is 'Hybrid'. Thanks to the traditionalists who contributed us with great tools like the critical path analysis, earned value management and the likes. These are time tested concepts which is here to stay. The agile practices like time boxing, the short term planning, daily team meetings, self organizing teams can be effectively used within phases of every project. That will result in a healthy co-existence.  Think of  burn down charts co-existing with earned value management and helping to protect the earned value.  Nothing is good or bad, the project context determines it’s suitability.

Hope Hybrid manifesto will help us to focus on the project’s success than worrying about the technicalities of frameworks.

The Hybrid manifesto is evolving. You can help with your suggestions.

Abrachan Pudussery

Domain Expert at Wrench Solutions

Project Cost and Schedule forecasting

Schedule and Cost forecasting explained in detail.

  • Are we progressing as planned?
  • Are we completing the work within budget?
  • When will we complete the project?

These are the key questions we hear most of the time in project review meetings. Well implemented earned value management systems, provide answers to these questions at the press of a button.

Earned Value Management (EVM) is based on the analysis of the earned value of the project and comparing it with the planned value of the project. Earned value management is used to monitor and control both the schedule and cost. Earned value management (EVM) comprises of;

  1. Earned Value Analysis
  2. Variance Analysis
  3. Trend Analysis
  4. Reserve Analysis
  5. Corrective / Preventive actions
1. Earned Value Analysis :

The basic building blocks of earned value management are;

  • As on date, how much work we were supposed to complete? – Planned Value (PV)  – Also known as Budgeted Cost of Work Scheduled (BCWS) 
  • Out of that how much work did we complete? – Earned Value (EV) – Also known as Budgeted Cost of Work Performed (BCWP)
  • For the completed work how much did we spend? – Actual Cost (AC) – Actual Cost of Work Performed (ACWP)
2. Variance Analysis

Once we have the basic values of Planned Value (PV), which is also known as Budgeted Cost Of Work Scheduled (BCWS), Earned Value (EV), which is also known as the Budgeted Cost Of Work Performed (BCWP) and the Actual Cost (AC), which is also known as the Actual Cost Of Work Performed (ACWP), it is time to do the performance analysis.

  • Schedule Variance (SV) = EV – PV
  • Cost Variance (CV) = EV – AC
  • Schedule Performance Index (SPI) = EV/PV
  • Cost Performance Index (CPI) = EV/AC

As we can see in the diagram above, as on the review date, the Earned Value (EV) is lower than the Planned Value (PV). That means, the work has not progressed as planned. The actual cost (AC) is higher than the Earned Value (EV) and even the Planned Value (PV). That means, there is a big cost overrun. In an ideal situation, all the three lines should have intersected at the Planned Value (PV). In that scenario EV = PV = AC

  • Schedule Variance (SV) = EV – PV = 0
  • Cost Variance (CV) = EV – AC = 0
  • Schedule Performance Index (SPI) = EV / PV = 1
  • Cost Performance Index (CPI) = EV / AC = 1
  • If the SPI=1, then we can infer that the project is progressing as per the agreed upon schedule.
  • If the SPI >1, then the project is progressing at a rate which is more than planned.
  • If the SPI <1, then the project is lagging behind schedule wise.
  • Similarly. If the Cost Performance Index (CPI)=1, then we can infer that the work is getting completed as per the budget.
  • If the CPI <1, then the that indicates budget overrun.
  • If the CPI>1, then more work is getting accomplished than planned, with the same amount of money.
  • As a general rule of thumb, if the SPI and CPI is 1 or above 1, then the project is doing well schedule wise and cost wise.

As project managers, if we know the schedule variance (SV), Cost Variance (CV), almost real time, then we can monitor and control our projects effectively.

3. Trend Analysis

The variance analysis provides us with the current snapshot of the project. One can become more pro-active in managing and controlling the project, if the future trends of the project performance can be predicted with the present progress information. We use graphs and charts to do this.

At this stage, let me introduce these three additional terminologies;

1) Budget At Completion (BAC) – is the total approved budget of the project from the beginning of the project till the end of the project.

2) Estimate to Complete (ETC) – is the budget required to complete the balance work of the project. ETC = (BAC – EV).

In some cases, ETC is calculated as a bottom up re-estimate for the balance activities to be completed.

3) Estimate at Completion (EAC)

  • If all the future work can be expected to be completed as planned, then how much will it cost when we complete the project. EAC = AC + ETC = AC + (BAC-EV).
  • If the current trend is going to continue in the future as well, then EAC = AC+(BAC-EV) / CPI.
  • In some projects, where the schedule has an impact on the cost, for example, a delay in schedule incurs additional cost, then EAC = AC + (BAC-EV) / (CPI x SPI). In this case, CPI and SPI are given weightages like (80/20, 50/50 or some other based on the judgment of the project team).
4. Reserve analysis

While performing the cost control of the project, the reserve analysis of the contingency and management reserves monitored. This will help in utilising these reserves elsewhere is the project progress is satisfactory or in organizing additional reserves proactively.

5. Corrective and Preventive actions based on the to Complete Performance Index (TCPI)

What should be the target CPI, to be maintained for the balance work, in order to complete the project within budget.

TCPI = Work remaining / Funds remaining

(BAC-EV) / (BAC–AC) or it can be,

(BAC-EV) / (EAC-AC) if the EAC is approved by the management.

Earned Value Management brings in more visibility into the project, and helps us to be more pro-active.

So far our focus was on forecasting the Estimate At Completion (EAC). What about forecasting the Estimated Date Of Completion of the project?. The following seven minutes video explains schedule forecasting;

Abrachan Pudussery, Domain expert, Wrench Solutions

Reference – Project Management Body Of Knowledge by PMI, USA

Building a distributed agile team

In today’s fast changing world we cannot escape from the fact that business requirements change very often. If we use the predictive, heavy weight methodologies for developing software it is very difficult to incorporate the changing business needs of our customers. Lightweight software development methodologies, which appeared in the late nineties “embrace changes”. The disciplined adaptive nature of these methodologies helps us to easily accommodate changing business needs of our customers, even in later part of the development cycle.

Many software development organizations are using agile development methodologies like Scrum as it helps the organizations to respond to changing business environments very quickly and provide better customer satisfaction. In today’s business environment it is not really the big that win the battles rather it’s the fast that win the battles over the slow. Time to market is very important in today’s fast changing world. Agile development helps us to deliver the value to the customer rapidly through a divide and conquer approach and prioritization. The right 20% of effort will yield 80% of the value, so we do a lot of those in agile development and extreme testing.

Introduction to Agile

In Scrum the whole development is divided into different increments/sprints. Top priority user stories are covered in the initial sprints. Unit tests are developed first as a best practice. Then the code is written to ensure that 100% of unit tests pass. This is done in an incremental way. The developers write unit tests and 100% of Unit tests are automated. This will help in executing the tests repeatedly and also simplify the reporting of results.

There is one more important type of testing involved in agile testing, which is called Acceptance Test/Customer Test. These tests are written, based on User stories. They are formal tests conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Test engineers write the Acceptance tests with the help of customers in some organizations. It is very important to understand the customer perspectives while writing the acceptance tests. The big mountain acceptance tests are automated using an appropriate tool and executed on all the builds. Agile testing creates confidence that code is complete and it works; catches integration defects when they are first created, and, most importantly, provides confidence that a maintenance change did not introduce a regression error.

Basic values like open communication, tight feedback loop in the scrum teams, simplicity and courage are the key in scrum teams. In scrum, testing isn’t a final hurdle it is a journey along the full development cycle.

Areas to Focus

While building a distributed agile team  we need to consider multiple factors. If we don’t build the right team for Agile it is going to be very tough to get the results. Open Communication is one of the key values in agile development.

Individuals and Interactions

If your existing team is to be transformed into an Agile team the most important step is to evangelize the agile concepts and benefits in your team. Management and Development teams also need to be educated on the ROI(Return On Investment). When we were implementing Agile in our organization we used to conduct talks by practitioners on agile, play agile dramas depicting the outcome from monumental methodologies and light methodologies. Once the platform is set we can start implementing agile practices and values. We need to identify and prioritize which are the areas to focus on first for the team. We may need to refactor the team. If there are team members in your team with a negative attitude or having an attitude to resist changes, then proper guidance needs to be given to them to bring in the change. If there are no improvements, it is a good idea to move them to a different project. Agile talks about “tossing off” the code at the end of the day if it doesn’t serve the purpose. This is applicable for team members also. Don’t try to patch it up too much…

While recruiting new members to an agile team we need to ensure that they have the right set of attitudes and skills in line with the agile way of working. Openness, ready to give and accept feedback, simplicity, courage, adaptability, good in communication, right skill mix …these are some of the attributes we need to ensure in a new hire. If you are planning to hire it is a good idea to have a brief discussion about agile practices you follow in your organization during the interview. Once they are hired we need to evangelize agile among them. In some cities we may not get engineers who worked in agile earlier. Transforming an engineer who has been working in monumental methodologies to an agile environment is not that easy. It’s a big paradigm shift. There may be resistance to change. We need to plan our inductions in such a way that the returns of Agile are communicated to the new hires appropriately. Once they understand the synergy it gives to customers and the organization employees will start believing in this new model. Once this milestone is covered it is easy to evangelize the other agile practices we follow in our organization.

Like the “pair programming” concept in Agile mentoring also can be done through pairing. A new hire is paired with a senior engineer who is in the team for more than 1 year. A high level introduction about the product is given to the new hire. After that during the sprint the new hire pair up with other team members according to the plan laid out by the Coach. The mentoring plans always focus on big mountain functionalities first.

When a groupWhen group of people works together in internationally distributed locations, there is great need to communicate with each other, share data and share expensive resources. Building a good communication mechanism is very important for the success of agile testing. Conversation with developer, customer, and feature team leads and product manager is frequent. Daily Stand up meetings with the scrum teams helps to build the relationships among the teams. All the Agile team members including developers, test engineers, documentation experts, product managers and DevOps assemble in the morning (usually on a planned fixed time like 10am) for a short stand up meeting of 5 to 10 minutes duration. Plan for the day and top priority unresolved issues from the previous days work is communicated to the team. This meeting is not for resolving the issues or detailed discussion. Resolutions are taken later after the meeting. If we are working in a distributed model where the development is happening in the US and the testing is in India or some part of the feature team is in a remote location like India and China, Communication and the feedback loop get badly affected. Tailored agile for these kinds of offshore development can be called as “Distributed Agile”. Collaboration among testers, programmers, and other stakeholders is more highly valued on agile projects than details of process, practices, or tools. Test engineers are part of scrum teams. Agile methods ask teams to continually evaluate how to improve group interaction, for the benefit of the project.

Once we have decided the members of the scrum team, building the team is the first priority. We need to plan for internal and external team building activities initially. We can also do a lot of informal interactions and get together … like all feature team members having evening snacks together in the snacks parlor.

Video calls, Chat, email , lightweight documentations  , phone calls etc.. can be used for constant communications. We can plan for weekly meetings with members of the scrum team who are in the remote location. It is a good idea to have all the scrum team members participate in this meeting. Frequent conversations between the remotely located team members is a good practice. This will help us to build relationships. We need to agree on the overlap timings when the video calls can happen as most of the time one of the engineers will be at home because of the time zone differences. Engineers traveling in both directions frequently (2-3 travels per quarter) and working with the remote team for 3-4 weeks will enhance the relationships. This will help us for better culture sync. These ambassadors ensure there is enough osmosis within the distributed feature team.

Working Software over Comprehensive Documentation

Jim McCarthy said that, “The regular build is the single most reliable indicator that a team is functional and a product is being developed.” This is very much true in the case of a distributed agile team. We need to ensure that we have good CI/CD practices in our organization where the latest builds are easily available for the test teams. This will help the test teams to run their test on the latest code. We need to automate the big mountain acceptance tests using appropriate tools. This will help us to test often and communicate the progress to the feature teams.

Frequent demos of the current status of the features to the entire feature team is very important. It is a good idea to have such demos weekly once. Demos can be arranged for remote teams on Fridays and we can have a group test after that where the entire feature team tests the latest build with a focus on new features. These demos can be recorded and uploaded to a common repository. Later if some of the team members want to go through the demo they can always replay it from the common repository. During the initial milestones where the top priority features are developed we can use build mechanisms like “sandbox” where the developers check in their new code as and when the unit test passes into a sandbox build maintained by the feature team. Test engineers can always use this build for testing the new features. As we are going to give feedback on working software rather than on design documents or requirement documents the feedback inputs will have more value. Development engineers can incorporate the feedback back into the sandbox the next day. At the end of the week all the new code checked in by the feature team in the sand box (which is tested and feedback incorporated) can be checked into the main line code. If we are working in distributed agile we may need to document some of the important changes. We can use wiki or google doc etc… for maintaining these kinds of knowledge bits.

Summary

To build an effective testing team for Distributed agile we need to focus on individuals and interactions over processes and tools. We need to ensure that the latest code is available for testing in all the internationally distributed locations. Feedback based on working software helps to build confidence in the feature teams.

References : https://agilemanifesto.org/ 

Author :

Baiju Joseph Thalupadath

Head Of TechOps(QE,RE & SRE) @ Yahoo Small Business

Linkedin profile