I have written here before about process creep. This happens when equipment is designed to a specific process condition, but over time, small changes are made to those process conditions. This becomes a problem when the original equipment is no longer suitable for the application. Scope creep is quite similar and IIoT efforts often fall victim to it. What started out as a clearly defined effort becomes subject to additional scope. Similar to process creep, the changes are all small, but over time, lead to a problem. Here is what you can do to avoid it.

It’s Not What You Know, but How Good You are at It

At one time we owned a house that was built in 1930. Some of the electrical system had been updated, but for the most part, it still had the original knob and tube wiring. Over several years, I updated the system to include a larger breaker panel and added circuits for every room in the house. As the project progressed, what started as a simple project, became unruly. At one point, my wife stated that I needed to stop putting holes in the wall. More outlets is better, right? What should have taken a few weeks, took a few months. I fell victim to scope creep.

Why Does This Keep Happening?

Technology efforts, like adding manufacturing intelligence, seem to fall victim to scope creep on a consistent basis. I have often said the biggest challenge to technology projects are the clipboard (this is how we have always done it) or the memory of the last technology effort (a lot of money was spent and return was not realized). This is largely due to the the fact that the project was too large in scope (keep in simple) or what started our as a manageable effort grew to enormous size. One of the most common fallacies in project management is that of sunk cost: we have already invested so much, it would be a failure to stop now.

How to Avoid It

As with many projects, it is important to identify who the key stakeholders are. On the client side it should include people from technical, commercial and operational areas. From the supplier side, commercial, technical and manager roles should be identified. Moreover, roles should be assigned and clearly understood so that everyone agrees who is doing what.

While this should be well defined from the the onset, the objective of an effort should be clearly defined in a statement of work or other project deliverable document. This will be the basis for the technical and functional performance of the effort. The SOW will be the starting point for all project execution and implementation.

If the effort involves multiple phases, the milestones need to be clearly defined. What is the milestone? How is it measured? What are the activities that occur when the milestone is reached? Who is involved in deciding the milestone has been reached? Having clear answers to these questions will allow the project to continue to the next phase.

Project Charter to the Rescue

As the project progresses, any changes with the stakeholders, deliverable or milestones, should be considered a scope change. But the change does not have to derail the project. A great way to capture all of the above is through the use of a project charter. It documents stakeholder, scope and milestones, as well as how changes are made. If an issue is identified, the work should stop and stakeholders should discuss it and how that impacts the project (both commercially and technically). These changes should be noted in the charter. The project will only continue when all stakeholders are in agreement with the changes.

Avoiding scope creep is not difficult to do. What used to be the common pitfall of technology efforts can be simply mitigated through the use of a project charter. And this helps your continue to resolved your manufacturing inefficiencies.

Tagged with:
 

Leave a Reply

%d bloggers like this:
Bitnami