PMP® Exam Will Change in December

Are you planning on pursuing the PMP this year?

Three months ago, if anyone had told me that the PMP certification could be achieved without leaving your home, I would probably have laughed at it. But sometimes a pandemic like the Corona Virus does present some opportunities that we probably could not expect and that is exactly what has happened with the PMP Certification.
So first let’s look at the traditional approach of getting the PMP Certification that was generally followed until Feb 2020.
1. Student enquiry would lead to a consultation and registration process.
2. Classes would be scheduled (either weekdays or weekends) in a traditional classroom environment.
3. Students would apply to PMI with their application and upon approval get into a preparatory mode.
4. Exam would be conducted at Approved Pearson Centers with scheduled dates and prior bookings.
5. The entire process would take around 3-4 months depending on the individual
So, what changed in the last couple of months. The Corona Virus threat got us into a lockdown, the only thing that a person could do staying at home is purchase groceries or study something online. There wasn’t anything really that anyone can do or rather should do. There couldn’t be a better time to achieve a professional credential.
Suddenly the word adaptability became key, adaptability for the training provider, adaptability for the certifying body. Changes happened and they happened overnight.
So, what are the changes that made it a certification that can happen from home.
1. Educational institutes are now providing the 35 training online with virtual classes with Schedules now more flexible, student can now complete their courses much faster considering they can do it from the comfort of their homes.
2. PMI has introduced proctored examinations which allows students to take their examinations from home.
3. Learning Management systems are now mature and provide content and roadmap when it comes to course preparation.
4. This will weed out the good institutes from the bad.
As such the entire process of getting a certification sitting at home has become a reality, I believe that this model will sustain and become the new norm.
I am more excited about the following
1. The change in student demographics with students from all across the world being able to study together and attend classroom sessions.
2. With virtual classrooms becoming the norm, students will be able to get their training from the best of breed faculty. The awareness of the subject will change and the ability of many students to clear the exam will improve. You will see the drastic change in certified professionals in 2020-2021.
3. Content will and has to improve to cater to the much wider audience.
I am excited about the future of professional certifications; I believe that this is the start to something that will change the way we study and teach. It will give every student privileged and underprivileged the opportunity to learn…. grow and succeed.

Features of the Personalized Plan.

1. One to One Counselling Sessions with the Program Director
2. Customized Roadmap on Red’s Learning Management System
3. Most advanced PMP curriculum (Oliver Lehman)
4. Dedicated Student Support (Application and classes)
5. Mock Up Simulations.

Important Dates

June 2019
New PMP Exam Content Outline Releases

30 June 2020
Last Day to Take Current Version of PMP Exam

Resilient vs Agile Supply Chain

By Mr.Nitin Choudhary

CSCP Faculty

Resilience is defined as the ability of a person, system or organization to recover to normal when subjected to external force or disruption. The same definition extends to Supply Chains.

It’s the capability of a Supply chain to achieve its intended goals even in the face of changes & disruptions. In theory, a total resilient supply chain will absorb most of the impact and recover to reach its target. But hardly any organization relies on a totally resilient supply chain because usually these impacts come at a cost (sometimes which even results in loss of business). Inherent in the definition itself, resilient supply chains contradict the lean philosophies.

On the other hand, an agile supply chain is defined as a supply chain which is quick to adapt to the external changes. Instead of absorbing the risk like a resilient supply chain, an agile supply chain steers around the risks quickly. But it’s also a fact that all this steering around the risks comes at a cost to the supply chain. An agile supply chain to be truly agile has to let go of the benefits coming from the economies of scale to maintain its agility for risk avoidance.

Now most organizations settle for a trade off between the level of resilience and agility in their supply chains depending on the product, market, criticality and some other business factors.

As a general thumb-rule, agile approach solves more of external disruptions and resilience in the supply chain focuses more on internal disruptions.

As represented in the figure below, diagram “A” shows Agility handling Opportunities and disruptions through threats and resilience handling internal disruptions.

In diagram “B”, this is what most supply chains strive to be. In this case resilience is defined as something which integrates agility into it & handles both external & internal disruptions.

Image for blog

The Rise & Rise of Hybrid Project Management

In one of my earlier articles, I had briefly touched upon the genesis of Project Management. However, I felt that an apt preface to this topic of discussion would be to delve deeper into the history and evolution of project management, which would set the context to discuss the latest trend that has been evolving in the project management world.
blog1

History of Project Management:

Preposterous as it may sound, Project Management shares its existence and evolution timeline with that of the human kind, it’s just that it was not christened then and got its name much later during the day. However, the history or project management is relatively recent.

Before project management was defined and named, there were projects. The Pharaohs built the pyramids of Egypt around 2500 BC, and to this day there are unanswered questions as to how they accomplished such an engineering marvel without the aid of any modern-day tools that we are aware of. There are records, however, that does indicate that there were managers, even back then, who was responsible for each of the four faces of the Great Pyramid. Another instance of a great project management feat was The Great Wall of China, constructed circa 208BC, which suggests the immense amount of planning which would have gone in to build this wonder of the world. Historical data reveals that the workforce for this large project was organized into groups. There were three that we know of: soldiers, common people, and criminals. Millions were ordered to complete the project.

Fast forwarding by a few millennia, the need for a more pronounced structure in construction, manufacturing, and transportation in the 19th century led to the birth of the modern-day project management as we recognize it today. While there might not have been task management, scope, or workload considerations at the time, there was certainly leadership at play, and there must have been some budget, even if open-ended, and scheduling of some sort. But with practice came process and refinement, as we shall see moving forwards.

Image for blog

It wasn’t until the 1900s that project management as we know it began to take form. As projects became industrialized, the process to manage them also experienced a revolution.

Henry Gantt, rightly conferred the title of the father of modern Project Management, in the year 1917 created a scheduling diagram (which later came to be known as Gantt Chart) using a visual timeline to plot tasks as points with durations and linked them if they were dependent. This was used in the construction of Hoover Dam in 1931, which remains a cornerstone in modern-day engineering and project management.

Development of Critical Path Method by Dupont in 1957, development of Program Evaluation & Review Technique in 1958 and Work Break Down structure in 1962, both by US Department of Defense, formulation of Theory of Constraints in 1984, the definition of Scrum model in 1984, ideation of Earned Value Management in 1989 and creation of the Agile Manifesto in 2001 were all significant milestones in the history of Project Management. In parallel, the formation of organizations/bodies like The American Association of Cost Engineers (1956), the International Project Management Association (1965), the Project Management Institute (1969), and the UK Government created Projects in Controlled Environment (1996) provided the much-needed cradle support to nurture and mature the project management theories.

With globalization, and the need for increased speed-to-market with products and services, Projects have become larger, more complex and increasingly difficult to manage. Teams have grown more diverse and spread across the world, there is an eternal need to cut costs but not corners, enhance product and service features, and make amends while the “machine is still running”. No doubt there have been better techniques, integrated with enhanced Artificial Intelligence (what machines learn from humans) and Machine Learning (what humans / machines learn from machines) capabilities, that are all shots in the arm for the modern Project Manager. However, in addition to these tools and techniques, there is an even greater need for the Project Management methodology to be more adaptive, nimble, agile and visual. Does Hybrid Project Management provide all of it and more? Let’s read on.

Case for Hybrid Project Management

The conflict between proponents of Agile project management method and those of the traditional waterfall method have reached legendary status. Agile proponents argue that since most of the projects involve some sort of research, where the scope is not defined and the requirements are in flux and where there is a need to show tangible progress as early as possible, this methodology aces. They further point that short duration sprints help teams to focus on important tasks and discover flaws with design assumptions and development processes much faster. The proponents of the traditional project management argue that for large projects, especially those which combine multiple disciplines, a clear blueprint is required for the work to be planned and executed. Without a robust structure, large teams consisting of multiple disciplines may get distracted by their own little problems and lose the focus on the overall objective.

The truth lies somewhere in the middle. The best project management method used in a project depends on the size of the team, the team’s experience, and the complexity of the project. Hybrid Project Management combines the best of what Agile offers in terms of speed of execution plus the detailed planning and clarity on objectives offered by traditional project management. Hybrid project management methodology is better suited for the majority of projects in which agile or waterfall methods don’t meet the need of the project.

What is Hybrid Project Management?

The hybrid approach includes the best principles practiced in both agile project management and traditional methods. In the hybrid methodology, the project is broken down into manageable components called sub-projects by discipline (hardware, software, mechanical, etc) or by functionality (navigational subsystem, computation modules, etc). This simplification can be accomplished by using a Work Breakdown Structure or WBS.

When a project is broken down in terms of functionality, the waterfall is used to map out the path from the requirement and specification to the development, testing, and final release to the customer. Each component is then specified in more detail and developed using an agile project management method like Scrum.

Image for blog

In Hybrid project management approach, all high-level tasks, their interrelationship (dependencies), and final product delivery are defined by the traditional method (Work Breakdown Structure). Agile is then used to speed up the development of each component and its sub-component in the plan. This defines a clear interface between separate disciplines. The hybrid approach is simple. It makes it possible for better quality products with less development time and faster reaction and adjustment to market changes.

After each component of the project is broken down into tasks that may take anywhere from one month to a few months, the Agile method comes into play. These components are broken down further into four to six weeks product releases called sprints. Here all principles used for the agile project management method are applied. The outcome of each sprint is tested and sent either to the market (if applicable) or used as the base for the next sprint. These iterations continue until the final product is developed and ready to be shipped to the market.

Hybrid Project Management Definitions

Components: The individual building modules driven from product requirement document. For example, a mobile phone has electronics, display, WIFI and software components. A software product may have UI, Business Logic and communication components. Product requirements establish which components are needed in a project.

Image for blog

Track: The path for development and release of each component. Some tracks could be shorter or longer than others.

Backlogs: The list of tasks for each component. Tasks for each sprint are derived from backlog of the same track. Both project manager and scrum masters add or modify the backlog.

Sprint: 4-8 weeks long development effort and each includes development, testing and release (deployment). Each track has its own backlog and sprints. Sprints from different tracks run in parallel. The output of each sprint from different tracks may or may not combine with sprints from other tracks to make it into a release

Project Team: Each project team is made up of dedicated team members. The essential members are 100% assigned to the project, and there is no sharing of resources across multiple projects. Team members report to scrum masters for day to day development effort.
Components: The individual building modules driven from product requirement document. For example, a mobile phone has electronics, display, WIFI and software components. A software product may have UI, Business Logic and communication components. Product requirements establish which components are needed in a project.

Track: The path for development and release of each component. Some tracks could be shorter or longer than others.

Backlogs: The list of tasks for each component. Tasks for each sprint are derived from backlog of the same track. Both project manager and scrum masters add or modify the backlog.

Sprint: 4-8 weeks long development effort and each includes development, testing and release (deployment). Each track has its own backlog and sprints. Sprints from different tracks run in parallel. The output of each sprint from different tracks may or may not combine with sprints from other tracks to make it into a release

Project Team: Each project team is made up of dedicated team members. The essential members are 100% assigned to the project, and there is no sharing of resources across multiple projects. Team members report to scrum masters for day to day development effort.

Hybrid Project Management Guiding Principles

The guiding principles of Hybrid Project Management is enumerated as below:

  • A Hybrid project is managed by a Project Manager using WBS methodology who has overall ownership and responsibility for the project.
  • Scrum Masters support the Project Manager by executing each Agile Sprint.
  • Continuous Team Collaboration is required for ongoing reporting, analysis and management review.

Hybrid Planning Phase:

In the traditional methodology, the entire project plan is scoped and planned before the start of the project. In agile, only the first sprint is planned. Hybrid Project Management recommends a complete project plan but the specific details of each sprint is not defined until the first sprint is completed. The Project Manager has overall planning responsibility while each Sprint is managed by the Scrum Master.

Image for blog

Hybrid Supporting Processes:

Hybrid project management method suggests to follow the Agile methodology. At each iteration, customer feedback is sought, testing occurs and fixes made to enable continuous improvement. Formal method is used to define the outcome for each iteration.

Image for blog

Hybrid Execution Phase:

In Hybrid the Project Manager is assigned the overall project ownership, and the individual Scrum Master is responsible for executing Sprint. Reporting is a joint responsibility requiring continuous collaboration and communication.

Image for blog

Concluding Thoughts:

Hybrid project management, with all its novelties, is still in its nascent stage, and the methodology is yet to be formally acknowledged by the global Project Management bodies. However, the methodology does appear to hit all the right notes with the practitioners and it is only a matter of time before it edges out many of the existing methodologies. The pioneers of this school of thought are indeed driving a paradigm shift in the realm of project management as we see the rise and rise of the hybrid model. Do watch out this space for more on this.

Is Program Manager the new Project Manager?

AMBARISH GUPTA
PROGRAM MANAGER – CIGNA INSURANCE

Project Management as a domain and Project Manager as a role has been well established within the professional world and the last half a century has just seen this domain and role being cemented with various industry verticals and mature with experience time. While Program Managers have also existed for the same modicum of time, they have sort of remained “under the shade”, letting the Project Managers be the torchbearer of the project management world. Of late, however, there has been an emergence of the Program Managers. Looking at the emerging interchangeability of these two roles, one wonders, and hypothesizes, are Program Managers the new Project Managers?
blog1

However, before we attempt to analyze it any further, let’s validate the tenability of the hypothesis through some data.

An independent study conducted by www.proventuresindia.com in mid 2019 estimated the number of certified Program Management Professionals [PgMP®] to be at 2,598, while the number of Project Management Professional [PMP®] credential holders for the same time period stood at staggering 911, 375. While these numbers were absolutely not comparable, the same team conducted a trend analysis for a period between November 2015 and March 2019, and the summary for that is given below:

  • PMP grows at a steady rate of 10%, with the exception of year 2018, when the growth rate jumped up to 15.6 % in anticipation of the edition change from 5th to the 6th edition
  • PgMP® and PfMP® experienced growth of 26.8% and 50.1% respectively
  • The PBA growth is exponential at 181.8%
table1


If nothing, the study proves that the demand for Program Management Professional as a credential has been growing at twice the rate at which the demand for Project Management Professional as a credential has been performing during the last four years. The demand, with suitable assumptions, can well extrapolated to growing prominence of Program Manager as a role across organizations.

Before taking the plunge of analyzing the reasons behind this unique trend, let us take a peek at what are the similarities and dissimilarities in the roles of a Project Manager and a Program Manager.

Image for blog

It is clear from this comparison that the key underlying difference between these two roles lies in the scope and context. In general, program managers are expected to look at a broader scope, are aligned to the organization’s strategies and are focused on long term sustainable benefits rather than the immediate deliverables. Project Managers, in comparison, are more focused on the deliverable at hand within the triple constraint of cost, schedule and quality. Due to this difference in perspective, there is also a difference in how “Change” is viewed by these two roles. While program managers are more adaptive towards change (they act as the change agent), project managers are skeptical in their approach when it comes to change as it may impact their deliverable at hand.

Regardless of this fundamental difference in approach, it has been validated that there is a significant shift and emergence of the program management role. There can be many reasons for this transition, I would like to enumerate two of them in support of my hypothesis:

(1) Changing the landscape of project management’s adaptability:

Project management as a methodology was envisioned with the construction industry as the model. As a result, a lot of examples that were quoted in subsequent literature on this topic had a “construction flavor”. However, to be fair to the propounds, the project management concepts were generalized to the extent possible, so that they may be industry agnostic. While this adoption took time, it surely did happen with the maturity of different industry verticals as well as the maturity of implementing project management methodology. With the emergence of the knowledge industry in the last few decades, adoption of project management has undergone significant changes. Knowledge industry has customized project management in a way that is more suitable to their way of work. As a result, knowledge industry especially views projects under the following categories:

(a)Quick wins: these are low cost, low complexity projects which can be finished within one to three months. Also christened as “project lite”, “sub project” or simply “initiatives”, the objective here is to get the work done without going through the rigor of a full blown “project”. These are often led by team leads with minimal support from a project manager.

(b)Lean projects: These are essentially process improvement exercises which may include activities like value stream mapping, root cause analysis, solution prioritization and design of experiments. These initiatives bring forth a blend of quality methodology and project management methodology and is usually led by the quality team within an organization with minimal assistance from a project manager.

(c)Projects: These are full blown projects which have the required complexity of a project and hence are expected to follow the rigor of project management. However, more often than not, these projects do have a focus on organization strategy, stakeholder expectations, benefit sustainment and change management, to the extent that diffuses the demarcation between a project and a program. And it is in these scenarios that a Project Manager ends up playing the role of a Program Manager.
Stand – alone projects, especially in the knowledge industry, is becoming rare and infrequent and hence organizations want their project managers to don the hat of a program manager ever so often. This is a primary reason for the emergence of the role of a program manager.

(2)Project Manager Demographics:

Early adopters to project management methodology (and by extrapolation, credential holders of PMP®) would be moving up in their roles, responsibilities and designations and would logically like to climb the next step of Program Management in their careers. These professionals, in turn, would operating from a perspective of a program manager, providing a potential shift from project management to program management.

table1

A study conducted by Project Management Institute on the demographics of successful PgMP® credential holders revealed the following:

  • A whopping 62% of the respondents were in the age group of 36 – 50, indicating 10 to 25 years of professional experience
  • 80% of the successful respondents were in the age group of 36 – 55 years.

This was further corroborated by analyzing the number of years of project management experience of the successful credential holders, and the results looked as follows:

table1
  • 52% of the respondents had more than 15 years of experience as project managers
  • 85% of the successful credential holders had more than 10 years of experience

High number of experienced project management professionals opting to gain the program management credential and eventually transition to a program management role goes on to the prove the hypothesis. Relatively younger project management professionals not opting to take the plunge further corroborates the point.

Conclusion:
It doesn’t really matter what nomenclature an organization uses for project management professionals. As long as the organization, its PMO (if it does have one) and the individual concerned are aligned with the expectations, it would be an enriching experience and association for all stakeholders concerned, and project management would be the winner.

Why do Projects Fail

Projects are high visibility, and generally high-value initiatives undertaken by organizations with an aim to make a significant difference in which they conduct business. However, every year, organizations around the world bear the brunt of millions of dollars wasted in the form of failed projects. Furthermore, in a bid to salvage or bring such projects on track, another fortune is spent on expensive consultants to assess and recover failing projects. The resultant, more often than not, is a significant deviation from the original plan, and a disproportionate degree of success. Such projects are labeled as “failed”.

What causes a project to fail? How often do projects fail? What kinds of projects are more likely to fail? These are some of the questions that arise to the thinking mind. Before we get on to find the root causes of project failure, let’s look at some statistics to get a perspective of how “big” an issue are we talking about.

  • In 2018, nearly 70% of projects met their original goals or business intent (30% failure), while nearly 60% were completed within the original budget (40% overrun). Both these figures are up from 62% (38% failure) and 50% (50% overrun) respectively in 2016. (PMI)
  • A survey published in HBR found that the average IT project overran its budget by 27%. Moreover, at least one in six IT projects turns into a “black swan” with a cost overrun of 200% and a schedule overrun of 70%. (HBR)
  • Among IT projects, failure rate corresponds heavily to project size. An IT project with a budget over $1M is 50% more likely to fail than one with a budget below $350,000. For such large IT projects, functionality issues and schedule overruns are the top two causes of failure (at 22% and 28%
    respectively). (Gartner)
  • A PwC study of over 10,640 projects found that օnly 2.5% of companies complete their projects 100% successfully. The rest either failed to meet some of their original targets or missed the original budget or deadlines.
  • Failed IT projects alone cost the United States $50-$150B in lost revenue and productivity. (Gallup)
  • While software projects have an average cost overrun of 66%, the same figure for non-software projects is 43%. However, 133% of non-software projects fail to meet their stated benefits, compared to just 17% for software projects. (McKinsey)
  • 17% of IT projects can go so bad that they can threaten the very existence of the company. (McKinsey)
Image for blog

Bridge on the river Choluteca

Bridge on the river Choluteca

Search this one up, this would give you some perspective. This is in Honduras, Central America. It’s a fine, well-built bridge except that the river does not flow under it, but to one side. It’s rather funny when you see it, but it must be tragically unfunny for those who depended on the bridge. Apparently, when the bridge was built, it was in the correct place. However, a massive hurricane came and caused terrible flooding. It completely destroyed the approach roads, and forced the river to chart a new course, leaving the bridge spanning dry land! Many failed projects come to resemble the bridge, giving a grim reminder to the fact that projects can be left “high and dry” when they do not adapt and adopt to the changing environment.

Common Causes of Project Failure

While there can be multiple reasons of project failure, the usual suspects are the following:

  • Scope Creep: Scope for a project is sacrosanct and should always be zealously guarded. However, when scope is subjected to unplanned changes outside the agreed control mechanism, all project parameters start behaving erratically and are the first warning bells indicating “spoilers ahead”.
  • Poor resource allocation: Certain organizations encourage their resources to treat projects as “side of the desk job”, resulting in certain resources being allocated for far too many projects than they can actually handle. On the other hand, there are instances when there are far too many resources working on a project. Both scenarios are recipes for project disaster.
  • Poor communication: Importance of communication in a project environment cannot be overstated. Lack of a well-crafted communication strategy catering to all project stakeholders is a potent situation for unwarranted developments in the project, those that do not augur well for the success of the project.
  • Poor Stakeholder Management: This goes hand in hand with the communication. Not knowing your stakeholder well in a project is akin to a time bomb waiting to explode. Expectations, when not managed, can run wild, and when they do, project is the first thing to get sacrificed.
  • Unsupported project culture – “Culture eats strategy for breakfast” a phrase originated by Peter Drucker and made famous by Mark Fields, President at Ford, is an absolute reality when it comes to project! Projects need a delicate balance between flexibility and rigidity, which is often provided by an environment, culture of projects. An unsupportive culture can be the single biggest factor for project failure.
Scroll to top
0 Items
د.إ0