A major source of trouble with changes is typically that the project manager, in attempts to avoid bureaucracy, adopts an informal process of handling requests for change. Such leads to misunderstanding on the part of the party requesting the change, and before the project manager can undo the damage; the organization is committee to extending the scope of the project but without the additional resources and time to do it (Portny et al., 2008).
I recall a project where my organization set out to create electronic documents to help minimize the use of paper and to streamline some of our internal processes. Doing so would eliminate the time it took for documents to be completed by eliminating the use of mail and having a central repository for all completed documents so that items wouldn’t be lost. This was the original scope of the project. This began as an initiative just for one department. As the project went on and more departments heard about it, the list of forms to be created electronically grew exponentially. In addition to that, people started requesting that documents be created to use for external customers. This expanded scope created a number of issues. There was no change control process created so anyone on the project team was just creating documents with no guidelines. The documents were being generated for use outside the company without being reviewed and cleared by our legal group to ensure no unnecessary liabilities were being created. Lastly, there weren’t enough people resources on the team to keep up with the demand of requested forms that needed to be created.
I recommended that we scale back the scope and focus on one pilot department and a small list of forms. This would allow the group to handle the load and work out any identified issues prior to getting any other departments involved. The rest of the stakeholders weighed the benefits of this versus the disadvantages and decided that was the best course of action to take. Looking back on the situation, if I had been the project manager, I would have clearly defined the scope and all of the initial components of the project. This way all of the stakeholders would have clear and realistic expectations of what was to come and could anticipate some of the next steps. In this pilot it would have been best to outline a plan based on the results to implement the electronic form process in the other departments and allow for a more efficient transition that most, if not all, stakeholders could be satisfied with to meet their goals.
Sometimes projects can get off track very quickly because of poor communications between all of the parties involved, lack of proper identification of what is needed to achieve the groups objectives or even poor project management overall. This can lead to increased costs and failure of the project. However, if other aspects are considered as the scope of the project changes such as budget, other resources and the timeline or schedule of the project, scope creep should not occur.
Avoiding scope creep in not possible; however, monitoring it, controlling it, and thereby reducing some of the pain is possible-if the project manager follows a few guidelines... (Portny et al., 2008)