Product Development engineers try to create realistic and accurate proposals to give both internal and external customers numbers for cost and schedule. And, no matter how many times they tell everyone that these are estimates, stakeholders always seem surprised when the budget and schedule change. The culprit for this drift in expense and time is almost always scope change.
As a product works its way from concept through various stages of design, testing, and then manufacturing, problems show up, new options are uncovered, and stakeholders also want to make improvements. These require changes to the product’s design, and therefore the tasks you budgeted for in your project schedule need to change.
This is scope change.
This is where those doing the product development often come in conflict with those paying for the product development. And, if handled poorly, this is where animosity and finger-pointing can grow and take over a project.
Having done product development for hundreds of clients over the past twenty-five-plus years, our team at PADT has become experts on scope change and how to deal with it. This post will define scope and scope change and how to minimize and then deal with the whole issue through specifications, planned iteration, and communication. Whether you are doing the product development yourself, working with an internal group, or outsourcing to someone like PADT, your product development project will go much smoother if you accept that scope change will happen and plan accordingly.
Scope and Scope Change Defined
Scope is one of those words people “in the industry” use without really thinking about what it means. Scope is scope. Originally, the term scope referred to a device or tool used to measure something. Over time, it also grew to refer to what was being measured, or more precisely, according to Webster’s, “Intention, object.”
Project management, according to the Project Management Institute, is “the work required to output a project’s deliverable.” These are the tasks required to obtain the goals of a project. The cost and schedule required to design a product are directly related to the scope. Each task has a cost and time associated with it.
Scope change is therefore changing some aspect of work required to output the project deliverables. The most obvious change is doing a different task. Maybe you had “test prototype at room temperature,” and now you have “test product at -20C, room temperature, and 45C.” Sometimes scope change is a change to the cost or schedule of a given task. You thought that your contract design engineer was $125 per hour, and instead, they are $135. Or, maybe you estimated that a given task would that 46 man hours, but as you understand the problem better, it takes 72 hours.
The most common type of scope change is when someone changes the product’s deliverables. The above example of testing at three temperatures instead of one is a great example. It can also be a new feature in the product, like “add a button that goes ‘bing!’ when you press it.” Stakeholders can add features to a product or change the required performance or testing. The important thing to remember is that the list of tasks, along with the cost, and schedule of each task, are determined by those defined deliverables for the project.
The Best Way to Define Scope Is Through Product Specifications
And speaking of defined deliverables, let’s talk about product specifications. This is how most product development projects document what the product needs to do. It is a list of the what, when, and how much of a product.
The what is the most important. The most common specifications are a list of things the product must do and the features the product must have. Say you are developing a hammer, then the most important specification would be to drive nails into wood manually. Features may include an ergonomic handle, weight between one and one-and-a-half pounds, and length between twelve and eighteen inches long. It can also include aesthetic requirements like color and finish as well as packaging. Or, it might control the material used, like saying that the handle has to be made out of recycled material.
The specification will also include specific testing requirements. These can be industry standards or may be defined by your company. For our hammer, it may be things like surviving a drop from twenty feet onto concrete or not rusting after being sprayed with water and left in a cool camp place for ten days. Finding out that there are industry requirements near the end of a project is a common cause of scope creep. Specifications also include cost constraints on the materials used to create the product, the manufacturing of the product, and schedule expectations on the design and manufacturing.
The important thing to do is make sure all the specifications are written down and agreed to. Everyone on a project should know that changing specification changes the tasks, cost, and schedule required to achieve the specification. That is a scope change.
Embrace Change: Don’t Be Surprised by the Cost with an Iterative Product Development Process
Seasoned product development professionals know that scope change is part of designing, testing, and manufacturing a new product. Even if every specification is nailed down and a detailed project plan is put in place, things change, and the scope changes. That is why most companies use an iterative design process.
The opposite of an iterative product development process is one where the stakeholders push the development team to cut corners. Compressed schedules and incomplete specification documents are a sure way to guarantee scope change. If anyone even thinks of saying, “we don’t have time for all this planning. Let’s just figure it out as we go,” stop the conversation and reset.
An iterative process assumes that some steps will be repeated because something went wrong, you need to make improvements, or the scope changed. It assumes the team will iterate on designs as a normal part of the process and has the potential impact of those iterations and costs built into the cost and schedule. In the long run, this usually reduces cost and time because making scope changes outside of what is expected, especially near the end of a project, takes time and money.
Managing Scope Change Through Communication
If you can’t avoid scope change or plan for it, the best thing you can do is make sure everyone is aware of it. Communication is critical to ensure that the team doing the work and the stakeholders’ impact know what is going on. And the communication needs to be two-way. The development team needs to communicate with stakeholders, especially those responsible for cost and schedule. Likewise, the stakeholders need to communicate priorities and concerns back to the development team.
It would be great if the whole product development process was a rational procedure where human emotions never got involved. But the reality is, people can get frustrated or angry, trust can erode, and animosity can grow when scope change is a surprise. Fear of disappointing co-workers or customers, or angering them, can also keep people from delivering bad news. And the best way to elicit an emotional response to a scope change is not to communicate it early and then surprise the stakeholders.
The last thing anyone needs in any project is people taking an adversarial position with each other. If stakeholders are constantly pushing back on scope change, trying to avoid it, getting emotional, or minimizing it, the development team will react negatively. Once trust is gone, and frustration enters the picture, productivity and accuracy go out the window.
The answer is simple, communicate.
Achieve Product Development Success by Minimizing and then Excepting Scope Change
Scope change is not inevitable, but it is common. Taking the time to capture all the specifications for a product up-front and making sure the project plan addresses those specifications is the easiest way to avoid scope changes. Another is to make sure you don’t take shortcuts or skip steps. And, most importantly, build iterations into your product development plan.
When scope change does happen, minimize the impact by taking the time to look at the change in detail and communicate what needs to be done and why. If everyone works together and accepts scope change as a natural part of the project’s progression, their impact on cost and schedule can be minimized.
