One of the most prevalent themes in any AV/IT industry discussion is the continually increasing globalization of the sourcing for product development and most specifically software.
No longer is the underlying code for the majority of AV products written by the brand on the front panel. In fact, more often than not, that software is developed, written and created by an invisible OEM provider, who can be, and often is, located far away from the home base of the brand.
One of the most prolific sources for this kind of development is India, which according to the most recent data analysis from various global business journals is responsible for more than 50 percent of the $180-billion plus globally based software sourcing industry’s revenue. The four major Indian hubs are:
- Bangalore – The Silicon Valley of India
- Hyderabad – Cyberabad.
- Chennai – (hub for IT Infrastructures)
- Mumbai – (The Financial Capital)
They have rapidly become the leading sourcing destinations across the world, with a market share approaching 55 percent based on the 2017-2018 data. To service this incredible growth, Indian IT companies have set up over 1,000 global delivery centers in about 80 countries across the world.
It’s important to look at the perspective of leaders from the Indian IT world, because they see things from a unique and often different perspective than their western counterparts given their unique role in the global supply chain matrix.
By following analytical content, blogs and other sources from the Indian industry, one can garner a valuable viewpoint and perhaps get a better picture our true globe-spanning industry as a whole especially since India is also gaining prominence in terms of intellectual capital with numerous innovation centers springing up.
In that regard, Abhinav Chauhan, who works at app development company Tilicho Labs commented on a topic of considerable significance to the whole AV/IT business in a blog post from May 2018.
His focus was a topic that should be familiar to any AV/IT integrator — scope creep.
From his perspective, he defined scope creep as “the process by which a project grows beyond its originally anticipated size,” as shown in the graphic below from that same post.
In other words, his point was that we think we have finalized a project’s definition with a client and we get to work, but insidiously, and often deep in the background, over time, the project gets bigger and bigger, while the pay stays the same.
Why this matters is very simple — the costs associated with this ‘expansion’ drop directly to the bottom line and it’s a net profit killer.
Many Names, One Result
Scope creep has many identities. It is often referred to as feature creep (in product or system functionality terms), focus creep (in project scope of work terms) or creeping functionality (in user needs statements). Another popular catchphrase for this problem is a kitchen-sink syndrome, but no matter what you choose to call it, scope creep can sneak up, morph and destroy a project from within before anyone realizes what has happened.
Stopping the Slide
ANY project can become subject to the effects of scope creep, and the larger the initial scope or the longer the timeline becomes, the more likely it is to occur. It’s not something you can deal with after it has taken hold, but it is something that must be caught BEFORE it has any substantial or irreversible impact on either cost or design parameters.
Its Brand New But Do You Really Need It?
One of the most prevalent causes of scope creep is the appearance of or introduction of new technology or an improved version of some device, hardware or software mid-way through a project. All of a sudden the client sees a new and purportedly “better” version of whatever is in the current spec or project scope.
The natural assumption is that the latest iteration MUST be the improved answer to whatever the original question was, but is that really the case? This is where your expertise and careful and thorough research into the differences and changes between the current product and the ‘new and improved’ version must be carried out in considerable detail.
Certainly, this can be both resource consuming and tedious, but if it either avoids a major scope creep problem or actually provides a better solution, then the time is well spent. If it becomes apparent that the ‘new’ item will not bring anything to the project that is not already in place, you must be prepared to present a well-reasoned defense and analysis of why this is the case and stop the potential costly scope creep in its infancy.
Remember the new shiny toy has great attraction, especially if it has been deployed by a competitor to your client. However, that is not a sufficient reason to make the change and incur the associated costs (and there WILL BE costs) unless there is a provable ROI from the change.
The rapid cycle times now occurring with product development and introduction can easily and quickly create major opportunities for scope creep. If you do not stay up to date on what is available vs. what you originally specified when the projects’ scope was finalized you can rapidly drift deeper and deeper into the quicksand of endless revisions and changes, most of which the customer will not be expecting to pay for. After all, you are supposed to be the expert so why didn’t you know of the upcoming ‘improvement’ and plan for it. It becomes your problem whether or not it actually is.
If your vendors don’t make a point to keep you in the loop on upcoming developments or new product introductions, make a concerted effort to encourage them to do so. If that fails it may be time to look for another supplier relationship. They are not going to defray any costs you incur so if they won’t keep you up to date find someone who will. But remember this is a two-way street- you have to put out the time and effort to stay up to date not just wait for the supplier to fill you in. Things move too quickly in the current AV/IT product space to allow complacency in this area.
In the End
Scope creep is sometimes viewed as inevitable on any project, but the reality is a that it only happens when you don’t put into place warning flags and contract language that allow it. Assume it is just waiting to happen and plan for it, or plan for a negative profit impact if scope creep becomes part of the project.