The fate of Sisyphus is one of the most famous punishments in Greek mythology. You may have heard this story, but here is a quick rundown.
Sisyphus was famous for his trickery and had many escapades deceiving the gods, including cheating death, not once but twice. He was ultimately punished by Zeus to eternally roll a boulder up a hill in the depths of Hades.
He had to push this boulder uphill, and as he was about to send it toppling over the crest of the hill, the rock would come rolling back down. He would then have to start the push all over again. Sisyphus was doomed to continue this task for eternity, an endless punishment in futility. This punishment is so iconic that laborious and futile tasks are known as Sisyphean.
Imagine you are Sisyphus, and the boulder is your project. Does this story feel familiar? As soon as you are nearing the end of the project, i.e. pushing the project over the finish line, another requirement comes to light, and the end seems farther away.
In the last edition of this newsletter, I described how incorrectly classifying an operational or otherwise non-project activity as a project leads to never-ending projects. However, the project is initiated correctly and signed off in this scenario. But it is still stuck in a never-ending loop.
Your project might be plagued by a phenomenon called scope creep.
What is scope creep?
A project's scope defines the work the project team will complete to meet the project objectives and starts getting specified during the project initiation phase. The scope acts as a guardrail for your project and establishes the goals, deadlines, and deliverables the team is working toward. As you progress from initiation to the planning stages of the project lifecycle, it is essential to explicitly describe what work is within and out of scope for the project.
Scope creep occurs when the project's scope increases as the project progresses. Deliverables initially out of the scope or unplanned are continuously added to the project scope during the project lifecycle.
For example, a project to deploy the wifi in an office building might have the mounting of the wireless access points and the cabling from the nearest ethernet point on each building floor to the access point as its deliverables. The scope also specifies that this work will be completed in 1 month with a budget of $40,000. At the start, mounting, installation, and minimal cabling are within scope. Any other activity is outside the scope of the project.
In this example, scope creep occurs when cabling from the server room to each floor is added to the scope after the project has started. Then, a request to install the equipment racks for routers and switches for the Internet connection. After a few weeks, the project team is asked to install additional access points around the premises to provide wifi coverage at the car park and garden areas.
This additional scope extends the project timeline to 3 months, and then to 6 months and maybe even further.
What causes scope creep, and how can we avoid it?
Unless you intend to end up like Sisyphus, continuously rolling your project boulder towards the finish line and having it come crashing back down, you probably want to avoid scope creep in your project.
Here are two of the top reasons you have project scope creep and what you can do about it
Cause: Unclear or undefined project scope
Not defining the project scope and making this clear to stakeholders is a prominent reason projects are plagued with scope creep. If stakeholders don't have a common understanding of the planned goals of the project, they will make requests based on their assumptions of the scope. To these stakeholders, the requested deliverables have always been in the project's scope.
Solution: Specify the project's scope early in the project lifecycle and ensure this scope is communicated to all stakeholders. The scope should be documented in the project charter and the scope statement if you have one. This scope should be repeatedly communicated as much as possible, and the project activities should be compared to the existing scope to ensure they are based on agreed objectives.
Cause: Lack of a transparent change management process
There are valid reasons you might need to adjust the scope of a project. However, if the project team and stakeholders can arbitrarily modify the scope, they will take advantage of this.
Solution: A formal change review and acceptance process should be adopted for your projects. With this process, the project manager or stakeholders understand that every scope addition needs to be reviewed by the change board and then communicated. This process will also highlight any additional resources that need to be provided to accommodate the change and a review of the impact on the schedule or budget. All stakeholders should also be informed of the change in scope as part of this process.
At the end of the day, scope creep might not be as dire as rolling a boulder in Hades, but it's unpleasant to deal with. With the proper scope definition in place and a plan to handle change in scope, you can avoid being Sisyphus.
Reach out
Do you have any questions or feedback, please email me at info@theconsole.tech
Also share if you know someone who might find this helpful.