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

Remove Your Mental Block, Open Up and Think in Terms of PMBOK’s Best Practices

Excerpt from the personal blog of KnowledgeHut Faculty – Satya Narayan Dash, PMP Aswin Krishnan H is a proud PMP today. His success is not only due to sound preparation, but also handling stress during the exam. He names it as the “smile” factor, as he has told below so uniquely. Aswin was part of my class in May, 2015. He is a very lively person and participates fully. In fact, I remember few instances where his enthusiastic participation were bringing surprised looks on some faces. In my view, enthusiasm is a great quality in any team member. But, unfortunately, it is highly underrated. I believe, enthusiasm is contagious and brings many into the fold of discussion. He called me after he was certified and I asked – “How does it feel to be a PMP?” He had a sense of happiness, relief and immense satisfaction. Below, he has outlined his experience in preparing for it, going through the PMP program and finally cracking the exam. Go on and read his experience.                                                               ************************************* Introductory – Why I decided on it and how I started? I was motivated to do PMP as part of my job and wanted to understand properly the Best Practices and how to use them with confidence in day to day activities as far as possible. Three of my friends were equally interested in doing Industry standard certification and when we began our search we had PRINCE 2 and PMP in our mind. Finally, we settled down with PMP which has huge demand in any industry. We then started our search for Training provider, found that it’s the Coach and his approach that help a lot in this kind of Certification, though online and word of mouth reviews we shortlisted Knowledge Hut. One of my friend had a successful experience in securing his PMP within a month after training with the Coach Mr. Satya Narayan Dash, He was really impressed by his practical approach, knowledge and personal commitment. He has previously attended PMP trainings from various centers but never could understand the concepts clearly, and failed in the exam miserably. He came from Chennai to do the course in Bangalore, just for the Coach. My PMP Training Experience: The training was very precise and covered all Knowledge Areas from the 5 Process Groups: Initiating, Planning, Executing, Monitoring and Controlling and Closing. Satya was very kind and use to share his personal experiences with certain problems which helped to see insights of approaches and reason why or what suits best based on the PMBOK Guide. He always helped us think about all the process and why each Input is given and what is the output of each process and why it is important, often in many of the companies we don’t practically use all the process or tools but the Coach’s insight in all tools and approaches was very helpful in understanding the Input, Tools and Techniques and Output (ITTO) for each Processes. We had classes on Weekends, the coach was very punctual and kept his timelines very strict. He was very happy to help even after the classes and he would stay back for us even if it was raining just to make sure that we get the idea of what is happening or why it is happening, He use to explain ‘Change Request’ or ‘Deliverable’ Flow by drawing pictures as it goes through each processes. These insights really helped in understanding the concept and the interrelationship between each process and ITTO. In the entire class there was fun, all were active and were participating which the coach always managed to make it interactive. Lot of things we need an actual physical person to explain to us rather than just going through hours and hours of Videos. I understood that having a real person standing in front of us will build that physiological effect, which will help me learn more and get motivated easily. My Own Study: I really wanted to complete the exam within 2 months after completing the class, but due to personal commitments it got extended to 4 months. Every-day I use to spend at the least 2-3 hours reading PMBOK 5th Edition, Rita Mulchay. This really solidified my understanding that was gained in the Classroom training.  In the last one or two months I use to keep on giving Mock Tests in the early mornings (4 -7 am) and then review them after coming back from work (7 – 8 pm), I kept on giving mock test from various places and was not be very subjective in selecting the source for exam. I felt that giving these mock tests really boosted my confidence and triggered to schedule the exam. While doing the mock tests most of the times I was in panic and I didn’t read all options and selected the wrong one. Rita Mulcahy’s recommendation helped. I read the options from D to A instead of A to D. This really increased my hit percentage. My PMP Exam Experience: I became a member, filled in my application, got my references and waited for a week to get it approved; luckily it was not selected for any audit. That was half way done, second challenge was to schedule the exam. I kept on giving mock tests until I had the confidence and was hitting 75-80% in mock tests. This triggered me to schedule an exam, at this time I just wanted it to get over at the earliest; luckily I found a date that was within 10 days and scheduled the exam on that day. I had formulated this strategy of completing 70 questions in an hour so I will be done within 3 hours at the max (200 questions) this I kept on applying while taking the mock tests and this strategy was quiet successful for me. On the Test day, I was faced with a flurry of Mathematical questions (20-25) from Question No#1 with all confusing stuffs and very wordy; I was very stressed, then I remember reading somewhere that even if you are stressed and if you manage to keep a smile on your face you can beat the stress. I applied the same and was able to get over the initial surprises in the exam. There were lots of situational questions, I was confused in lots of places; I marked them and kept on moving forward without worrying about the lengthy or wordy questions and kept on answering whichever I could. Finally, by the time I was done with 200 questions, it was like 2:30 hours; so I went back and selected all the unanswered and marked ones and slowly went through each one of them, now ‘smile’ factor worked and was able to easily and clearly read the questions and answer them. I completed all left outs within 45 minutes. Now I started reviewing again from beginning and just kept on speed reading questions and selected answers just to make sure that I did them correctly. The PMP really puts a toll on you with all sorts of Mathematical, Situational, and Tricky Questions, the initial impact of the questions is really intended to create stress, if you overcome that then you would be able to score very easily. During the exam I read the answers from D to A instead of A to D, I found this to be very helpful against panic answering due to stress. Suggestions for PMP Aspirants: – Dos Please read PMBOK at the least twice, it is very helpful and answer to PMBOK and not to your personal experiences. Please take any book like Rita or Andy Crowe or Head First and complete them once before kick starting the mock tests. Please keep a smile on your face, even though you are stressed, this will help relieve stress and get back to your senses while taking test, if you are in panic answering mode read the answers from D to A than from A to D this will improve your hit rate, these helped me. Please do take 10-15 mock tests before attempting the exam, this really helped me understand where I stand and what my weakness is and helped to motivate and improve. Real life PM experience helps a lot while answering these questions during the exam. – Don’ts Don’t waste time prolonging the exam, use your time wisely and complete it at the earliest. Having too many materials won’t help as you will be confused when to complete them, don’t get overburdened. Conclusion: After earning PMP I am much relived, I can see the fruits of hard work getting paid off. Whenever you say that you are PMP, there is a peer respect, because all of them know how much committed you need to be to earn this prestigious qualification. I now see what things at work do work and what not and how they are interrelated. PMP is not just a one-time process, you can apply this leanings in each every aspect of your life which you are doing unconsciously. Finally If I CAN DO IT ANY ONE CAN. You just need to remove the mental block and open up and think more in terms with best practices put forward by PMBOK, and your personal commitment. Brief Profile:  I am Aswin Krishnan H and am a Project Manager with Hewlett-Packard, India. I have 9 years of experience in Telecom, Retail and Security Domain with .NET Platform.                                                               ******************************   Aswin’s online PMP credential is available at PMI’s online credential registry. I am thankful to Aswin for sharing his journey in achieving the PMP certification. I believe it will help you – the PMP aspirant – to have your own. This article was originally published on managementyogi.blogspot.in
Remove Your Mental Block, Open Up and Think in Ter...

Excerpt from the personal blog of KnowledgeHut Fac... Read More

Identifying Project Stakeholders in the “Project Management Professional” Way

Project Management Professional (PMP) certification is an industry recognized qualification for the Project Managers. PMP is the market indicator of experience, knowledge and enhancement of skills, which are required to lead and direct the project. PMPs are the crucial part of every organization. PMP qualified Project Managers reach the potential to handle multiple projects and turn them into tangible outputs, minimizing the various project constraints. At the onset of the project, it is important to identify the formal authority for the project, in the form of Project Charter. That means, we need to identify the Project Stakeholders. Identifying project stakeholders at the very beginning of the project is critical to project success. This process is carried out before the end-to-end planning stage of the project. It is a two stage process which is carried out when the stakeholders are not content. If a step intended to satisfy the stakeholders is actually not serving its purpose, we can call it anything but project success. The following steps are mandatory to keep a project running successfully- Identifying the stakeholders Inspecting the relationship of each stakeholder with the project to establish their level of interest in the project. Anyone and everyone can be the stakeholder. It includes the people whose business interests are impacted by the project, who can dominate or steer the project, or have more expectations from the project. A stakeholder is not necessarily a sponsor or board member. He or she can also be a team member or the project manager. Every single member associated with the project can be a stakeholder. So you can identify the stakeholders by the source of information on the Stakeholders (Input), working on that information (using the tools) and on outcome. Input:  Project Charter– It not only refers to the documents specifying the rights of the Project Manager, but also provides a list of the key Stakeholders (comprises of the Sponsor, Senior Management, or Consulting Management). Procurement Documents: In addition to Charter, the Procurement Document is a great source to the third party stakeholders falling lower in hierarchy. Enterprise Environmental Factors– EEF indicates how the rules and regulations, human resources and structure of the Organization etc. affect the project. One of the factors can be input, to identify the key stakeholders which gives us insight on who has the power to influence the project. Organizational Process Assets– OPA is the repository which keeps information about the past project, improvement from past projects, procedures, policies and standards in an assembled manner, so as to act as a reference for future projects. Tools and Techniques:  Stakeholder Analysis– It consists of analyzing the information from the input of identifying Stakeholders, which will assist us to select the stakeholder who can influence the project positively. So we can start recording the role of an individual, their point of interest, their influence level against the list of all stakeholders. You should examine the expectations and interests of all the listed stakeholders in details. This may help identify more stakeholders. In addition to that, we can handle all the stakeholders’ concern and make plans to address them. That is one good way we can convert negative stakeholders to positive ones. Once we have the relevant details, we can use those to classify the stakeholders depending on their interests, influence, support and power. We can use tools like Resistor, Neutral and Advocate to categorize Stakeholders: Resistor is a negative stakeholder who is not supporting the project. Neutral stakeholder does not support the project. In this case, the project manager tries to convert their interests positively. Advocate is a stakeholder who completely supports the project and also provides ideas to overcome the barriers if any. Output:  Stakeholder Register- All the information accumulated in stakeholder analysis helps us in creating a Stakeholder Register. A register comprises of all  the information in tabular form, whose size depends on the project size. It is the duty of the project manager to identify the potential stakeholders and note them down in the table, so as to ensure project success. Project Stakeholder Register is depicted below: Stakeholder Management Strategy– Stakeholder management strategy is formulated to plan the actions for the entire course of the project management. This strategy is made to minimize the negative influences on the project.          As per PMBOK 5th Edition, the Stakeholder management strategy document includes the following: Key Stakeholder’s impact on the project Stakeholders’ level of participation as per stakeholder analysis Groups designated to each stakeholder Assessment of Impact Potential strategy for gathering Support Collecting source of information on the stakeholder as an input, and working on that data using tools can help us in finding the positive stakeholder to enhance the level for project success.
1765
Identifying Project Stakeholders in the “Pro...

Project Management Professional (PMP) certificatio... Read More

How to make the transition from an Engineering Position to a Project Management Professional in 10 Steps?

When it comes to career advancement, getting pigeonholed could have serious repercussions. Moreover, if you have spent your last 6 to 10 years in the ranks of a technical position and thinking of attaining a managerial position, then obtaining a certificate in a Project Management Course is the way to go forward. On the other hand, you would be interested to know that only 20% of significant organizations actively operate leadership development programs and a meager 5% emphasize bringing out the managerial skills of their technical staff. The above data highlights the importance of a PMP certificate course in case you are designated as an engineer. As per an engineer who has pursued a project management certificate, his decision to pursue Project Management Professional certification was based on the fact that it helped him codify his work. Moreover, it was useful for him in future transitions. Another belief lied in the fact that it forced him to learn formalized project management strategies and techniques. Since obtaining his certificate in 2011, it has achieved the goal of solidifying his project management skills. On the other hand, it has also given him a formalized manner of viewing project management. According to him, it was well beyond the benefits of on-job training that he picked up in his engineering work.         As an engineer, it is quite probable that you would always be involved in some projects, either as team members or project leaders. The primary objective to pursue the Project Management Professional stands on two notions. The first is with the help of a PMP certificate; an engineer could codify the work and can make prosperous career transitions in the future. It would also help an engineer to learn formalized strategies related to Project Management. Here is the list of ten ways with the help of which you can facilitate your transition.  1. Enrolling yourself in a PMP Certification Course Obtaining a certificate in a PMP course is an industry standard for the aspiring managers as it depicts to the employers that you have achieved a high level of managerial education in successfully supervising a project. During the PMP course, you would come across the following learning objectives.  Conducting interviews and extracting valuable information Planning projects in a detailed manner and afterward establishing an optimal solution. Assigning and planning your resources most efficiently and cost-effectively. 2. Lay more emphasis on Emotional Intelligence (EI) You are an engineer, and you are well versed with the notion of Intelligence Quotient. In fact IQ got you where you are today. However, if you want to make a successful career transition, then EI is the best bet.   Emotional Intelligence usually encompasses your skills related to monitoring, managing and regulating the emotions in a healthy and balanced manner in a bid to achieve various business aims. In other words, as a project manager, you would have to rely 10% on your IQ and 90% on EI.  3. Improve your interpersonal skills It is a widely accepted fact that no company or organization would recognize you as a project manager if you sit at your desk all day. It is vital to develop your interaction skills with your fellow employees who would further boost your relationship with others. On the other hand, it would also profit your relationship with the senior managerial staff. Moreover, it would also assist you to convince them you are the right person for the job. 4. Emphasize on your dealing skills It is crucial for you to note that managers are required to negotiate deals on a daily basis. These dealing can encompass both minor negotiations and large contracts. However, it is also vital for you to note that the proper development of negotiation skills takes time and you can improve your negotiation skills with the help of an online course. Excellent negotiation skills would always help you to showcase your talents to the top administrators of the company.  5. Grow your determination  As a project manager, sometimes would truly test your patience. However, the best way to test the limits of your tolerance level is to stay affixed to your goals during a project. You have to keep the bigger picture in your mind while achieving the goals of Project Management. The duty of a project manager requires a thick skin to emerge victoriously. 6. Leading from the front The main aim of a Project Manager is to motivate those who are working on your instructions. On the other hand, the goal of a project is of utmost importance to you, but your workforce would have different priorities than the goal of your project. Hence, you need to gain adequate motivational skills to make sure that the purpose of your particular project gets fulfilled. 7. Always possess an attitude to learn and grow while working Besides maintaining an all-around knowledge of your organization's various departments, it is also vital on your part to have an opinion that would reap you with luxurious benefits. Standing still and learning nothing should never be your ideology while you are a manager of a project. 8. Get a mentor In case you are appointed as a Project Manager, you should always consult the professionals out there who possess the same kind of skills. Hence, make sure that you approach people with the desired skills so that he or she can guide you through the process of successfully managing a project in real industrial situations. However, the selection of a specific mentor is a personal matter. You should always be on the lookout for that kind of a mentor who can inspire, encourage, maintain high standards and interpret body language. You can also opt to attend team meetings with your mentor to make sure that you gain skills as per your mentor. 9. Emphasizing the use of project management tools Your knowledge and experience are of utmost importance to you and your organization. However, you also need to make sure that you utilize the tools that are available to project managers. To give you a crystal clear idea, some of the standard tools are Gantt Charts and Earned Value Analysis.    10. Opt for gaining experience of various stages of project management You would be well-aware of the fact that projects are usually split into multiple steps, and each one of these scenes comes with its own set of challenges. Hence, it can be said that if you are looking to progress from a technical position to a manager, you need to comprehend the importance of all these stages. You should always take care to pro-actively seek out new projects at various stages of their existence.   It is also vital to ensure on your part that you are involved in various stages of project management as your new organization would value your experience of being involved in all the steps.    11. You would be in an advantageous position if you come from a technical background If you have a technical background, then you can easily opt for the Technical project manager role. It is a situation where the technical background can be beneficial to your position. It would also be advantageous for your project and organization. 
1063
How to make the transition from an Engineering Pos...

When it comes to career advancement, getting pigeo... Read More

Useful links