September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
As you know, context counts so a scope statement for a similar project from a different company might not be "right" for your context. In general, I'd suggest that as long as it meets certain principles you are good to go such as ensuring that folks have a clear understanding of what's in and what's out and the focus is more on the "what" than the "how".
The best advice I can offer is to
1) search for and review samples of templates online; there are literally hundreds of examples you can learn from.
2) Keep it simple. Avoid fancy language and legalese, you want your scope statements to be clear and concise.
3) Make sure your scope items are "SMART" goals (Specific, Measurable, Achievable, Realistic, and Timely)
4) Include a section for items that are distinctly out of scope and make sure all stakeholders agree to them. This is just as important as capturing what is in scope and helps clear up any ambiguity.
5) Even in a Waterfall project I've found the Agile terms "Definition of Done" and "What Does Good Look Like" to be helpful in a scope statement.
Hope this helps,
Hello John: First, don't sell yourself short because you very clearly described your situation in your note - so your writing skills are effective! Second, Kiron and Scott have both responded perfectly. Their advice is sound. I would especially pay attention to what they stated about things OUT OF SCOPE. This is very important. There are many templates out there and I would follow your corporate directives as well.
Thanks every, One good thing so far is there is no Cooperate directive as I am the first PM for the company using PM methods. so its kinda of molding the process. Being clear on the "Out" has been a top priority as several of the on going projects have not had this. Therefore, it seems there is no end in site.
I had taken the template from here and designed it on the company letter head so there is a clear understanding of the format and content.
A piece of advice I will offer is focus on content before format. As others have said, the content will differ from company to company. Regardless, the purpose of defining the scope is to establish the boundaries for the work.
There are several different “views” of a project like how it is time-phased, the organizational responsibilities, branches of the WBS, and the requirements. Scope may specify any or all of these. Perhaps the project ends at the conclusion of a feasibility analysis or detailed proposal submittal. Perhaps this project is only the hardware and the software is out of scope. Perhaps you are only engaging your own organization and not external suppliers or other internal orgs. These are the types of things that may need to be considered in the project boundaries.
Generally you want to make statements in a “positive” way, e.g. “We will do this.” and not the negative, “This does not include...” The negative is generally bad practice as sometimes people think that anything that is not explicitly prohibited is included. In practice I find however that to avoid confusion it helps to point out certain things that are categorically excluded.
Only write what somebody else is going to read.
If you produce a lot of paperwork nobody is interested in you damage yourself. Are scope statements the right format?
For small projects (you and your friend?) talking across the desk might be the better way to communicate or, if you want to visualize something, using a canvas pinned to the wall besides a Kanban Board (and then you even are 'agile').
If you want practice writing, you could use this forum and LinkedIn as a sandbox. Being German, I learned writing in English by producing a monthly 8 page newsletter for the Chapter - for 8 years, never missing once. So its about practice in a relatively safe environment.
Key to remember is this: project scope is defined from product scope, and product scope is not under project management accountability, business analyst is accountable for that. What is project scope? The neede work and only the needed work to achieve the product scope. You have to take it into account do not fail. With that on hand, understanding that project scope is work, then do not forget to punt clear what it is included, what is not included, assumptions and constraints. And remember: the amount of information included on project scope will depend on the project phase you are located at the time you write it.
I agree with Sergio
Thank you everyone, This has helped with Clearly understanding what needs done. I am not so far off base with what I am doing as a thought.
Please login or join to reply