Every technology professional knows that a well-defined set of technical goals can help you guide the project to a win. We ask ourselves: What defines a “win” for this project?
The scope of work needed to complete the project us a list of tasks that needs to be predefined, and should not be expanded throughout your project. If such an expansion is needed, you could fall into the trap of scope creep – an increasing amount of scope that could be detrimental to you on a per-project completion billing, or the Customer on per0hour billed projects. Either way, the additional scope needs to be evaluated, estimated, agreed upon, approved, and prioritized. Then, and only then, can it be added to a project.
If you are one of the professionals who is still learning to manage scope creep, please be aware of these things you can do:
- Some project resources are not authorized to change the scope of a project. Talk with your Project Manager to alert them of this situation.
- Discovering new scope is not uncommon. Not adding the newly discovered scope into a project could also be troublesome. You may have come across something important that needs to be part of the project. The trick is when and how scope is added to the project. You want the scope to be added in a way that the effort is still compensated, but not too late to require the team to re-do tasks yet to be done.
- Setting expectations on the go-live date is also critical. If Project Management or the Customer needs to add scope to the project, there needs to be a reasonable reset of expectations such as go-live date, number of hours spent, QA/testing estimates, etc. Everything is affected by a scope change, whether it is to add or remove the scope.
- If the changing of scope in a project feels like negotiation, it likely means there is a negotiation happening at the time. This is the time where you need to leave the negotiation to those authorized. Usually, a PM, a Sales lead, etc. will make sure that both the scope and time required for executing such scope change are accounted for.
- Sometimes a change in scope can wait. There may be many reasons for this. When scope changes and those changes can wait, they are usually left for later resolution. Depending on the new scope’s priority relative to the project, the Customer may have a longer or shorter wait for the new scope to be implemented.
Experienced team members will make sure you have all scope accounted for and all necessary changes are added to ongoing projects
Nobody is perfect, and while discovering new scope after having planned your project is not ideal, it isn’t a given loss. Just make sure you help your team work through the discovery process as much as you are required.
In InfoSec’s terms, the point where you add new scope to your project is one of those high-risk points in time. You need to have considered all security implications of adding this particular feature. Whenever you change or replace a feature, you run the risk of missing out on scenarios that needed no consideration previously but now could have a serious effect on the security of your deliverable. This should not alarm you or your teammates, but it is one more thing your PM will have in mind during your project’s scope evaluation.