Search

How are Changeless Principles Responsible For Project success In Software Industry?

IntroductionNo other industry perhaps is characterized by a change as much as the software industry. While every segment of society and more so the industry, goes through change, the pace and magnitude of change in the software industry are leaps and bounds ahead of all other segments.This magnitude of change can be unsettling as just when one thinks that one has cracked the secret of success, the rug is pulled from under the feet by the change and success formulae have to be reinvented all over again. In such turbulent scenarios, how do leaders respond to the changes and succeed? What is their recipe for success?This article is about how leaders don’t get swept away by the changes but respond smartly to the changes in a thoughtful manner. They hold the bull by the horn, so to say, and rule the changes rather than being dictated by the changes. One of their secrets to success is that they anchor themselves in constant principles that don’t change and respond to changes based on these changeless principles.What are these changeless principles of the software industry? This article highlights 5 most impactful principles that don’t change and have lead to proven success in software delivery.What are the changeless principles?The changes in the software industry happen in almost all facets, be it technology, software development methodologies, and life cycle models, business model, contract types, you name the facet and you can see changes.Specifically, 5 types of changes impact software project success significantly and they are requirement changes, the life cycle model changes, estimation methods becoming obsolete, project scheduling methods becoming ineffective and the emergence of new risks.Every change brings along with it new challenges and simply embracing the change can potentially create new problems while solving some old problems. Slogans such as “Don’t resist the change, embrace it instead!” or considering being open to changes as a virtue aren’t enough to succeed amidst the change.For instance, when an estimation methodology becomes obsolete because of a new technology, what does one mean by not resisting the change or embracing the change?Teams simply become technically competent in the new technology but regress back to raw, unstructured estimation method rather than creating a new estimation method. However, leaders respond to changes differently. They step back and look at the change from a meta-level, realize that the meta-principle that hasn’t changed and re-apply that meta-principle to the changed situation and remain effective.Coming back to the estimation example, when an existing estimation method becomes obsolete with the change of technology, they look at the meta-procedure of creating estimation method itself (Which doesn’t change) and create a new deliverable-based estimation methodology for the new technology rather than regressing back to raw, unstructured estimation methods.Thus they maintain estimation accuracy and project success in spite of the change. On these lines, the following are the 5 principles that don’t change in the software industry:1) The Principle of requirement change: Encourage changes occurring due to external factors but discourage or eliminate changes occurring due to the  internal factors. This principle doesn’t change irrespective of the emergence of new ways of managing requirements.2) The Principle of life cycle models: The 5 phases of any life cycle don’t change and you should create your own life cycle model when faced with a new situation. In spite of new life cycle methods emerging, the 5 phases namely, requirements, solution specification, a design of the solution, implementation of solution and testing of solution don’t change. One can always tailor-make these 5 phases to create a new life cycle.3) The Principle of estimation methodologies: The procedure to create deliverable based estimation methodologies does not change; create a new deliverable-based estimation method when technology changes. Established estimation methodologies become obsolete when technology changes but the meta-method of creating a new estimation methodologies doesn’t change. Hence, creating new estimation methodology using this meta-method is essential to maintain estimation accuracy.4) The Principle of schedule management: Project schedules are effective when the work breakdown is aligned with the life cycle model and contains at least 90% of the tasks performed by the team on the ground.  As life cycle models change, old methods of drawing up project schedules become ineffective and teams either give up drawing an effective schedule or draw schedules that are not used. However, aligning the schedules to the new life cycle models ensures that schedules are effective and results in optimum resource utilization.5) The Principle of risk management: It is essential to prioritize identified risks and plan mitigation and contingencies irrespective of size and complexity of the project. The types of risks may vary as project environment changes, but the basic principle of risk prioritization, mitigation ,and contingency planning does not change. As contract types, business models, life cycle models and technologies change, the types of risks may change, but the basic principle of risk management do not change and this has to be implemented completely to increase chances of project success.Why only these 5 principles? Are there not other principles that are important? Well, there could be many principles that don’t change and have to be applied for project success, but these 5 are the most important principles critical to project success and the most challenging too.There are principles related to the stakeholder management, product design, testing, team management and so on, but dealing with all of them would perhaps be apt for a complete user manual on changeless principle and not for an article. Hence 5 most important principles have been chosen for illustration in this article.Illustration of the 5 principles1) The Principle of requirement change:Encourage changes occurring due to external factors but discourage or eliminate changes occurring due to internal factors.Well, requirement changes are the order of the day in software projects and the way requirement changes are managed differs with software development methodologies and life cycle models. While the earlier CMMi based school of thought insisted on defining and signing off on requirements early in the lifecycle and keeping the changes to a minimum subsequently, the Agile school of thought went to another extreme saying that they encourage requirement changes and both are right in their own perspective.While minimum requirement changes are good for the stability of the project in terms of conformance to plan, encouragement for requirement changes could be good for business success as business scenarios can be dynamic and IT should keep pace with business dynamics.So, it is clear that there is an Agile wave now and it is altering the way that we look at the requirement changes. And, let’s see how the mass goes with this change and how leaders respond. Those who simply “Embrace” the change, go with Agile methodologies at face value, accept that requirements can keep changing and suffer the consequences.For instance, some IT vendors enter into fixed-price contracts for Agile projects based on some initial understanding of scope, and because of progressive elaboration of scope, the customer keeps giving requirements at every release which bloats the scope so much that the project easily gets into schedule overruns and cost overruns. This could result in losses for the vendor and if not handled well, it could result in dissatisfaction of the customer and loss of business as well. However, thought leaders take a step back and look at why requirements change and come up with responses that keep both customer interest and their own interest in mind. Leffingwell et. al.[1] have researched into why requirements changes and classify the causes into two sets called internal factors and external factors.Internal factors have to do with who we elicit requirements from, and how we elicit requirements. If requirements are not elicited from the right stakeholders and if the right elicitation techniques are not used, then it results in unclear and incomplete requirements leading to subsequent changes. Such changes are avoidable through the appropriate usage of elicitation techniques and documentation.This is why the BABoK (Business Analysis Body of Knowledge)[2] lists more than 30 techniques to elicit, analyze and document requirements. These techniques have to be used effectively to eliminate changes occurring because of internal factors.The external factors, on the other hand, have to do with changes to market conditions, competitive landscape, and legal compliance needs. The changes are needed for the business success of the projects and can’t be easily foreseen.Postponing such changes may have serious, adverse impact on business objectives and hence such changes must be accommodated into the present release as quickly as possible. Leaders who succeed with Agile projects follow this principle, insist on upfront clarity in scope at a high level and then allow progressive elaboration of scope over the releases for more details.That is, they use a multitude of apt techniques to elicit and document requirements from the right stakeholders upfront so that their get clear and complete requirements and hence eliminate changes occurring due to internal factors.However, they would not insist on “Freezing” the requirements but allow progressive elaboration of details of these requirements to accommodate changes happening due to external factors. Thus they achieve both interests – proper estimation and planning for efficient delivery and cost-effectiveness through upfront clarity and completeness of high-level requirements and also ensure quick alignment with changing business scenario through a progressive elaboration of detailed requirements.2) The Principle of life cycle models:The 5 phases of any life cycle don’t change and you should create your own life cycle model when faced with a new situation.Lifecycle models keep emerging and every time there is a new lifecycle model, it impacts the project schedules, communication reports, team ramp up and ramp down plans, and quality plans mainly. However, as some industry experts such as Karl Wiegers [3] suggest, these life cycle models have little difference and the masses may get swept away by the hype involved in the new lifecycle model but leaders respond differently.Leaders understand that every new life cycle model brings with it solution to some existing problem but also a new set of problems. Hence, they accept the new models selectively and often adapt with the new lifecycle model by tailor-making it to their advantage. They can do this tailoring based on the understanding that the 5 phases of a lifecycle model are changeless.Software development models have emerged under many names beginning from waterfall, V, RAD, evolutionary methods, iterative, incremental, spiral, RUP and finally fully Agile methods such as Scrum, XP, and Kanban. The life cycle models mainly define how the 5 phases such as requirements, functional specification, design, implementation and testing are woven. The fact that any development project, not just the software projects involve all the 5 phases is a changeless principle as established below:Problem definition:This phase can be alternately called Scoping, Requirements Specification etc., and defines what the customer needs are that should be translated into deliverables. Any project exists because there are customer needs and hence this phase cannot be done away with.Solution specification:Alternately called functional specification, analysis phase, feature specification etc., this phase defines what the proposed solution is for the customer need. Any project is an implementation of solution to a customer need and solution definition cannot be done away with.Solution design:Alternatively called design, low-level design etc., this phase defines “HOW” the solution will be implemented. Any nontrivial solution needs to be designed and in that sense, this phase is indispensable too.Solution implementation:Alternatively called implementation phase, construction phase, the coding phase, this phase implements the designed solution. It is this phase that produces the actual deliverables and hence indispensable.Testing:This phase involves multiple types of testing and tests the implemented solution against the specified requirements. No product can be released without testing and this phase is indispensable too.Given that these phases are indispensable, let’s see how different life cycle models weave them. The waterfall model involves a tight sequence among the 5 phases. That is, you cannot skip any phase and work on a phase without completing the previous one. The incremental model breaks down the scope into multiple increments but maintains the tight sequence among the phases within each increment.However, Scrum not only breaks the scope into multiple increments called “Sprints”, but also removes the tight sequence among the 5 phases. For instance, one can do coding for a feature without an approved design for the same.Hence, the Agile model provides more freedom and flexibility to developers compared to the incremental model or the full-fledged waterfall model. While this freedom sounds attractive, if the team is not multi-skilled and seasoned enough, the resulting product may contain spaghetti code and become unmaintainable. Also, if the team is not multi-skilled, the Agile model may not result in optimum resource utilization.Given this backdrop, while the masses embrace the Agile model mechanically and suffer the consequences of chaos and underutilization (while also realizing some benefits), the leaders respond differently. They may adopt Agile fully if suitable, but if not, they create tailor-made hybrid models.Most of the recent successful megaprojects showcased at PMI conferences implemented hybrid models that involved elements of agility but imposed certain discipline as well. The latest version of PMBoK lists hybrid life cycle models as a trend in project management [4].To illustrate a hybrid model, factory model that was one of the many hybrid models implemented in Wipro Technologies and published as a case study at Harvard [5] can be taken as an example.Factory model is a software service delivery model and software development life cycle is only a part of it and this article illustrates only the life cycle part of the factory model. As illustrated in diagram 1, factory model involves frequent releases that are pre-scheduled and requirements are accepted even after the requirements document is signed off and subsequent phases are in progress.However, there is a cutoff date for requirements inflow after which the incoming requirements would be allocated to the next release. As the releases are shorter and the customers have a look ahead, usually they would be willing to wait for the next release rather than pressing for inclusion of requirements into the current release.This is a hybrid model, which has Agile features namely shorter releases and openness to accept requirements even after signing off RS. But, it also has traditional features such as tight binding of life cycle phases within a single release and freezing the requirements beyond the requirement window. There are many such hybrid models used effectively by industry leaders.3) Principle of estimation methodologies:The procedure to create deliverable based estimation methodologies does not change; create a new deliverable-based estimation method when technology changes.As new technologies emerge, one of the consequences is that established estimation methodologies become obsolete. For instance, when the Function Points estimation method was created for COBOL applications, it became quite widely used. The units into which the functionality of an application is broken down into, such as “Internal logical files”, “Record types” etc., was natural to COBOL applications.However, with the emergence of GUI based client-server applications, this model became a force-fit and estimators regressed back to carrying out unstructured raw estimates. This phenomenon happens every time there is a technology change. The masses follow raw, unstructured estimation method but the leaders develop new methodologies themselves.We have carried out research into the accuracy of estimates by asking the groups of people to estimate for the same specification using both raw method and structured methods and the results show stark differences in accuracy. Diagram 2 below contrasts estimates performed using unstructured, semi-structured and formal (completely structured) methodologies:As the above diagram compares estimation results performed by same people on the same specification with estimation method being the only variant, it can be concluded that estimation method plays a major role in determining the accuracy of estimates. Use of semi-structured and fully structured estimation methods improves the estimation accuracy significantly.Hence, the leaders use the changeless procedure to design new estimation methods and come up with a new estimation method themselves when technology changes. This procedure is as follows:Define the measure of application size.Define the units into which the specification is broken into.Define the factors to classify the complexity of the broken down unitsDefine the formula to arrive at size based on the number and complexity of broken down unitsDefine the method to determine effort from the size using productivity norms.This author explains in one of the previous papers [6] how different methodologies can be compared along the lines of the common procedure defined above and compares Function Points, Use case Points, MVC Points and structured WBS methods in a common format as shown in diagram 3 below:The author and colleagues have created two such deliverable-based open estimation methodologies namely MVC Points [6] and Interface points [7] intended to estimate web applications and enterprise application integration projects. We have also seen many unpublished methodologies to estimate data warehousing applications, ERP applications used in-house in leading IT organizations and usage of these methods greatly improve estimation accuracy.4) The Principle of schedule management:Project schedules are effective when the work breakdown is aligned with the life cycle model and contains at least 90% of the tasks performed by the team on the ground.  When life cycle models change, the way work is broken down also changes. It has been illustrated in earlier articles of this author [8][9] that alignment of work breakdown structure to the life cycle model is a critical factor that determines whether the schedule will be used in the project or not. When life cycle models change and the older ways of WBS doesn’t work, the masses give up scheduling practices but the leaders change the WBS and continue scheduling practices to ensure optimum resource utilization.Specifically, the arrival of Agile methodologies has rendered old ways of WBS obsolete. As shown in diagram 4, Agile methods view project progress in terms of completely usable features whereas traditional methods view project progress in terms of work done.Accordingly, the WBS also changes. A WBS of a traditional project would like table 1 belowTask IDMile stoneSummary tasksSub tasksDuration Resource.......1RS302Feature 1Elicit requirementsDocument requirement.......Feature 2....................FSFeature 1GUIBusiness logic.......Feature 2............Design........As can be seen in table 1, the WBS is organized along life cycle phases. As this does not work with Agile models, the common tendency is to give up schedules and execute work in ad hoc manner. However, leaders transpose the WBS to align with an Agile view of project progress as shown in table 2 and continue to use project schedules to optimize resource utilization.Task IDMile stoneSummary tasksSub tasksDurationResource1Release 1......2Feature 1RS related tasksOther task from sprint backlogOther task from sprint backlogFeature 2..................Release 2Feature 3GUIBusiness logicOther task from sprint backlogFeature 4............Release 3......5) Principle of risk management:It is essential to prioritize identified risks and plan mitigation and contingencies irrespective of size and complexity of the project.As changes occur in all facets of project execution, very new risks emerge and a common tendency is not to identify the risks but stick with the old risks and suffer the consequences. However, leaders stick to the constant principle of risk management and use that to identify and manage new risks. The risk management process that doesn’t change is indicated in the following diagram 5:To illustrate, when the outsourcing model changes from tactical outsourcing to strategic outsourcing, new, critical stakeholder risks emerge. When life cycle model changes to Agile, new cost-related risks emerge. However, the leaders stick on to the process of risk identification, risk prioritization, risk response planning and risk monitoring and control to stay on top of risks and maximize project success probability.ConclusionAs changes occur ever more frequently in all facets of software delivery, it is not adequate to respond with rhetoric such as “Embrace the change” or “Be open to change” although they are well-meaning phrases. It is important to respond to the change thoughtfully and taking a step back from the change and identifying the changeless principle behind the change helps in responding thoughtfully.This article has identified constant principles that don’t change in 5 facets of project delivery and anchoring in these changeless principles helps to respond to changes smartly and increase project success chances by leaps and bounds.

How are Changeless Principles Responsible For Project success In Software Industry?

2K
How are Changeless Principles Responsible For Project success In Software Industry?

Introduction

No other industry perhaps is characterized by a change as much as the software industry. While every segment of society and more so the industry, goes through change, the pace and magnitude of change in the software industry are leaps and bounds ahead of all other segments.

This magnitude of change can be unsettling as just when one thinks that one has cracked the secret of success, the rug is pulled from under the feet by the change and success formulae have to be reinvented all over again. In such turbulent scenarios, how do leaders respond to the changes and succeed? What is their recipe for success?

This article is about how leaders don’t get swept away by the changes but respond smartly to the changes in a thoughtful manner. They hold the bull by the horn, so to say, and rule the changes rather than being dictated by the changes. One of their secrets to success is that they anchor themselves in constant principles that don’t change and respond to changes based on these changeless principles.

What are these changeless principles of the software industry? This article highlights 5 most impactful principles that don’t change and have lead to proven success in software delivery.

What are the changeless principles?

The changes in the software industry happen in almost all facets, be it technology, software development methodologies, and life cycle models, business model, contract types, you name the facet and you can see changes.

Specifically, 5 types of changes impact software project success significantly and they are requirement changes, the life cycle model changes, estimation methods becoming obsolete, project scheduling methods becoming ineffective and the emergence of new risks.

Every change brings along with it new challenges and simply embracing the change can potentially create new problems while solving some old problems. Slogans such as “Don’t resist the change, embrace it instead!” or considering being open to changes as a virtue aren’t enough to succeed amidst the change.

For instance, when an estimation methodology becomes obsolete because of a new technology, what does one mean by not resisting the change or embracing the change?

Teams simply become technically competent in the new technology but regress back to raw, unstructured estimation method rather than creating a new estimation method. However, leaders respond to changes differently. They step back and look at the change from a meta-level, realize that the meta-principle that hasn’t changed and re-apply that meta-principle to the changed situation and remain effective.

Coming back to the estimation example, when an existing estimation method becomes obsolete with the change of technology, they look at the meta-procedure of creating estimation method itself (Which doesn’t change) and create a new deliverable-based estimation methodology for the new technology rather than regressing back to raw, unstructured estimation methods.

Thus they maintain estimation accuracy and project success in spite of the change. On these lines, the following are the 5 principles that don’t change in the software industry:
5 Changeless principles of Software industry


1) The Principle of requirement change: Encourage changes occurring due to external factors but discourage or eliminate changes occurring due to the  internal factors. This principle doesn’t change irrespective of the emergence of new ways of managing requirements.

2) The Principle of life cycle models: The 5 phases of any life cycle don’t change and you should create your own life cycle model when faced with a new situation. In spite of new life cycle methods emerging, the 5 phases namely, requirements, solution specification, a design of the solution, implementation of solution and testing of solution don’t change. One can always tailor-make these 5 phases to create a new life cycle.

3) The Principle of estimation methodologies: The procedure to create deliverable based estimation methodologies does not change; create a new deliverable-based estimation method when technology changes. Established estimation methodologies become obsolete when technology changes but the meta-method of creating a new estimation methodologies doesn’t change. Hence, creating new estimation methodology using this meta-method is essential to maintain estimation accuracy.

4) The Principle of schedule management: Project schedules are effective when the work breakdown is aligned with the life cycle model and contains at least 90% of the tasks performed by the team on the ground.  As life cycle models change, old methods of drawing up project schedules become ineffective and teams either give up drawing an effective schedule or draw schedules that are not used. However, aligning the schedules to the new life cycle models ensures that schedules are effective and results in optimum resource utilization.

5) The Principle of risk management: It is essential to prioritize identified risks and plan mitigation and contingencies irrespective of size and complexity of the project. The types of risks may vary as project environment changes, but the basic principle of risk prioritization, mitigation ,and contingency planning does not change. As contract types, business models, life cycle models and technologies change, the types of risks may change, but the basic principle of risk management do not change and this has to be implemented completely to increase chances of project success.

Why only these 5 principles? Are there not other principles that are important? Well, there could be many principles that don’t change and have to be applied for project success, but these 5 are the most important principles critical to project success and the most challenging too.

There are principles related to the stakeholder management, product design, testing, team management and so on, but dealing with all of them would perhaps be apt for a complete user manual on changeless principle and not for an article. Hence 5 most important principles have been chosen for illustration in this article.

Illustration of the 5 principles

1) The Principle of requirement change:

Encourage changes occurring due to external factors but discourage or eliminate changes occurring due to internal factors.

Well, requirement changes are the order of the day in software projects and the way requirement changes are managed differs with software development methodologies and life cycle models. While the earlier CMMi based school of thought insisted on defining and signing off on requirements early in the lifecycle and keeping the changes to a minimum subsequently, the Agile school of thought went to another extreme saying that they encourage requirement changes and both are right in their own perspective.

While minimum requirement changes are good for the stability of the project in terms of conformance to plan, encouragement for requirement changes could be good for business success as business scenarios can be dynamic and IT should keep pace with business dynamics.

So, it is clear that there is an Agile wave now and it is altering the way that we look at the requirement changes. And, let’s see how the mass goes with this change and how leaders respond. Those who simply “Embrace” the change, go with Agile methodologies at face value, accept that requirements can keep changing and suffer the consequences.

For instance, some IT vendors enter into fixed-price contracts for Agile projects based on some initial understanding of scope, and because of progressive elaboration of scope, the customer keeps giving requirements at every release which bloats the scope so much that the project easily gets into schedule overruns and cost overruns. This could result in losses for the vendor and if not handled well, it could result in dissatisfaction of the customer and loss of business as well.
 
However, thought leaders take a step back and look at why requirements change and come up with responses that keep both customer interest and their own interest in mind. Leffingwell et. al.[1] have researched into why requirements changes and classify the causes into two sets called internal factors and external factors.

Internal factors have to do with who we elicit requirements from, and how we elicit requirements. If requirements are not elicited from the right stakeholders and if the right elicitation techniques are not used, then it results in unclear and incomplete requirements leading to subsequent changes. Such changes are avoidable through the appropriate usage of elicitation techniques and documentation.

This is why the BABoK (Business Analysis Body of Knowledge)[2] lists more than 30 techniques to elicit, analyze and document requirements. These techniques have to be used effectively to eliminate changes occurring because of internal factors.

The external factors, on the other hand, have to do with changes to market conditions, competitive landscape, and legal compliance needs. The changes are needed for the business success of the projects and can’t be easily foreseen.

Postponing such changes may have serious, adverse impact on business objectives and hence such changes must be accommodated into the present release as quickly as possible. Leaders who succeed with Agile projects follow this principle, insist on upfront clarity in scope at a high level and then allow progressive elaboration of scope over the releases for more details.

That is, they use a multitude of apt techniques to elicit and document requirements from the right stakeholders upfront so that their get clear and complete requirements and hence eliminate changes occurring due to internal factors.

However, they would not insist on “Freezing” the requirements but allow progressive elaboration of details of these requirements to accommodate changes happening due to external factors. Thus they achieve both interests – proper estimation and planning for efficient delivery and cost-effectiveness through upfront clarity and completeness of high-level requirements and also ensure quick alignment with changing business scenario through a progressive elaboration of detailed requirements.

2) The Principle of life cycle models:

The 5 phases of any life cycle don’t change and you should create your own life cycle model when faced with a new situation.

Lifecycle models keep emerging and every time there is a new lifecycle model, it impacts the project schedules, communication reports, team ramp up and ramp down plans, and quality plans mainly. However, as some industry experts such as Karl Wiegers [3] suggest, these life cycle models have little difference and the masses may get swept away by the hype involved in the new lifecycle model but leaders respond differently.

Leaders understand that every new life cycle model brings with it solution to some existing problem but also a new set of problems. Hence, they accept the new models selectively and often adapt with the new lifecycle model by tailor-making it to their advantage. They can do this tailoring based on the understanding that the 5 phases of a lifecycle model are changeless.

Software development models have emerged under many names beginning from waterfall, V, RAD, evolutionary methods, iterative, incremental, spiral, RUP and finally fully Agile methods such as Scrum, XP, and Kanban. The life cycle models mainly define how the 5 phases such as requirements, functional specification, design, implementation and testing are woven. The fact that any development project, not just the software projects involve all the 5 phases is a changeless principle as established below:

  • Problem definition:
    This phase can be alternately called Scoping, Requirements Specification etc., and defines what the customer needs are that should be translated into deliverables. Any project exists because there are customer needs and hence this phase cannot be done away with.

  • Solution specification:
    Alternately called functional specification, analysis phase, feature specification etc., this phase defines what the proposed solution is for the customer need. Any project is an implementation of solution to a customer need and solution definition cannot be done away with.

  • Solution design:
    Alternatively called design, low-level design etc., this phase defines “HOW” the solution will be implemented. Any nontrivial solution needs to be designed and in that sense, this phase is indispensable too.

  • Solution implementation:
    Alternatively called implementation phase, construction phase, the coding phase, this phase implements the designed solution. It is this phase that produces the actual deliverables and hence indispensable.

  • Testing:
    This phase involves multiple types of testing and tests the implemented solution against the specified requirements. No product can be released without testing and this phase is indispensable too.

Given that these phases are indispensable, let’s see how different life cycle models weave them. The waterfall model involves a tight sequence among the 5 phases. That is, you cannot skip any phase and work on a phase without completing the previous one. The incremental model breaks down the scope into multiple increments but maintains the tight sequence among the phases within each increment.

However, Scrum not only breaks the scope into multiple increments called “Sprints”, but also removes the tight sequence among the 5 phases. For instance, one can do coding for a feature without an approved design for the same.

Hence, the Agile model provides more freedom and flexibility to developers compared to the incremental model or the full-fledged waterfall model. While this freedom sounds attractive, if the team is not multi-skilled and seasoned enough, the resulting product may contain spaghetti code and become unmaintainable. Also, if the team is not multi-skilled, the Agile model may not result in optimum resource utilization.

Given this backdrop, while the masses embrace the Agile model mechanically and suffer the consequences of chaos and underutilization (while also realizing some benefits), the leaders respond differently. They may adopt Agile fully if suitable, but if not, they create tailor-made hybrid models.

Most of the recent successful megaprojects showcased at PMI conferences implemented hybrid models that involved elements of agility but imposed certain discipline as well. The latest version of PMBoK lists hybrid life cycle models as a trend in project management [4].

To illustrate a hybrid model, factory model that was one of the many hybrid models implemented in Wipro Technologies and published as a case study at Harvard [5] can be taken as an example.
Factory Model Work flowFactory model is a software service delivery model and software development life cycle is only a part of it and this article illustrates only the life cycle part of the factory model. As illustrated in diagram 1, factory model involves frequent releases that are pre-scheduled and requirements are accepted even after the requirements document is signed off and subsequent phases are in progress.

However, there is a cutoff date for requirements inflow after which the incoming requirements would be allocated to the next release. As the releases are shorter and the customers have a look ahead, usually they would be willing to wait for the next release rather than pressing for inclusion of requirements into the current release.

This is a hybrid model, which has Agile features namely shorter releases and openness to accept requirements even after signing off RS. But, it also has traditional features such as tight binding of life cycle phases within a single release and freezing the requirements beyond the requirement window. There are many such hybrid models used effectively by industry leaders.

3) Principle of estimation methodologies:

The procedure to create deliverable based estimation methodologies does not change; create a new deliverable-based estimation method when technology changes.

As new technologies emerge, one of the consequences is that established estimation methodologies become obsolete. For instance, when the Function Points estimation method was created for COBOL applications, it became quite widely used. The units into which the functionality of an application is broken down into, such as “Internal logical files”, “Record types” etc., was natural to COBOL applications.

However, with the emergence of GUI based client-server applications, this model became a force-fit and estimators regressed back to carrying out unstructured raw estimates. This phenomenon happens every time there is a technology change. The masses follow raw, unstructured estimation method but the leaders develop new methodologies themselves.

We have carried out research into the accuracy of estimates by asking the groups of people to estimate for the same specification using both raw method and structured methods and the results show stark differences in accuracy. Diagram 2 below contrasts estimates performed using unstructured, semi-structured and formal (completely structured) methodologies:

Comparision of result
As the above diagram compares estimation results performed by same people on the same specification with estimation method being the only variant, it can be concluded that estimation method plays a major role in determining the accuracy of estimates. Use of semi-structured and fully structured estimation methods improves the estimation accuracy significantly.

Hence, the leaders use the changeless procedure to design new estimation methods and come up with a new estimation method themselves when technology changes. This procedure is as follows:

  1. Define the measure of application size.
  2. Define the units into which the specification is broken into.
  3. Define the factors to classify the complexity of the broken down units
  4. Define the formula to arrive at size based on the number and complexity of broken down units
  5. Define the method to determine effort from the size using productivity norms.

This author explains in one of the previous papers [6] how different methodologies can be compared along the lines of the common procedure defined above and compares Function Points, Use case Points, MVC Points and structured WBS methods in a common format as shown in diagram 3 below:
Comparison of estimation methodologies
The author and colleagues have created two such deliverable-based open estimation methodologies namely MVC Points [6] and Interface points [7] intended to estimate web applications and enterprise application integration projects. We have also seen many unpublished methodologies to estimate data warehousing applications, ERP applications used in-house in leading IT organizations and usage of these methods greatly improve estimation accuracy.

4) The Principle of schedule management:

Project schedules are effective when the work breakdown is aligned with the life cycle model and contains at least 90% of the tasks performed by the team on the ground.  

When life cycle models change, the way work is broken down also changes. It has been illustrated in earlier articles of this author [8][9] that alignment of work breakdown structure to the life cycle model is a critical factor that determines whether the schedule will be used in the project or not. When life cycle models change and the older ways of WBS doesn’t work, the masses give up scheduling practices but the leaders change the WBS and continue scheduling practices to ensure optimum resource utilization.

Specifically, the arrival of Agile methodologies has rendered old ways of WBS obsolete. As shown in diagram 4, Agile methods view project progress in terms of completely usable features whereas traditional methods view project progress in terms of work done.

Accordingly, the WBS also changes. A WBS of a traditional project would like table 1 below

Task IDMile stoneSummary tasksSub tasksDuration Resource.......
1RS

30

2
Feature 1






Elicit requirements





Document requirement





.......




Feature 2......




..............



FS






Feature 1






GUI





Business logic





.......




Feature 2......




......




Design





........





As can be seen in table 1, the WBS is organized along life cycle phases. As this does not work with Agile models, the common tendency is to give up schedules and execute work in ad hoc manner. However, leaders transpose the WBS to align with an Agile view of project progress as shown in table 2 and continue to use project schedules to optimize resource utilization.

Task IDMile stoneSummary tasksSub tasksDurationResource
1Release 1

......

2
Feature 1






RS related tasks





Other task from sprint backlog





Other task from sprint backlog




Feature 2......




............



Release 2






Feature 3






GUI





Business logic





Other task from sprint backlog




Feature 4......




......




Release 3





......





5) Principle of risk management:

It is essential to prioritize identified risks and plan mitigation and contingencies irrespective of size and complexity of the project.
As changes occur in all facets of project execution, very new risks emerge and a common tendency is not to identify the risks but stick with the old risks and suffer the consequences. However, leaders stick to the constant principle of risk management and use that to identify and manage new risks. The risk management process that doesn’t change is indicated in the following diagram 5:
Risk management
To illustrate, when the outsourcing model changes from tactical outsourcing to strategic outsourcing, new, critical stakeholder risks emerge. When life cycle model changes to Agile, new cost-related risks emerge. However, the leaders stick on to the process of risk identification, risk prioritization, risk response planning and risk monitoring and control to stay on top of risks and maximize project success probability.


Conclusion

As changes occur ever more frequently in all facets of software delivery, it is not adequate to respond with rhetoric such as “Embrace the change” or “Be open to change” although they are well-meaning phrases. It is important to respond to the change thoughtfully and taking a step back from the change and identifying the changeless principle behind the change helps in responding thoughtfully.

This article has identified constant principles that don’t change in 5 facets of project delivery and anchoring in these changeless principles helps to respond to changes smartly and increase project success chances by leaps and bounds.

KnowledgeHut

KnowledgeHut

Author

KnowledgeHut is an outcome-focused global ed-tech company. We help organizations and professionals unlock excellence through skills development. We offer training solutions under the people and process, data science, full-stack development, cybersecurity, future technologies and digital transformation verticals.
Website : https://www.knowledgehut.com

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

CAPM or PMP: Which Is Better?

Project Management is one of the fastest-growing professions around the world. Earning a project management certificate is not only a great way to build skills, position yourself as a valuable asset in your organization, and earn a bigger cheque, but also a great way to stay ahead of your peers. Two popular and in-demand certification options are the Project Management Professional (PMP) Certification and the Certified Associate in Project Management (CAPM) Certification. Both of these certifications are offered by Project Management Institute (PMI) and understanding the difference between these two certifications is critical to decide and choose the right course that fits your career goals.  In this blog, we will look into the differences between PMP and CAPM certification, including cost, difficulty levels, prerequisites, and industry demand; so, you can make an informed decision to fast-track your career towards success.CAPM vs PMP Certification: Which is Right for You?Before figuring out which course is right for you, let us start by understanding the differences. In simple terms, CAPM is considered as the beginner-level certification compared to PMP, which is a professional level course. Hence, the prerequisites required for CAPM are much lesser than PMP and the exam for CAPM is considered to be easier and less expensive as well. Having said that, PMP certification is better known, more prestigious, and highly likely to earn you a bigger paycheque.  The Certified Associate Project Management (CAPM)® will help you stand out from your competitors and enhance your effectiveness and credibility while working on different projects. On the other hand, the Project Management Professional (PMP) certification course is a qualification that is recognized industry wide. Becoming a PMP will enhance your work methodologies in any industry, regardless of the complexity of the projects being handled. This course covers a wide range of techniques and tools necessary in project management. This will help increase your earning potential as well as your confidence in your work. Difference between CAPM and PMPCategoryCertified Associate Project Management (CAPM)®Project Management Professional (PMP)®Difficulty LevelEntry LevelProfessional LevelBenefitsGreat recognition by peers and project managers.Potential salary increasesSteppingstone to becoming a PMPGreater credibility and confidenceNew job opportunitiesPotential salary increasesWhat is examinedKnowledge of Project Management processes and understanding of terminologyKnowledge of Project Management and the ability to apply the same in real-life scenarios.CostRelatively cheaper, compared to PMPRelatively more expensive, compared to CAPMBenefits of the CAPM and PMP CertificationsBoth CAPM and PMP have their own set of benefits. Let us look into each one of them.  If you wish to acquire a CAPM certification, you should know that it will enhance your efficiency and is recognized to distinguish you from the others in the industry. Benefits of CAPM course include: Recognition of your success from a renowned professional body in the industry Respect from your peers and project management professionals Increased confidence in your abilities Career progression Possibility of receiving a higher salary at work Affordable compared to PMP certification If you have made up your mind about taking up the PMP certification, it will benefit you in the following ways:  Professional recognition from your peers as well as the industry as a whole Higher understanding and experience in project management process Higher salary compared to un-certified project managers Wider range of job opportunities Greater professional responsibility Greater recognition compared to CAPM certification Both these courses give you access to a range of professional resources and an international network of fellow certificate holders. Certified Associate Project Management (CAPM)®Project Management Professional (PMP)®Respect from your peers and project management professionalsHigher understanding and experience in project management process.Increased confidence in your abilitiesHigher salary compared to un-certified project managers.Career progressionWider range of job opportunitiesPossibility of receiving a higher salary at workGreater professional responsibilityAffordable compared to PMP certificationGreater recognition compared to CAPM certificationHow Difficult are the CAPM and PMP Certification Exams?Before understanding the difficulty of the exams, let us learn the similarities between CAPM and PMP exams.Both CAPM and PMP exams use a Guide To The Project Management Body Of Knowledge (PMBOK Guide) as a base for their exams, but these two exams are not similar.  Both exams follow the multiple-choice format of questions and are computer-based. Paper tests may be allowed in special circumstances.Both the exams have non-scoring questions. The participant would not know which questions are non-scoring and hence it is important to answer all the questions given in the exam.With the right training and guidance, both these exams can be cleared. KnowledgeHut provides exam guidance and mock tests to help aspirants nail their exam in one go (hyperlink CAPM and PMP pages from KH)CAPM vs PMP Exam RequirementsThere are fewer guidelines for CAPM exam compared to PMP as it is created for entry-level professionals who have minimal to no project management experience. On the other hand, PMP requires more time and effort and is designed for professionals who have experience in project management. Let us look at the requirements in detail. CAPM Certification: A Secondary degree (high school diploma, an associate degree, or equivalent that is globally accepted) 23 hours of project management education before writing the exam. To complete this requirement, you may want to consider an exam preparation course. For example, Certified Associate in Project Management (CAPM) certification prepares you for the exam as well as meets the education requirement. PMP Certification:  There are two routes to consider a PMP Certification. Option 1: Secondary Degree (high school diploma, associate degree, or global equivalent) 60 months of experience in leading projects. 35 hours of project management education or a CAPM certification. Option 2:  A four-year degree 36 months of experience in leading projects. 35 hours of project management education or a CAPM certification. PMI will waive off the 35-hour education requirement for the PMP exam if you are an active CAPM certification holder.CAPM vs PMP Exams: What to Expect Like mentioned earlier, there are many similarities between CAPM and PMP exams. Both follow the PMBOK Guide and are designed by PMI and administered by Pearson VUE. Both exams cover a few of the same topics and neither exam allows reference material during the test. But there are some unique features to each of these exams. They are: CAPM vs PMP ExamCAPM ExamPMP ExamExam Components150 multiple-choice questions180 questions including multiple-choice, multiple response, matching, hotspot, and limited fill-in-the-blanksExam Time Limit3 hours or 180 minutes3 hours and 50 minutes or 230 minutes.Exam ContentCovers chapters from 1 to 13 of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)  Covers three domains: People, Process, and Business Environment. Use the PMP Examination Content Outline provided by PMI to prepare.  Non-scoring questions15 questions25 questionsFormat of examMultiple choiceMultiple choiceMethod of examComputer-basedComputer-basedPMP vs CAPM: Roles and Responsibilities in Real WorldThe real understanding of either of these certifications happens when you understand their real-world applications. After all, certifications are a means to a better career and if they do not meet your expectations, you should reconsider your choices.  CAPM will give you a chance to start with entry-level project management roles. Assistant project manager, project coordinator, junior business analyst are some positions you would be qualified for. In these roles, you would be applying your coordinating skills, scheduling meetings, and creating an effective platform for communication.  However, if you are someone with considerable technical experience, the CAPM certification will pave the way for a leadership position, which in turn can lead to a full-time project management position.  With a PMP certification, the scenario is slightly different. You will be qualified for full-time project management roles where you will deal with different projects of all sizes and complexities. Project manager, program manager, project controller are some roles in your reach with this certification. You will be expected to lead large projects to their success on time and within budget. Once you are at the PMP level, your performance expectations are high, and it is assumed that you come with a great project management history. Since we are on this topic, it is important to understand that a single certification is only a section of what qualifies you for a given role. Enterprises will also look into your account experience, overall performance, communication skills, leadership capabilities, and other important variables while hiring. To put it in simpler words, a PMP certification will imply that you are excellent when it comes to understanding and implying project management principles in real-world situations whereas, a CAPM certification will imply that you have a good grasp of conceptual understanding of project management principles. With this outlook, it is easier to understand why PMP has a higher level of demand and why PMPs are placed into roles with higher responsibilities. Can you convert a CAPM to PMP?You might think if converting a CAPM to PMP is possible. Since the CAPM is the first level on your PM journey, it does serve as the steppingstone to a PMP certification. While you cannot upgrade a CAPM to a PMP, obtaining a CAPM certification will definitely help you pursue a PMP certification. You will be able to add the project management education hours you gained while preparing for CAPM to your PMP exam prerequisite. But you cannot upgrade your CAPM certificate to a PMP certificate without sitting for and passing the PMP exam as well. If you are just beginning your career in project management, a CAPM certification can be a great step towards becoming a PMP and successfully shaping your career, with higher pay and recognition as a project manager.   Conclusion To wrap things up, we have discussed the differences, similarities, and prerequisites of each of these courses. Both PMP and CAPM certifications can add value to an aspiring project manager's career.  If you are someone just starting out in the project management field, CAPM is a recommended course as it is an entry-level certification. But on the other hand, if you have the necessary experience in the project management field, PMP should be your go-to course to enhance your career, as CAPM would do little for you from a development perspective in your career. Both these certifications have their own list of pros and cons. They are both highly recognized certifications and as a certification-seeker, you need to make your choice based on what you are eligible for and what your end goal is. What will you decide? 
3474
CAPM or PMP: Which Is Better?

Project Management is one of the fastest-growing p... Read More

The PMP® Exam Blueprint For 2019

Preparing for your PMP® exam might seem like a struggle, but the end result is quite rewarding. From the initial application process, you need to go through a lengthy procedure to become a PMP® certified professional. The PMP® exam tests the professionals on the five project management processes: Initiating, Planning, Executing, Monitoring and Controlling, and Closing.  It is also important for the candidates to have a thorough understanding of the nine knowledge areas under project management, which includes integration management, project scope management, time management, project resource management plan, procurement management, cost management, and time management.The PMP® certification is a validation of a professional’s experience in project management and is offered by the Project Management Institute (PMI) to those candidates who qualify the PMP® examination.The process of preparation can be quite challenging for a candidate who is preparing for a PMP certification. This article discusses the details of the PMP® exam, giving an insight into the prerequisites, layout of the exam and some tips on how to ace the exam the first time.PMP® Examination FormatThe PMP® examination contains a total of 200 multiple-choice questions. Out of these 200 questions, 25 questions are ‘unscored questions’, that is, they do not affect the exam score. These questions act as an effective and admissible way to test the validity of future examination questions. The questions are placed and are asked randomly throughout the examination. It is very important to keep in mind that the unscored questions cannot be distinguished from the scored questions. Hence it is important that all the questions are answered with the same level of precision.No. of Scored QuestionsNo. of Unscored QuestionsTotal number of Questions17525200The standard method of PMI  examination is Center-based Testing (CBT). While paper-based Testing is also available, but only under limited circumstances.The allotted time duration for completion of the exam is 4 hours. There aren’t any scheduled breaks during the examination, though a small break can be taken if needed. If any break is taken during the exam, the exam clock time does not stop but continues to count down.Before you begin taking the exam, you will be shown a tutorial explaining the process of the exam. It’s recommended to go through this video that takes around 15 minutes. Further, your PMP® exam will be followed by a survey. The time for both excludes the four hours of the examination during which you need to answer 200 questions.Allotted time for the Examination4 hoursNew PBT Policy effective from 1 July 2017The Paper-based testing for the PMP® examination is available under limited circumstances. The instances are listed as follows:Distance to a Prometric CBT (Centre-based testing)  site exceeds 240 km (150 miles)A Prometric CBT site isn’t available in the country of residence and travelling across borders is prohibited/burdensome.As of 01 July 2017, the price for PBT exam has been changed, which now equals the CBT prices.NOTE: It should be indicated during the certification payment process if the candidate will be opting for a centre-based or a paper-based examination. In the case of PBT examination, the site location, date and group testing number on the application should be included as well.How are the PMP® examination questions developed?The questions which are asked in the PMP® examination are:Developed in accordance with the standards of  IOC/IEC 17024Developed and are validated independently by global work groups of PMP® certification holders.Monitored via psychometric analysisAccording to the specifications made in the PMP® Examination Content Outline.Referenced to the present project management titles, which include but not limited to PMI ’s global standards.Are any language aids provided for the PMP® examination?PMI  examinations are administered in English. However, for the questions and answers of the PMP® examinations, language aids are provided with no additional costs.Language Aids are available in 14 languages, which are stated as follows:ArabicHebrewBrazilian PortugueseItalianChinese (Simplified)Chinese (Traditional)JapaneseKoreanFrenchRussianGermanSpanishPolishTurkishThe language aids are provided when the examination is being administered. They are protected under the PMI  Test Security and Confidentiality rules.NOTE: If a language aid is required, it should be indicated as a part of the payment process, that is, while submitting the application online; or as a part of the application process, if a paper application is being submitted.The post-exam survey and pre-exam tutorial are administered only in the English language. The language aid is provided only for the PMP® examination questions and answers.What is the Blueprint of the PMP® Examination?The PMP® examination blueprint, which is depicted in the table below defines the proportion of questions which are asked from each domain. These percentages determine the number of questions that will appear in the examination, covering all the domains and process groups of the project management. The following is the blueprint:Blueprint of the PMP® ExamDomainPercentage of QuestionsInitiation13%Planning24%Execution31%Monitoring and Controlling25%Closing7%TOTAL100%Further, let’s discuss the domains, tasks, knowledge and skill statements which are defined by the Role Delineation Study. There are multiple tasks under each domain which are measured through the process of PMP® certification.Domain I, Initiating - 13%Task 1: Carry out a project assessment based on the available information, meetings with stakeholders, and the lessons which are learned from the previous projects.Task 2: Figure out the key deliverables to direct the achievement of project goals and manage customer expectations based on the business requirements.Task 3: Use appropriate tools and techniques to perform stakeholder analysis so that expectations can be aligned and support can be gained for the project.Task 4: Recognise high-level risks, constraints, and assumptions based on the historical data, current environment, organisational factors, and expert judgement, so that an implementation strategy can be proposed.Task 5: Engage in the process of development of project charter by compiling and analyzing the gathered information so that it is ensured that the project stakeholders agree on its elements.Task 6: Acquire the project charter approval from the sponsor, so that the authority assigned to the project manager can be assigned, while at the same time commitment and acceptance can be gained.Task 7: Perform benefit analysis with relevant stakeholders so that the project alignment with organizational strategy can be validated.Task 8: Ensure that there is a common understanding of the key deliverables, milestones, as well as their roles and responsibilities by informing the stakeholders of the approved project charter.Knowledge and SkillsAnalytical skillsBenefit analysis techniquesElements of a project charterEstimation tools and techniquesStrategic managementDomain II, Planning - 24%Task 1: Based on the project charter and lessons learned, review and assess the project requirements, constraints and assumptions with the stakeholders.Task 2: Based on the approved project scope and using scope management techniques, develop scope management so that the scope of the project can be defined, maintained and managed.Task 3: Based on the project scope, resources, schedule, approved project charter, and other information, plan the cost management using estimating techniques so that the project costs can be managed.Task 4: Based on the approved project deliverables and milestones, scope, and resource management plans, develop the project schedule so that a scheduled completion of the project can be managed.Task 5: Come up with a Project Resource Management plan where the roles and responsibilities of the project team members can be defined so that a project organizational structure can be created and guidance can be formed regarding how resources will be managed and assigned.Task 6: Work on a communication management plan which will be based on the project organizational structure and stakeholder requirements, so that the flow of project information can be defined and managed.Task 7: Based on the project scope, budget, and schedule, create a procurement management plan. This ensures that the required project resources will be available.Task 8: To prevent the occurrence of defects while at the same time control the cost of quality, come up with a quality management plan to define the quality standards for the project and its products which will be based on the project scope, risks, and requirements.Task 9: Work on change management so that the changes can be managed and tracked.Task 10: Develop a risk management plan. Identify, analyse and prioritize the project risk; create a risk register, and define risk response strategy to do so. This way, the uncertainty and opportunity throughout the project life cycle can be managed.Task 11: Present the project management plan to the relevant stakeholders in accordance with the applicable policies and procedures, so the approval to proceed with the project execution can be attained.Task 12: Conduct kick-off meeting, communicate the start of the project, and other relevant information to engage stakeholders and gain commitment.Task 13: Develop a stakeholder management plan after analyzing the needs and potential impact so that the stakeholders’ expectations can be managed and can be engaged in project decisions.Knowledge and SkillsChange management planningCommunications planningEstimation tools and techniquesLean and efficiency principlesQuality management planningRegulatory and environmental impacts assessment planningScope deconstruction (e.g., WBS, Scope backlog) tools and techniquesStakeholder management planningWorkflow diagramming techniquesCost management planning, including project budgeting tools and techniquesContract types and selection criteriaHuman resource planningProcurement planningRequirements gathering techniquesRisk management planningScope management planningTime management planning, including scheduling tools and techniquesDOMAIN III, Executing - 31%Task 1: Follow the human resource and procurement management plans by obtaining and managing the project resources so that the project requirements can be met.Task 2: Lean and develop the project team to manage the task execution based on the project management plan so that the project deliverables can be achieved.Task 3: Use appropriate tools and techniques to implement a quality management plan. This is done to ensure that the work is being performed as per the required quality standards.Task 4: Follow the change management plan to implement the approved changes and corrective actions so that the project requirements can be met.Task 5: Follow the risk management plan to implement the approved actions so that the impact of risks can be minimized while at the same time, the advantage of opportunities on the project can be attained. ‘Task 6: Follow the communication plan and manage the flow of information so that the stakeholders are kept engaged and informed.Task 7: Follow the stakeholder management plan to maintain the stakeholder relationship so that continued support can be received and expectations can be managed.Knowledge and SkillsContinuous improvement processesElements of a statement of workProject budgeting tools and techniquesVendor management techniquesContract management techniquesInterdependencies among project elementsQuality standard toolsDomain IV, Monitoring and Controlling - 25%Task 1: Use appropriate tools and techniques to measure the project performance so that any variance and corrective actions can be identified and quantified.Task 2: Follow the change in the management plan and manage changes to the project so that the project goal remains aligned with the business needs.Task 3: Use appropriate tools and techniques to meet project requirements and business needs in order to verify that the project deliverables conform to the quality standards which has been established in the quality management plan.Task 4: Monitor and assess the risk to determine if exposure has changed and evaluated the effectiveness of response strategies so that the impact of risks and opportunities on the project can be managed.Task 5: Review and update the issue log as well as determine corrective measures by using appropriate tools and techniques so that the impact on the project can be minimized.Task 6: Use lessons learned management techniques to capture, analyze, and manage the lessons learned so that continuous improvement can be attained.Task 7: According to the procurement plan, monitor the procurement activities so that the compliance with project activities can be verified.Knowledge and SkillsPerformance measurement and tracking techniquesProject control limitsProject monitoring tools and techniquesQuality measurement toolsRisk response techniquesProcess analysis techniquesProject finance principlesProject quality best practices and standardsRisk identification and analysis techniquesQuality validation and verification techniquesDomain V, Closing - 7%Task I: Collect the final acceptance of the project deliverables from the relevant stakeholders as confirmation that the project scope and deliverables were achieved.Task II: According to the project plan, transfer the ownership of deliverables to the assigned stakeholders so that the project closure can be facilitated.Task III: Obtain financial, legal and administrative closure via the accepted practices and policies so that a formal closure of the project can be attained and a transfer of liability can be ensured.Task IV: According to the communications management plan, prepare and share the final project report so that the project performance can be documented and conveyed as well as project evaluation can be assisted.Task V: Collect and combine the lessons that were learned throughout the project and conduct a project review so that the organization’s knowledge base can be updated.Task VI: Archive the materials and project documents by making use of the generally accepted practices so that statutory requirements can be complied with and for potential use in future projects and audits.Task VII: Use appropriate tools and techniques to get feedback from relevant stakeholders so that their satisfaction can be evaluated.Knowledge and SkillsArchiving practices and statutesContract closure requirementsFeedback techniquesProject review techniquesActive listeningBenefits realizationBusiness acumenCoaching, mentoring, training, and motivational techniquesConfiguration managementCustomer satisfaction metricsDecision makingDiversity and cultural sensitivityExpert judgment techniqueGenerational sensitivity and diversityInterpersonal skillsLeadership tools, techniques, and skillsMeeting management techniquesOrganizational and operational awarenessPresentation tools and techniquesProblem-solving tools and techniquesQuality assurance and control techniquesRisk assessment techniquesStakeholder management techniquesVirtual/remote team managementCompliance (statute/organization)Close-out proceduresPerformance measurement techniquesTransition planning techniqueApplicable laws and regulationsBrainstorming techniquesChange management techniquesCommunication channels, tools, techniques, and methodsConflict resolutionData gathering techniquesDelegation techniquesEmotional intelligenceFacilitationInformation management tools, techniques, and methodsKnowledge managementLessons learned management techniquesNegotiating and influencing techniques and skillsPeer-review processesPrioritization/time managementProject finance principlesRelationship managementSituational awarenessTeam-building techniquesTips for passing and preparing for PMP® ExamPMP® exam requires a lot of dedication and efforts in order to clear it at one go. The following tips will surely help you to prepare and pass your PMP® exam:Memorise all formulas to easily answer the math questions.Spend around 4 hours to practice full sample exams at one sitting.On the day of your exam, use your time effectively to answer 200 questions within 4 hours. You will have 1 minute to answer each question.Answer all questions, do not leave any question blank.Use the process of elimination for obviously incorrect answer options to maximise probability in case you are not sure about the correct answer.Avoid spending too much time on any single question. If you are spending more than 2 minutes on a single question then you can make your best guess for the answer and mark it for review at the end of the exam.Try to reserve the last 10 minutes to review the marked questions.Read all the answer options before selecting an answer.Keep in mind that some questions may provide hints to other questions in the exam.Wear comfortable cloth and footwear on the day of your exam.To wrap it up!The PMP® certification acts as a validation of a professional’s experience in project management and is a challenging process as well. Start preparing well for the five domains (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) in advance so that you can ace the examination and get nearer to achieving your dream career. All the best!
10165
The PMP® Exam Blueprint For 2019

Preparing for your PMP® exam might seem like a st... Read More

A Comprehensive Guide to PMP® Exam Preparation

Are you still trying to figure out a way to start preparing for your PMP® Exam? Fret not! This blog will guide you with some best practices that you should adopt while preparing for your PMP® exam. This will surely help you to successfully clear your PMP® certification exam.Every PMP certification aspirant differs from one another in terms of experience and expertise. Similarly, every person has got a unique learning habit. Therefore, you should get your own study plan which is based on your personal learning likes and needs. But this doesn’t mean that you should get worried about developing the study plan as you can find a plethora of resources to cater the needs of exam candidates, both online and offline which allows you to come up with a plan which fits your specific needs, style of learning, and individual circumstances.6 best practices for your PMP® Exam preparationUsually, most of the successful PMP® candidates spend long hours preparing for their PMP® certification exam. So, you should make sure that you have plenty of time to prepare for your PMP® exam. You can adopt the following best practices to prepare for your PMP® certification exam:1.Review the PMP® Examination Content OutlinePMP® Examination content outline is an important document which will help you to do well with your PMP® exam. You should go through this document which is published by PMI® to find the following information:Break up of questions as per the Process areasList of skills, tasks, and knowledge which are required as per PMI’s Role Delineation study.Going through this credible document will give you a high-level idea of what all get covered in the PMP® exam. You should go through this once you feel that you have attained a reasonable command on the content covered by PMBOK® Guide or any other study guide which you are referring in order to ensure that you avoid any unwanted surprises while appearing for your PMP® certification exam.2.Take up a formal study course offered by any accredited Registered Education Provider (R.E.P)Project Management Institute (PMI) has approved a few organisations to offer project management training in order to establish a global network of quality education providers to help all the Project Management Professional (PMP®) credential aspirants and credential holders.Enrolling yourself in a PMP® training course is one of the best ways to prepare for your certification exam. The reasons are as follows:These courses provide tailor-made PMP study materials and best practices for the PMP exam.They give you a quick start in getting a grasp of various project management concepts, formulae, terminology, and other key inputs which help you to prepare for your PMP exam.You can also get the 35 contact hours certificate by taking up these training courses which is necessary for you to be eligible for the PMP® exam.3.Come up with a study planYou should start treating your PMP® certification as a project and prepare a plan which covers all the activities that would help you to get PMP® certified. But the core element in this plan is to have a well-defined study plan. You should break your study sessions into smaller chunks and prepare a study plan which includes timelines to read PMBOK®, practice mock tests, study various materials etc.4.Review the latest edition of PMBOK® Guide and self-study books published by other reputable training organisationsNo matter whatever reference material you want to study in order to prepare for your PMP® certification exam, the PMPBOK® Guide is the recommended study material for all the PMP® aspirants. The page number 61 of the guide contains a table that shows the relation between 13 Knowledge Areas and 5 Process Groups with 47 processes. It further explains how these are applicable to project management.As a candidate, you should be thorough with this table and draw this table on a piece of paper in 5 minutes while appearing for your exam. The same can be used as a reference in answering the 200 exam questions. Other than the PMBOK® Guide, you can also review other study guides published by R.E.P.s and other reputable training organisations.5.Get ready for your exam by practicing Mock TestsDo you want to check the status of your PMP® certification exam preparation? You can do that by taking PMP mock tests. These can help you to map the gaps in your project management knowledge. You can take a test and review the results to find the areas that you need to work on.Focusing on answering the questions by sitting at a place for four hours is not a piece of cake. Taking full-length mock tests helps you to prepare for such a physically daunting and mentally straining process. However, it is a very important drill for your PMP® certification exam. So, it’s better to take up these mock tests and prepare well for your big day.6.Study groupStudying in a group can prove to be quite helpful while you are preparing for your PMP® certification exam. Catch up with the like-minded PMP® aspirants to know about new tactics and get benefited in other ways by being a part of the study group. Few of the benefits are as follows:Studying in a group is the best escape from the monotony of studying alone.You can surely overcome the areas which you are struggling with.Helping others will also boost your confidence.Sharing project management experiences with others help you to crack the scenario based questions which is the trickiest part of the PMP® certification exam.It further helps you to stay on course and helps you to motivate each other in the group.The biggest advantage of studying in a group is that it forces you to study on a regular basis and makes the preparation activity a part of your routine.Tips and tricks to prepare for your PMP® examYou need to study numerous materials in order to crack your PMP® certification exam. But do you have access to the right books and materials? Every person has his or her own way of learning. The following ways will surely help you to become efficient in your study and get equipped with all the knowledge that you need to crack your PMP® exam:If you have access to the workshops conducted by PMI then that would be a big benefit for you. This will also help you to receive the bundle of 35 credit hours which are necessary to qualify for your PMP® application procedure. Attending a PMP® boot camp gives you access to numerous benefits. Few of them are:1.Review everything which you need to cover on the examEverybody is oblivious about what he or she is going to encounter during the PMP® certification exam. Whatever you will find in the exam is sure to be geared from the PMBOK®. This means you should be thorough with the PMBOK® guidelines to get PMP® certified at one go. But the PMBOK® consists of only 75% of what you will see in the exam. What about the rest? You need to seek for a PMP instructor’s guidance in order to fill the gap in learning to qualify your PMP® certification exam.2.Review how to study for the examAs discussed, the PMBOK® guide is a great resource for your PMP® certification exam. At times, even if the questions are lengthy with a situational circumstance, you need to bring it down to a rule that needs to be comprehended. Further, there are certain focus areas on which you need to invest more of your study time than others. It is always better to seek guidance from a professional rather than guessing what you should study.3.Informal questionsIf you lack the idea of how to implement cost, schedule, or risk structure, then it’s a great opportunity for you to understand it. You should learn to shed light on practical application using fundamental examples.You should change your study methods to prepare well for a continuously evolving exam process like the Project Management Professional (PMP)® exam. These days, this exam is based on PMBOK® Guide 6th edition and is a lot harder than it was in the past. The 4 partially correct choices which are provided for all the questions make it even confusing and raise the level of complication for the candidate.The following tricks are surely going to help you in shaping up your exam:Get aligned with the exam dynamics by spending 30 minutes every day on a free exam simulator.Follow the rule of 85%. Keep practicing mock exams until you score at least 85% in all the model exams. This indicates that you are ready to face the PMP® certification exam.Another important trick is to understand the ‘ITTO TRICK Sheet of 49 processes’ which you can find in the PMBOK® guide. This will really prove helpful to you in mapping all the processes inputs, outputs, tools, and techniques.In order to rightly utilize the 12 minutes after the exam, you need to read and memorize the Formula Trick Sheet. You need to print and paste the same on your desk in order to practice it every day because writing this after 4 hours exam will surely help you to track the questions and save significant time.You need to read and memorize the PMPBOK® 6th Edition 49 Process Chart. Print and paste the same on your desk and practice it every day until you can draw the chart within 8 minutes.To wrap it upWhen you begin with your preparation for PMP® certification, you should remember that attaining the PMP® certification shows your commitment to the profession of project management and demonstrates your credibility to earn more as well as raising the value of your resume above the non-certified professionals. Keeping these points in mind will surely help you to avoid getting discouraged during your certification process.You can also learn more about PMP® certification hereThis blog throws light on a few best practices along with some tips and tricks to smoothly proceed with your PMP® journey. It is important for you to set a standard time for your studies other than having a thorough understanding of the PMBOK® guide. So, start clearing your calendar to fit in your daily study time as PMP® needs a lot of thorough studies and is not an easy path to success.
9365
A Comprehensive Guide to PMP® Exam Preparation

Are you still trying to figure out a way to start ... Read More

Useful links