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.The best PMP certification will help you master all the principles and fundamentals of project management. 

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.

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:

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 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:

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:

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

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.

Ready to excel in project management? Our PRINCE2 Practitioner training online offers a flexible and convenient way to achieve mastery. Enroll today and take the next step in your career!

" style="height: 402px;">

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.

Top Cities where KnowledgeHut Conduct Project Management Certification Training Course Online

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.