Critical Chain Project Management – A brief overview

                              The below article will also be available on the Simplilearn Website

Critical Chain Project Management was developed and publicized by Dr. Eliyahu M. Goldratt in 1997. Followers of this methodology of Project Management claim it to be an alternative to the established standard of Project Management as advocated by PMBOK® and other Standards of Project Management.  This article attempts to provide a brief overview of the Principals of Critical Chain Project Management and its applicability to manage Projects across all organizations and verticals.

                The Critical Chain Method has its roots in another one of Dr. Goldratt’s inventions viz The Theory of Constraints (TOC). This Project Management Method comes into force after the initial Project Schedule is prepared, which includes establishment of the task dependencies.  The evolved Critical path is reworked based on the Critical Chain Method. To do so, the methodology suggests and assumes constraints related to each task. A few of them are elaborated as under.

Ø  There is a certain amount of uncertainty in each task

Ø  The task Durations are overestimated by the Team Members or Task Owners. This is typically done to add a safety margin to the task so as to be certain of its completion in the decided duration.

Ø  In most cases, the tasks should not take the time estimated, which includes the safety margin, and should be completed earlier.

Ø  If the Safety Margin assumed is not needed, it is actually wasted. If the task completes earlier, it may not necessarily mean that the successor task can start earlier as the resources required for the successor task are not available until their schedule time. Hence the saved time cannot be passed on to finish the Project early. On the other hand, if there are delays over and above the estimated schedules, these delays will most definitely get passed on, and in most of the cases, will exponentially increase the Project Schedule.

With the above assumptions, the Critical Path Methodology of Project Management recommends pooling of the task buffers and adding them at the end of the Critical path.

              

            The Critical Path Project Management defines 3 types of Buffers

1.       Project Buffer -         The total pooled buffer shown above(Fig 1.1) is referred to as the Project Buffer

2.       Feeding Buffer -       In a Project Network there are path/s which feed into the Critical path. The pooled buffer on each such path represents the Feeding Buffer to the Critical Path(Fig1.2) resulting in providing some slack to the critical Path.

3.       Resource Buffer-     This is a virtual task inserted just prior to critical chain tasks that require critical resources. This acts as a trigger point for the resource indicating when the critical path is about to start.

              

           As the Progress of the Project is reported the Critical Chain is recalculated. In fact, monitoring and controlling of the Project primarily focusses on utilization of the Buffers. Hence the Critical Chain Method, takes in the basic Critical Path based Project Network and Schedule and derives a completely new Schedule.

The Critical Path Project Management Methodology proves to be very effective in organizations, which do not have evolved Project Management Practices. Also, it is seen that the methodology does not advocate multi-tasking and hence in Projects with complex Schedule Networks, the results of implementing the Critical path Methodology have proven to be deterrent to the overall Project Schedule. Additionally, there is no standard method which has evolved for calculating and optimizing the Project Buffers. The Critical Path Project Management Methodology has had a fair amount of success in Manufacturing domains though it has not achieved any noteworthy success in IT Sector.

                Similar in lines with the principals of Critical Chain Methodology, the Event Chain Methodology of Project Management focusses on determining the uncertain events and the chain Reactions they propagate. It is a method of modelling uncertainties and is based on Monte Carlo Analysis, Bayesian Believe Network and other established simulation methodologies. Events when occurred can cause other events triggering an Even Chain, which will effectively alter the course of the Project. Events and Event Chains are identified and a Quantitative Analysis is performed to determine the extent of the uncertainty and the probable impact of the same on the Project. From this exercise, Critical Event Chains are evolved which have the potential to cause the most impact on the Project. Event Chain diagrams are visual representation of the Event and Event Chains and their impact.

It is clear that the neither the Critical Path Project Management Methodology nor the Event Chain Methodology can be considered as alternatives to the standard Methodology for project Management as advocated by PMBOK®. While the Critical Path Project Management Methodology can be at best used as a tool for deriving Project Schedule networks, the Event Chain Methodology for Project Management can be used as a tool for Quantitative Risk Analysis.

Yogeeta Deshmukh   BE, ITIL, PMP 

Interpersonal Skills – Project Manager: A Demigod? - Part 1

This Article has been originally published at
http://blog.simplilearn.com/project-management/interpersonal-skills-project-manager-a-demigod-part-1

“Effective Project Management requires that a Project Manager should possess the following competencies and characteristics

Knowledge – This implies the Knowledge about Project Management, its standards and processes.

Performance – Refers to what the Project Manager is able to achieve when applying the Project Management Knowledge to a Project.

Personal – This refers to how the Project Manager behaves when performing activities in the Project. It covers the Project Manager’s attitude, core personality characteristics and leadership-the ability to guide the project team while achieving project objectives and balancing the project constraints.”

        The above is as suggested in the PMBOK® 4^th edition.  The guide has more than successfully elaborated on what activities to do (Perform) and how to do the same (Knowledge) for achieving Project Goals. But, if we study successful and not so successful projects across the globe in different industry verticals, we find more often than not, that the Personal Skills of the Project Manager are responsible for the outcome of the Project.

The PMBOK® lists the desired Interpersonal Skills for a Project Manager as below

•    Leadership
•   Team Building
•   Motivation
•  Communication
•   Influencing
•   Decision Making
•    Political and Cultural Awareness
•    Negotiation

           Quite an exhaustive list, isn’t it? Can one mere mortal possess all the above skills that too at a level to always deliver successful Projects? In real world, unless you are the President of the United States, you don’t really have all those skills. But, what Project Managers need to understand are the basic theories around the desired competencies. This article attempts to give an overview of these same theories.  

Leadership -       Peter Drucker famously stated that "management is doing things right; leadership is doing the right things." Leadership involves focussing the Team towards a common goal and helping them see the value in the work they do. The influence of a leader over his followers is often referred to as Power. A Project Manager can use any of the 5 kinds of Power elaborated below, as appropriate, to influence and Lead his team.

            Formal Power

Legitimate Power – The Project Charter Authorizes the Project Manager to a Project. This gives the Project Manager Legitimate Power. A Project Manager uses Legitimate Power when she or he assigns work to a team member.

Reward Power – This type of Power is conveyed when you reward a team member with bonus, increments, promotion, extra time off etc. Care should be taken to ensure that the Rewards are fair and that they are tied to specific goals. The Rewards should be designed so that everyone has an equal chance to achieve them.

Coercive or Punishment Power – This is exactly what is sounds like.  This is the Power you use to inflict Punishment for non-performance or poor behaviour.  Any reprimands should be in a closed door meeting.

            Personal Power

Expert Power – This comes from the Project Manager’s Skills, Experience and Knowledge. Having and demonstrating this Power goes a long way in positively influencing Team Members. Team Members respect you for your competencies and skills are more likely to follow your lead.

Referent Power – This kind of Power comes from being trusted and respected. Often a Project Manager wields Referent Power as he is seen to be trusted and admired by people in authority.

            A Project Manager demonstrating Personal Power over Formal Power has a greater probability of effectively influencing Team Members in achieving Project Goals.

Team Building-                  Team Building is much more than taking your team members for a night out. It involves helping your team members bond with each other resulting in an environment of mutual trust and commitment. Team Building requires definition of a common purpose supported by open communication, timely conflict management, motivation and leadership. Good Teams can be built by setting up ground rules and being open in decision making.  The Project Manager should focus on eliminating difficulties and obstacles which interfere with the team’s ability to perform.

Motivation-        Motivating your team is all about helping your team members be satisfied with the job they are doing, recognizing them for their efforts and keeping them challenged. Awareness of motivational theories can help Project Managers to maximize team performance.

a.       Maslow’s Hierarchy of Needs

All human needs are structured in a hierarchy and only when the lower needs have been fully met, will a member be motivated by the opportunity of having the next need up in the hierarchy satisfied. A Project Manager should therefore offer different incentives to team members in order to help them fulfill each need in turn and progress up the hierarchy (see below). Managers should recognise that all members are not motivated in the same way and do not all move up the hierarchy at the same pace. They may therefore have to offer a slightly different set of incentives from member to member.

b.      Herzberg’s Motivation-Hygiene Theory

According to this Herzberg’s theory, there are  factors that would de-motivate a team member if not present but would not in themselves actually motivate her/him to work harder, also known as the Hygiene factors eg Paycheck.  There are also other factors, which a Manager can introduce which can directly motivate the members eg. Interesting work, opportunity for growth, extra responsibility, empowerment etc.

c.       McGregor’s Theory X and Theory Y

According to Mc Gregor, theory X managers are those who assume that Team Members are inherently lazy and will avoid work if they can and that they inherently dislike work. As a result of this, this kind of manager believes that workers need to be closely supervised and comprehensive systems of controls developed.

Theory Y managers assume that team members may be ambitious and self-motivated and exercise self-control. A Theory Y manager believes that, given the right conditions, most people will want to do well at work. They believe that the satisfaction of doing a good job is a strong motivation in itself.

d.      Expectancy Theory

The theory proposes that a member will decide to behave or act in a certain way because she / he is motivated to select a specific behaviour over other behaviours due to what she / he expects the result of that selected behaviour will be. The Project Manager needs to give people an expectation of a reward, which is achievable.

e.      McClelland’s Achievement theory

This theory states that human behaviour is affected by three needs - Need for Power, Achievement and Affiliation. Power is having an influence or control. Achievement is the urge to excel and to achieve success. Affiliation is being part of a group and having sociable inter personal skills.

Conclusion-        We elaborated on 3 areas of Inter Personal skills required for a Project Manager to deliver Successful Projects. In the concluding part, published separately, I will be talking the readers through some more Personal Skills.

Yogeeta Deshmukh   BE, ITIL, PMP

References

PMBOK® 4th edition

Head First PMP, 2^nd Edition – by Jennifer Greene and Andrew Stellman

http://pmworldjournal.net/article/challenges-of-managing-a-virtual-team-with-an-ocean-in-between/

Evolution of Project Management Life Cycles

           This article is published at http://blog.simplilearn.com/project-management/project-management-life- cycles-evolution-over-the-years. The below post is a reproduction of the same.

“The only thing constant in life is change”

-          Francois de la Rochefoucauld (1613-1680)

In Utopia, for Projects being implemented, there will be no change in specifications, scope, cost or resources, throughout the Life Cycle of the Project after the Project Management Plan is base lined and signed off. There will be no failed Projects and no reworks required. Projects will have no defects and will be accepted by the Customers on Delivery. Unfortunately, there is no Utopia and Project Managers globally have to be on their toes to deal with changing scenarios.  This article attempts to equip Project Managers with the knowledge of various Project Life Cycle Approaches so as to help them deal with changes on their Projects.

A Project typically has a number of Phases. The number of phases, their need for the Project and the level of control required over each phase are primarily defined by the nature of the Project, the complexity of the same and the industry to which the Project has to cater to.

Project Phases are generally sequential in nature but may have overlapping relationships. The phases and the relationships together form the Project Management Life Cycle. Further the Project Management Life Cycle to be adopted is frequently part of the Organizations’ Project Management Standards. In real life a Project Manager may not have a say in the Life Cycle approach to be adopted, but understanding the different approaches and methodologies can help a Project Manager better adapt to changes.

The Traditional Project Management Life Cycle – This is also known as the Waterfall method. PMBOK 5 refers to this method as the ‘Predictive Life Cycle’. In this type of model, the phases defined may have sequential or overlapping relations or even a combination of both. Work performed in each phase is distinct from the predecessor or the successor phase. This type of approach suits well to small projects with minimal complexity and where the product to be delivered is fairly well understood.

As depicted in the above figure, exit criteria have to be satisfied before commencing into the successor phase. There is a high level of emphasis on Documents and document sign offs.  Major constraints in following this kind of Life Cycle Approach or model is the incapability of the model to adapt to changes without resulting in major reworks or workarounds. This is one of the primary factors which resulted in the evolution of newer approaches which were more focused on Change.

The Iterative Project Management Life Cycle – This approach evolved to counter the existing   constraints in the traditional approach especially where there was a need to adapt to changes. In this approach the processes in each phase are iterated till the phase exit criteria is met. Truly speaking this approach was just a baby step in the evolution of project management Life Cycles.

It is clear from the above figure that the Iterative Cycle is nothing but a series of mini-waterfalls.  It can be adopted for less complex and small projects where the deliverables are fairly understood. It allows a relatively better insulation to changes over the Traditional approach.

The Incremental Project Management Life Cycle – In this kind of approach the product is developed over a series of incremental steps. The approach is cyclic in nature and each cycle delivers an added functionality. The process is repeated till the exit criteria for the product or deliverable is fully met. Large and complex projects greatly benefit from following this model. It supports prototyping and customer interaction is quite high in the build phase of the Project.

The Incremental model is much better equipped to handle change. Each incremental functionality is verified by the customer and hence the relative risk in managing large and complex projects is substantially reduced. On the downside, there is a possibility of gold plating, wherein the functionalities not really required end up being built into the Product or Deliverable.

The Adaptive Project Management Life Cycle – These methods are also known as change-driven or Agile methods. This approach to Project Management is a combination of both the Iterative and Incremental models. The iterations are very rapid and time bound. In the Adaptive Life Cycle, Customer Involvement is the key to successful Projects. The customer and the sponsor form a part of the Delivery Team. Sometimes in Agile approaches, the phases may not be clearly defined. It relies heavily on customer feedback and the ability of the team to quickly work on the feedback and incorporate the same into the Project. Communication and Collaboration are of paramount importance in implementing Projects using the Agile methodologies.

An Agile approach is suitable for complex projects where the requirements are absolutely unclear, but it is possible to define incremental requirements. Some of the major challenges in adopting the Agile approach are required high levels of Customer Involvement (which may not always be possible or practical). Also, having a Virtual Team may work against the required enhanced collaborative approach.

Conclusion -       Project Management Life Cycles have thus evolved from the need of to deliver successful projects. The ability of the Project Team or Organization, to adapt to a particular framework of Project Life Cycle considering the nature of the Project, goes a long way in delivering the Right Product, Result or Service. The Project Management Institute, PMI, has played a significant role in advocating the different Project Management Life Cycle methodologies. The Project Management Body of Knowledge is regularly updated. The PMBOK5 has for the first time, included brief write-ups on the different Project Management Life cycle approaches being followed worldwide for Project Implementation.

Yogeeta Deshmukh   BE, ITIL, PMP

References -      PMBOK V^th Edition

                         Adaptive Project Framework - Manage Complexity in the face of Uncertainty 

                                                                      – by Robert K. Wysocki

                         http://www.agilemodelling.com

Effective Stakeholder Engagement -The right step towards meeting Project Goals

      Often in the real world, Projects are reported to deliver suboptimal deliverables.  Many estimates and studies have place ERP failure rates to as high as 60%. There are innumerable published articles citing top reasons for ERP failure. No Management Buy-In, Resistance to change, Inadequate Requirement definitions, Unrealistic Expectations etc. are cited here as few of those top reasons for failures.

      All these truly stem from inadequate or ineffective Stakeholder Engagement Programs.  Stakeholder Management is one of the fundamental areas of Project Management, and the level of adoption can effectively make or break your Project. The Project Management Institute has taken due cognizance of this and has incorporated ‘Project Stakeholder Management’ as a distinct Knowledge Area in the V^th edition of the PMBOK guide.  In the previous edition, Project Stakeholder Management was a part of Project Communications Management.

     One of the key processes of ‘Stakeholder Management’ is to define and design an effective Stakeholder Engagement Plan.  In the Identify Stakeholder process, the mapping of Stakeholders is done and the Stakeholder Power/Influence/Impact is duly noted and registered. The need to enhance Stakeholder Engagement in a bid to deliver successful Projects has been reiterated in different Projects across the globe. In this context it is important to classify the Stakeholder Engagement Levels.  Such Engagement Levels are classified as

1.   Unaware –   If sufficient effort is undertaken in Identifying Stakeholders, your projects should ideally not have stakeholders who are Unaware of the Project or it Potential Benefits and Impacts. It is possible that in an IT / ERP implementation kind of project, the grass root people in the Organization, may be aware of the Project but not of its potential benefits in the larger scheme of things. The Project Manager in such situation may have run campaigns; use in-house magazines etc. to spread awareness of the Project.

2.   Resistant – These Stakeholders are aware of the Project, of its potential impacts but are resistant to change.  Stakeholders classified at this engagement level can seriously jeopardize the Project Deliverables. It is all the more problematic if the Stakeholders under this level are also those who have a high Power or Influence over the Project. This is one of the top reasons for ERP failures. Effective Change Management Strategies need to be adopted to take the engagement level of such Stakeholders to a more desired level. Appropriate Reward and Recognition Systems should be devised.  

3.  Neutral – Stakeholders having this level of engagement are aware of the project but are neither supportive nor resistant. In most scenarios, not much will be required to be done here except when the Stakeholders falling under this level have been identified as having high Power or Influence over the Project. In such cases, effort should be expended to take such Stakeholders to a more desired engagement level.

4.  Supportive – Stakeholders are aware of the Project and are supportive to Changes. This should be the desired engagement level of most stakeholders.

5.   Leading – Stakeholders are aware of the Project and its potential impacts and are actively engaged in ensuring the success of the Project. Stakeholders with high influence on the project should ideally reach this level of engagement.

     Stakeholder Management is all about creating and maintaining relationships among Project Stakeholders with the aim to achieve appropriate Stakeholder Engagement Levels and subsequently successful Projects. As is evident from the above, Communications and collaboration forms the backbone of effective Stakeholder Management Strategy which can potentially result in achieving all desired Project Goals.

Yogeeta Deshmukh   BE, ITIL, PMP