Set the Scope for a Successful Project-Prevent Scope Creep
- 1 hour on-demand video
- 17 downloadable resources
- Full lifetime access
- Access on mobile and TV
- Certificate of Completion
Get your team access to 4,000+ top Udemy courses anytime, anywhere.
Try Udemy for Business- By the end of the course, you will have learned how to run a workshop to define the scope of an Analysis project.
- You will learn how to define scope, based on things you know already
- You will learn how to use this technique to obtain agreement from the project stakeholders
- You will learn how to prepare for the Scope Definition Workshop
- You will learn how to run the Scope Definition Workshop
- You will learn how to document the decisions made at the Scope Definition Workshop
- Sufficient experience of IT projects to recognise the problems caused by poorly defined scope
- Access to a device capable of running courses on the Udemy site
I have seen the start of a lot of projects! Everyone wants to get a project off to a good start, but Analysis and Requirements projects are notoriously difficult to define. This course teaches a technique I have used to define the boundaries of all sorts of things. I've used it as an individual, with a team and with larger groups. I have found it useful. I think you will too.
You will have heard Project Managers complain about “Scope Creep”, Scope creep is when the “To-Do list” keeps growing, especially when it grows faster than we are completing the tasks. Projects work better when: we know what we need to achieve, the scope is fixed, we are not being given extra things to do and the Project Manager and team are not constantly having argue against “things being added”. A clear project scope is one way of combating scope creep.
An analysis project may not start with clear boundaries. If “A clear scope makes for a sound project”, how do we define that scope without performing the analysis? This course shows you how to do just that!
- Project Managers
- Business Analysts
- Technical Analysts
The creation of this course was prompted the question: "How to define the boundaries for Requirement Gathering?" This course teaches a technique which I have used to define the boundaries of all sorts of things. It starts from the proposition that “A clear scope makes for a sound project”. It explains how to set the scope for “an analysis project”, even when we don’t have clear boundaries to start with. This lecture explains the structure of the course.The other lectures in this Section: explain why Scope matters and introduce the technique itself.
In this lecture I discuss what we mean by “Project Scope”and explain why it matters. I explain that we are using Scope in the sense "the extent that something is allowed".
The project scope is what we are going to do and how we are going to do it. It determines what we are going to do. It is how we decide what should be in our “To-do list” and how we determine the territory we are going to cover. This is particularly important for analysis or requirements projects. Scope matters, because without a good scope definition we are unlikely to achieve our goal.
A clear project scope: makes it easier to explain why the project is doing, or not doing things, and it makes it easier to explain project priorities.
In this lecture I give you an overview of the entire Scoping Technique, to give a structure to the more detailed lectures which follow. I introduce: how to prepare for the Scoping Workshop, the Scoping Workshop itself, and how we document the results of the Scoping Workshop.
You may wonder about my background and experience. This "lecture" contains more background information about me, and tells you a number of ways you can get in touch with me.
In this lecture I explain how to identify the Factors which we will use as the basis of the Scoping Workshop. I’m going to: provide a working definition of a “Factor” and explain how it is used in this technique, suggest some commonly used “Factors”, explain what makes a good “Factor”, explain why actually identifying candidate “Factors” is often easier than you might expect.
In this lecture I show you how to break a Factor into the pieces which we will use in the Scoping Workshop. I going to start an explanation of how to break a Factor into pieces, work through an example, show you some additional work you should do to allow the Workshop to run more smoothly, and finish with some further examples.
In this lecture I explain how to run the Scoping Workshop. I describe it as a formal workshop, but of course you are free to adjust the format to meet your own needs, especially when you are working with small groups, or even alone. I outline: who should attend the Workshop, what materials and facilities you need for the Workshop, and how to run the for the Scoping Workshop itself
In this lecture I show you how to document the results of the workshop so that they can be used: for communication and as the basis for further work. I explain why some kind of documentation is necessary, show you the structure for what the document should contain and explain how and when to produce the document efficiently.
In this exercise you will put what you have learned into practice by producing a Scope Definition document.
If you are working as a group then it is more fun to do the first part of this exercise as individuals and then join together as a group to compare notes and look at the sample I provide together.
In this section I tell you about what I have described as “the other bits”; the parts of the method which you need to know about, but which would have interrupted the flow if presented earlier. In this lecture I explain how to handle the exceptions you are going to encounter with when you run the workshop. You could describe most of it as “objection handling”. I’m going to cover: how to handle the situation when people want to add both Pieces and Factors, and how to handle disagreements, when the people at the workshop cannot agree whether a particular piece should be “in-scope” or “out-of-scope”.
In this lecture I point out the things which are not covered by this technique. The bits which are “Outside the scope” of the technique! And I explain why those things are not included. The things this method does not cover are: any measure of size for the pieces, any concept of priority or importance for the pieces, the relationships between the pieces; an the effects of politics on the selection of pieces.
In this lecture: I remind you of the idea of a Context Diagram, show you that while the boundary of the system may be fixed, the scope of an analysis project is in fact arbitrary, and that the scope of the analysis project should always be set a little wider than the scope of the system which is being designed.
This is not a course on Project Management, but you need to understand where the Scope Workshop will fit in the in the project life-cycle. In this lecture I explain how the technique I have described relates to Project Management methods, in particular:“Waterfall” methods (such as PRINCE), And “Agile” methods (such as DSDM, Scrum and Xtreme programming). I explain when the Scope Workshop should take place, and how the Project Manager can use the output from the Scope Workshop.
In this section I remind you of what we have covered during this course on: Setting the Scope for a Successful Analysis Project. The justification for having the method is: “A clear scope makes a sound project.”
While setting the scope, we need to constantly remind ourselves: “We need to set the scope for the analysis project, not perform the analysis!”, because there is always a temptation to “get stuck in”, and create the illusion of rapid progress at the cost of losing control.
This is a single page "mind map" which summarises the method taught in this course.
You’ve learned the theory and if you have done the exercises, then you have some experience. You know that:“A clear scope makes a sound project”.
This lecture suggests how you can move forward and become fully proficient with this technique and integrate it into the other things you know.