No two software development efforts are the same. We live in a world where…

• The cell phone, computer, iPad and TV purchased today are obsolete shortly after you walk out the door. 
• The marketing campaign that worked yesterday falls flat today.
• The brick and mortar stores of yesterday are no match for the online storefronts that savvy entrepreneurs have up and running (Google Fiber as just one example). 

Change is the rule in the 21^st century and software is certainly not exempt because every software development effort involves businesses, people, and technology.

-Businesses live in an ever-changing, ever-evolving landscape of both their market and the vendors that they partner with.

-People rarely work for organizations for 20+ years and instead change jobs and industries much more frequently than at any time in history.

-Technology is the largest culprit in this ecosystem of change we find ourselves immersed in today. It moves at a pace that even the most techologically savvy people have a hard time keeping up with.

None of these pieces to a custom software development effort are easy to nail down. Those of us in the Information Technology world have been attempting to minimize this problem for as long as we can remember.

So how is change traditionally dealth with? Below is how it currently works with most software development companies. In a future blog post, we will address SilverFern's recommended solution…."Embracing Change."

Modern Day Traditional Approach (That Doesn't Work!) – "Making Change Difficult"

A logical conclusion to the fact that change occurs is to put processes around software development efforts that mitigate change (which is a nice way of saying “Let’s make change difficult.”) 

While that may make sense on the surface, we would argue that many haven’t thought deeply enough about this issue to come up with a truly logical conclusion. It's the "it is what it is" approach vs. "why is it this way and is there a better way to do it?" approach.

A process-heavy approach involves gathering detailed requirements upfront followed by building, testing, and deploying the software. The honest truth about this approach is that it doesn't make much sense in today's software development world. You can muddy up a project by being TOO process-heavy or bureaucratic. The focus turns away from "what makes sense here" to "this is what the process is and we can't deviate from it".

Gather detailed requirements upfront

There are many goals in the requirements phase of the Software Development Lifecysle (SDLC). A simplified goal might be stated as making sure developers know what they are building and the business knows what it is going to get.

The unfortunate aspect of this phase is simply the overwhelming nature of the task. In methodologies like this, requirements gathering may easily take up to half of the overall scope and budget as it is where most of the work is done. For a company waiting for a piece of software to improve its business, that delayed delivery may be a heavy burden to bear.

Not only that, if we KNOW things change, writing specs for requirements that are going to change is a waste of both time and money which leaves only inefficient bureaucracies with huge budgets and little sense as the only logical customers left. This phase also involves the following:

Include everything the software will need to do now and in the future

This is probably the most challenging aspect of software development using this methodology.  It challenges the business to know what the future may hold which if the truth is we live in a culture of change, may be a next to impossible task.

Carefully document and spec out those requirements

Many times this documentation is used to pass down to the IT staff so they have a clear understanding of how and what to build for the client.  Now it may be a surprise to some of you but developers tend to have a somewhat limited ability to communicate outside of their own species.  We know because we have worked around them our entire careers. With an approach favoring documentation over human interaction, misunderstandings are typically difficult to head off.

Get approval and sign-offs from all key stakeholders

The purpose of this is for the protection of both the client and the software provider. While its goal is to actually assist with the client-vendor relationship as everyone should be on the same page, it has been our experience that it tends to lead to an antagonistic relationship instead.  It leads each partner in the relationship to point back to sign-offs and approvals as ammunition in a disagreement.

Begin build out of software

The least important aspect of this particular process – need I say more.

Not enough of a reason to vilify this process you say?  Then let's think through their typical heavy change control process.

• Change is found to be necessary to software
• Documented summarization of reason for modification must be submitted
• Analysis must be done and submitted by IT and stakeholders
• Sign-off by appropriate stakeholders to approve or deny the change

The primary purpose for this complex change control process is to protect the software provider from the cost overruns that occur as a result of change. The secondary purpose is to provide visibility to the customer and to make sure they know what they are doing and how it will affect the overall cost and scope.

From our perspective, this continues to be just another thorn into the relationship that exists between both parties. (For example: A software provider is building a role based security module into an application. The customer assumed this module was going to be built utilizing their existing Active Directory infrastructure already in place. Since it wasn’t called out in the approved documentation that way, the software provider may insist on a change request which equates to more cost and a scope change thereby putting the customer and vendor at odds.)

Test software

Now we have no problem with testing and would only encourage it but this one is always confusing to us. In this methodology, we have reached the end of the project and perhaps the budget, but there is a bug. What do you do? While we are glad they found the bug, now another possibility for conflict exists between the software provider and customer. Perhaps the contract will elaborate more clearly on what the correct solution is for this type of issue. But if it doesn't….watch out.

Stay tuned…"Embracing Change"

Stay tuned for Part 2 of this series titled “Embracing Change”. If you just can’t wait, you can get a sneak preview in one of Troy’s latest blog entries.