Scope Creep 2.0: Embarking Into The Unknown

Jonathan C Smith, Senior Industrial Designer, IDSA

Uncontrolled changes in a project’s scope can occur when the scope is not properly defined, documented or controlled.

Scope creep, as defined by Wikipedia, (also called focus creep, requirement creep, feature creep, function creep) in project management refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented or controlled. It is generally considered a negative occurrence that is to be avoided.

I, for the most part, agree with this definition. Scope creep is not generally looked upon as a positive element of the development process. But if you are developing an innovative solution, then scope creep should be factored into the timeline by both the client and the design firm. I would also suggest that both parties discuss it openly as an expected part of the process and predetermine how much leeway either party would expect to have granted to them if something unexpected does come up. By unexpected I mean a new product that enters the category your product will be entering.

As one of my managers use to say “We don’t know what we don’t know” and this statement is very true for those who work in New Product Development. Innovation and new product development require those involved to constantly assess their understanding of a project, the marketplace and new manufacturing capabilities that may be employed. New developments by competitors can have lasting affects on the market place, which may need to be factored into the product you are developing and therefore your scope. As it relates to the timeline and deliverables, you may need that little bit of flexibility which will be most effective if it is discussed prior to embarking into the unknown.

In no way do I  suggest that one use scope creep as a bargaining tool, though some do, nor do I endorse the use of scope creep as a crutch for those who are still trying to develop their design methodology. I am simply exposing the need for those involved in the NPD process to be open about the issue and discuss it as an integral part of the development cycle so that it doesn’t damage what could turn into a fruitful relationship amongst professionals.

In an ideal world the client approaches me, the design firm, with a project brief. This project brief states in some specific terms what they are expecting to receive or have delivered to them at the specified date. Some of the potential deliverables may include: Research data, conceptual ideation sketches, 3D CAD models, functional prototypes, sourcing for manufacturing, packaging concepts, etc.

Here is a hypothetical example of a project brief I would receive from a potential client:

Enviro Corp. is seeking to develop a line of home cleaning products that are environmentally friendly solutions that clean as effectively as other similar products. All proposed solutions must be independently reviewed for both effectiveness and ingredients testing. We will also need a physical packaging solution for this new product line and are interested in having you develop solutions that are visually engaging. And so on and so forth with a specified date somewhere within the brief.

I would then define a schedule which would in simple terms define the phases and key dates of the project, at which point we would review the developments and endeavors of my firm.

If I had some credibility and experience in this arena, household cleaning products: organic chemical solutions, 3D packaging development and graphic branding solutions. I would not be hard pressed to develop an accurate timeline in order to deliver upon the needs as stated in the brief. But if I weren’t, then I would perform the required research in order to have a solid understanding of the market place, from product to packaging and merchandizing.

While the research may be required, it isn’t always possible to do all of it, or to be aware of all that may factor into your development cycle, before you develop the time line that outlines the deliverables. I want to ensure that I make myself aware of what is on the cusp of the envelope and ensure myself that I am delivering the best possible solution.

I don’t want to develop “me too” products when my client is asking for new and innovative solutions. In order to do so, either they or I may need to change the timeline and even the deliverable as we are made aware of new developments outside of our control. I have worked on projects that have been shelved once a competitive product hit the market place, effectively negating two years of development. All of which came back full circle as some of the discoveries that were made lead to new products.

Scope creep can be an effective tool for the accountants and idealists in all of us. But each of us has an obligation to our clients and in turn to ourselves to develop solutions that bring innovative and highly considered products to the market place. Excellence, perseverance, determination, and communication can drive innovation and we shouldn’t let our lack of foresight into the project scope hinder our drive to push forward and develop refined solutions that are desired by consumers.

You can learn more about the author:

:: Portfolio :: www.jonathancsmith.com
:: Portfolio :: www.coroflot.com/515design
:: Linkedin :: www.linkedin.com/in/jcsmith515
:: My Blog :: www.designexposed.com