top of page

Importance of Scope in classical project management versus agile project management.

 

  1. Importance of scope in classical project management.

 

In a classical project management methodologies, it is verry important to get your scope well defined and clearly explained. Your scope is fix for your project since budget and planning are in direct relation to it. Remember the tripple constraint in project management scope-budget-timing. When scope changes, budget and timing will be impacted.

 

 

 

 

 

 

 

 

 

 

 

 

Project managers will need to be very attentive for:

 

* a well-defined and clearly agreed upon scope from the start of the project; which is intended not to change and in order to be able to plan and budget this scope should be analyzed in detail from the beginning of the project. Although we all know that for most projects this scope will change since customers not always know in advance what they really need; all design is not always clear from the beginning, needs can change during project execution, and so on.

 

* Scope creep is the incremental expansion of the project scope.

 

* Gold plating. This is another problem where most PMs need to be aware of. Developers, team leaders want to deliver a product of high quality. This often results in developing things that were not required. These are often things nice to have but are not part of the initial demands of the customer. This means the team developed these items for free since nobody asked it and nobody will pay for it and as such the team is spending budget and time in things that were not on the list of requirements

 

To prevent scope changes; a classical project manager will need to put in place a change control board to evaluate all kind of changes where everybody can agree upon, which impacts again the original scope, planning and budget.

 

Fact is that since you have to analyze all requirements in detail in advance, you are spending a huge part of the budget on analyzing things to have a high probability that they will change and as it you’ll spend a lot of time and budget in unnecessary things. On top of that your project will not start before the planning phase is finalized. This means already a delay in your execution track.

 

 

 

 

 

  2. How does agile project management handle these problems?

 

Of course, scope is also important in an agile project. However scope focusses here on requirements with business value on one hand and on the other hand agile projects welcome scope changes. Let me explain. In most projects you have to work with customers that have a fix budget and a more or less fix time-line. The only thing we are sure of is that scope will change.

 

In order to handle that problem; as a project manager we first define the initial scope a customer would like/need to have. The customer then prioritizes his scope list (also called backlog) according to the business value the different items in his backlog have. This allows us to get an overview of the complete list of requirements (which is nevertheless temporary) and the importance for the customer of each requirement. The list is then sorted by the business value.

 

Most important requirements are found on top of the list and the less important ounces at the bottom of the list.

Each requirement is then roughly estimated. This will give us a rough idea of the cost. Since budget is fix, we then already know if the project encounters already some budgetary problems or not. In case this would be the case you will have to decide with the customer what requirements will not fit in the budget and could be dropped.

 

Basically, since we made a list ordered by business value, it should be the requirements at the bottom of the list. It is important that the customer understands that each time that he adds or changes a requirement, that he has to put it in the ordered list and that the items add the bottom off the list will possibly drop out of the list due to budget constraints.

 

This way, the customers ends up with a product that suites his needs and covers most of his valuable things within budget and timing constraints.

 

On top of it, since agile works with short sprints a number of other advantages can be listed:

 

  • We analyze in detail in order of the requirements of a sprint. This means that only a small part of requirements will be analyzed in detail in advance. Result is that less time is spend in analyzing all requirements an d we can start earlier in development modus

 

  • Early start of developing business value for the customer. Agile handles sprints and at the end of a sprint you should generate a shippable product. Since requirements with the highest business value are developed first, there is a big chance that the customer can start earning money with your development even when it is not yet finished.

 

  • Less analyzes is done in front, means less wasted work is done since part of the analysis is done at the start of a project will need to change during project.

 

  • Since we work with short sprints and at the end of the sprint an evaluation by the customer; the miss interpretations in analyzes become clear and this a lot earlier than in classic project man agent. This way you prevent the project of going the wrong way and will end up with a result customer really expected to have instead of a product that you thought the customer needed to have but where he evaluates that the delivered product does not meet his needs. Agile wise, you are able to detect problems early in the process so that you still can manage to adapt with acceptable budget and timing impact.

 

Below you find a typical flow of a classic project management cycle versus an agile project management cycle. On side note here is that the image representing the classical project cycle is designed here as if the triple constraint was met. Most of these kind of projects however end up quite some time after the target date and encounter a delay.

In the agile process you will notice a number of repetitive items which are part of the iterative sprints. Each time it starts with a sprint planning, this means that the requirements planned to be done should be analyzed in depth but we focus on a limited set. Then they are taken into the planning for the sprint (green part), executed (pink part) and reviewed by the customer at the end of the sprint (Black part) since at the end most of the reviews have already taken place, you will end up we a far most easier way to finalize your project; less discussions since a lot of the feed-back, corrections, changes…. Have already been done during the different sprints.

 

 

 

 

 

 

 

 

 

 

 

 

 Classic PM versus agile PM

bottom of page