Scope Management Video

/Scope Management Video
Scope Management Video 2019-10-06T15:16:59+00:00

Hello and welcome to my series on the PMP exam preparation course we are now on project scope management which is a whole new knowledge area and what scope management is concerned with is the requirements for the project the scope of the work that needs to be completed the deliverables that need to be handed over during and at the end of the project so it is all the work required for us to be able to hand over a product or result that the sponsoring organization would have requested and that means looking at two types of scope and one of them it would be the product scope that’s the physical deliverables whether it’s a product service or result that’s the physical outcome that you’re handing over and there’s also the project scope this is the work that we have to do to get the physical product so for example if I was making let’s say I was making a table right or a chair you know putting nails or cutting up wood you know that’s physical work so that’s the product scope and it has the dimensions of what it is that you have to produce whether it’s maybe 2 feet by 3 feet you know those specifications are given to you by your client so that makes up your product scope but then there is also the work you have to do to obtain the wood to get the nails so all the purchasing procurement that you have to do the meetings you have to do to get the specifications these are considered the project scope right so agreements you have to make documents you may need to be you may need to prepare these are all project scope so there’s work that we do even looking up you know subject matter experts consultants and so on these are things that don’t show up in the final product instead these are things that we do behind the scenes aside from the product that you end up seeing so it is on top and above the work that we do the construction or the implementation and so on and we have to factor those into our scope excluding them from our scope or estimates would shortchange us so I’m not just going to wake up one day and find a piece of wood and start making that table instead I need to have meetings and understand the requirements and then go and seek providers or suppliers of that wood and make sure that the type of wood matches so all these things will not really be seen in the final product your client eventually just sees a table or a chair and they test it out and if it’s fine they take it so that’s that the end result is a product that you’re handing over but the work that you have to do that’s the project scope so in scope management here we are concerned with the total scope that this projects want to require but also what is also important here is that we are focused only on the work required right so we’re not really going to try to impress and do more than that we should just deliver the scope that the client requires now defining the scope would be one thing and managing it to make sure that it does not get changed you know in a chaotic fashion as we proceed would be part of our expectations all right now looking at the processes in project scope management there are one two three there are six processes here starting from plan scope management which a lot of people confuse with the scope itself right so this is not the scope this is the approach you want to use in managing scope on the projects so it’s not the scope itself it’s not the requirements it’s the approach you want to use right in managing the scope on the project after you come up with the approach then you go into electric wire man’s defined scope create WBS and these would form a this these will make the planning part of scope management and after that we need to keep things in control so we validate scope and we control scope alright so the first four that you see here these are the planning aspects of scope and the other two are the monitor and control and these are the six processes we will cover in scope management planning all right now things to be mentioned here with regards to a predictive and adaptive life cycles you’ll find that in a predictive in a predictive life cycle that the little bubbles are defined at the beginning of the project and then any changes after that would be managed and typically in a predictive life cycle changes will be disruptive why because you know as in a waterfall model you you prepare your scope in advance and you you’ll get agreements on it and then from then on you start working on it in phases right and you you know you cross check in with your client but you know when somebody wants to introduce a change halfway through your project then that means that the remaining part of what you had planned would have to be modified and so we we will find that it’s more disruptive than you would find and adaptive in adaptive or agile life cycles the deliverables get developed over iterations so we don’t really work with a full scope of the project instead maybe we’re focused on the outcome and we we do this in sprints we work with a product backlog of features or requirements that the client would like to see in the final outcome and at the very beginning of every iteration and there’s also deterrence print that we use at the beginning of every sprint we determine what are the highest priority items from the backlog and we plan on delivering these in about couple of weeks all right let just bring the whiteboard over okay right so just to explain how agile works all right agile what it does is we have we have our clients and let’s say the clients we sat with them and we got tons of requirements from them and I’m just gonna draw lines here and what I mean with these lines is we have either features or requirements so I’m just gonna write you know feature a and then we have feature b c d e and f so these let’s say were the features that we got from our client and we decided that from these features that the following were the highest priority features that they would like to see first right so we initiate the first sprint here right we initiate the first sprint I’m just gonna write sprint in here and you you don’t have to call it a sprint but I mean that’s a common term that we use out there and the feature is BCD would go into that one sprint right and we will assign a project lead maybe myself I’m the PM and my team and we get agreement from the steering committee or the board or your sponsor on these features B C and D that these are relevant to them and that you know these are the highest priority at this point and we go and we work on that one sprint and usually the time schedule that we put on this is 10 business days or we say 2 weeks right I’m just gonna write 10 days here so there are 10 days that we have allocated to this one sprint and every day of the friend would represent 10% because it’s one out of ten days so two days will be 20% at the end of the two-week period what would happen or what the expectation is is that we would have delivered B C and D and we can demonstrate these to our stakeholders okay we demonstrate them and they look at them and based on what they see they will give us direction on the next sprint that we need to run so now we think about the next sprint that we have to run right in the next friend mind you B C and D here have already been completed so we don’t need to do them anymore but we do have a we have e we have F that are still carried over in our backlog so we still have a we have E and we have F and maybe while you know based on what we saw in the first friend they’ve decided that maybe we could also do G and H as features now that we have confirmation from the first sprint okay so this is how agile works this is how adaptive approaches work we adapt based on what we saw and the first sprint and we figure what should go into the next friend sprint a or the first sprint here sprint number one gave us certain capabilities sprint number two will give us additional capabilities and these are incremental scope that is being delivered by the project team it is almost immediate gratification to the organization because they are able to use these in an incremental fashion now as we progress we carry over in our backlog all that came out weird so we carried out we carry over in a backlog whatever features were not completed previously and then we add the following to them the following was added due to what we were able to determine from the very first brand we realize that additional capabilities could be built in and so now we have AE F G and H and then what happens is the organization decides which of these are the highest priority let’s say they determined that a G and H are the highest priority items then that means that those are the ones that are gonna go into that one sprint and we will work on these right so this one would also be another ten days that we have to work on and at the end of the ten days we will review with the board or the sponsor the results and so we call this a change driven approach because at the outcome we decide on the next grant which could be you know it could be deemed a change in direction we may decide to take this too or take it in a different direction and maybe include different features based on what we were able to see for capabilities so with every sprint which is roughly 10 days the organization determines how to proceed and they are getting confirmation on capabilities that have been developed so what you see down here what you’re able to see down here these are the the backlog right and so we carry through this backlog as we work on the project now let me drag this out a little bit and what I would like to introduce at this point is burn up and burn down charts because in the agile methodology we use that a lot so a burn down chart will look like this and what you will have is the amount of work that we need to complete right and let’s mark it there on the left and what we have on the axis down here is time right so time is progressing in a certain direction and on the Left what you have is the number of features or requirements in our o’clock okay so this would be a backlog right what’s left in the backlog we usually would start with all of the work in our backlog so let’s say we have a couple of hundred items that we need to deliver and we started working on it so if we worked on this for one week two weeks and so on what you’ll find is that you will complete some of the work and you know it could be in bulk well completions both deliverables and with time as time progresses less and less of the work is remaining and you’re completing this work according to a plan that you have so what you see is the remaining amount of work is reducing as time progresses because more of the items in your backlog are being executed implemented in the sprints all right so at some point the work will all be completed here what you see now is a downward trend altogether like that and that’s why they call it a burn down chart all right so you’re counting down the remaining work and typically what an organization will do is it tracks actual remaining work so maybe you had an ideal goal to go from here right straight down if I could draw a straight line straight down here and what you see in the colored lines that I produced previously like this right this part of it it’s showing you actual remaining work versus what we had planned in the red line to have had so we start to track actual remaining work versus the ideal and depending on how we are progressing on the actual work we might be able to draw maybe a projected line that gives a better indication to the organization of when we’re actually going to finish all the work all right so based on actual results we can track we can forecast when the project will be completed so that’s just flavor of how agile works and how we work with backlogs okay so now that we know about backlogs let me introduce the the role of the business analyst here so you’ll see that these days the world has you know shifted with regards to trends in how project management is done organizations have recognized that requirements gathering is a core skill and one of the roles that takes care of requirements gathering and management is the business analyst so business analysis has picked up in recent years and especially with technology now becoming very prominent and most of transformational change is happening biotechnology so business analysts are professionals who are highly qualified in being able to sit with a business stakeholder and determine what the problems and the business needs are and then go and meet with the relevant stakeholders and gather their requirements and eventually be able to develop solutions that will meet those specific needs business analysts tend to do their work prior to the project being started so for example a business case feasibility study these tend to be done by business analysts and after they study the need from the stakeholder and look at all options available alternatives and so on they analyze them they look at requirements that different stakeholders may have had from responsive sponsoring organization and they formulate what they believe is a viable solution that the organization should go with that solution at the end is what ends up being your project charter okay so just wanted to bring that bring that up before we proceed finally for the introduction here in scope some things we need to mention here are that in evolving environments where a lot of things are not clear where we have risk right so we have evolving requirements we have high risk we have significant uncertainty and we don’t understand the scope really well it is highly recommended that we go with agile methodology which is similar which is the other word for adaptive alright so when you think adaptive think agile and agile allows you to spend less time trying to figure out what needs to be done at an early stage and they avoid doing that instead they spend more time establishing the process for discovery and refinement this is done through sprints and so we look at a backlog as we mentioned previously we have a list of items that the sponsoring organization would like to see happen and then we go with release versions and that would help us show some of the results as we go incremental and as we see the results were able to define and redefine the scope throughout the project using additional sprints and prioritization of the requirements and features that are listed in the backlog so that backlog that we discussed is going to be the pool of the requirements of features that the organization is interested in and the benefit of agile is that we get to prioritize the scope right we prioritize the features their requirements based on the stakeholder needs incrementally as every sprint is worked on alright so that completes the introductory area of scope management and I think I’ll stop here and post this and on the next on the next video we will start with plan scope management alright so I’ll see you on the next video take care and have a great day bye bye