In the project management world, it would be nice if we had the luxury of just going with the flow.
To be carefree and changing as we go and accepting every new customer thought and request with a “Yes, certainly, that can be included, too!” But we can’t. It would be a recipe for complete and utter failure. We have to have some boundaries. We have to have that line in the sand. We have to have project scope.
Project Scope is a Necessity
Oh yes, those can be dirty words. But we must track and protect the project scope as the leader and manager. Thus, becoming both the friend and foe of the project customer. They want us to manage a successful project for them and use their financial resources, i.e. project budget, wisely, but they would also like the ability to add and change things throughout the project engagement as their needs either change or become more clearly defined. We would love to accommodate that preference, but we can’t.
The requirements that make up project scope are the “lifeblood of the project.”
I have a few mottos tattooedon my project management hat and that is one of them:
“Requirements are the lifeblood of the project”
“Communication is Job One for the project manager”
“You’re only as successful as you last customer thinks you are…”
Follow these three and you’re on the path to project success. Ignore the first two and you’re likely headed for a big project full of headaches – which means you will fail the third one.
https://www.workzone.com/blog/what-is-scope-creep/
Four Key Points of Project Scope
Let’s review what I consider to be four key focuses that you must have during the project scope management process on each project you manage…
1. Get the requirements documented well in the initial phases. I’m not saying you have to have all detailed requirements in place on day one of the project. That will never happen. In fact, you aren’t likely to get them fully documented in enough detail until you’ve gone through the requirements discussion and documentation process and then worked out some of the requirements tweaks, assumptions and unknowns during early design. But make sure everything is well documented and eventually signed off. It’s the baseline for the rest of the work on the project.
2. Implement and follow strict change control. You have to get serious about change control. That means how will you handle change requests? You most likely already have that methodology in place so be sure to relay that process to the client and all stakeholders as they come aboard starting at the project kickoff meeting. The last thing you want is a frustrated project customer who is being surprised by change orders throughout the project as they are changing or clarify project requirements.
3. Avoid gold plating. Is your team going above and beyond for the customer? Would you know if they are? I’m not saying your team is bad or playing for the other side. Sometimes our developers on technical projects end up working very closely with some of the subject matter experts (SMEs) and ultimate end users on the customer side and work in small changes or special requests possibly without even realizing they are going above and beyond the call of duty… err…. project scope.
The end result can be cost and schedule overruns as the extra work builds up. If everyone is aware and actively discussing scope and current work progress as a cohesive team, this likely won’t happen. Project managers – make sure your team is aware of this innocent, but potentially harmful practice and the affects it can have on overall project budget and timeline. Every hour counts and we can’t give them away for free – they painfully add up if we aren’t creating change requests to cover that extra work and extend expected deadlines and due dates.
4. Test, UAT and sign off. The documented requirements not only play a monumental role in the design and development of the project solution, they also tend to play a big role in any system tests and user acceptance testing (UAT) we do on the project. Test cases and test scenarios are built off the project requirements and testing success is measured against the planned requirements for the solution. Is it doing what it is supposed to be doing? The requirements tell the story. Getting the requirements right means you have a usable baseline to measure testing against.
Conclusion
Requirements in your project scope are critical. Good, detailed, complex requirements are critical. If we don’t have a good target to aim for, then hitting it really won’t mean much and at the end of the day project success or failure… no matter the reason… is still the project manager’s overall responsibility. So stick to your guns, plan and explain your project change control processes well so everyone knows what to expect, what their role in it is, and how they can help make it successful.
