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!
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.
Test yourself and see if you have remembered why having a clear scope is a good idea and what this course teaches.
In the following sections the exercises are based around a fictitious company called the “Quixote Group”.
In the “Supplementary Material” for this lecture there is a document describing the Quixote Group. Look at the document and think about its contents.
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 exercise you will create a list of candidate Factors which are relevant to scoping a new project for the Quixote Group which was described in the case study document.
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 exercise you will create a list of Pieces for the candidate Factors which were identified in the previous exercise. All the material you need is in the Quixote Group case study document.
Test yourself and see what you remember about preparing for the Scope Workshop.
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
Test yourself and see what you remember about running the Scope Workshop.
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.
Test yourself and see what your remember about documenting the results of the Scope Workshop.
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.
Test yourself. See how much you remember about "the other bits" of the method.
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.
I'm Tom Gillies and I have been a Business and Technical Analyst in the Information Technology industry for the past thirty years.
My courses are based on my real-world experiences. I am teaching as I wish I had been taught. My objective is to give you enough knowledge to make you reasonably self-sufficient, and enough experience to give you reasonable confidence, while understanding your limitations. I think you will find working at your own pace liberating and you can contact me during the course if you wish to.
I started my working life as an engineer. I have a BSc in Chemical Engineering from Aston University in Birmingham, England. As a result of my work as an engineering designer, I became interested in computing and eventually I joined IBM as a Systems Engineer, working in pre-sales for customers in the aerospace industry.
Within IBM, I moved to a consultancy group and worked directly for customers as a Business or Technical Analyst for twenty-five years. I served a wide variety of customers from large “blue chip" corporations and government departments to start-ups. I have designed, developed and maintained computer systems, large and small, on a wide variety of platforms.
In my experience of the Information Technology industry, I have found that some skills have been of lasting value. SQL is one such technical skill. Problem solving, some analysis techniques and the so-called "soft skills" are others. All of these improve your ability to communicate with both the business and technical staff make you a more valuable member of a team.
I live in the Republic of Ireland and, when I'm not working for Customers, or writing and supporting courses, I am improving my skill in the Russian language.