Hi Paul, final set of answers today. Struggled with some of these, partly because I wasn’t sure what the questions was looking for? Any comments/advice gratefully received. I’ve put comments specific to the questions in italics to distinguish them from my attempts at answers. Thanks, Sarah
Explain what is meant by the term ‘project scope’.
With the aid of suitably labelled diagrams where appropriate explain four aspects of defining a project’s scope.
The scope of a project is all of the outputs of a project will produce, the tasks involved in producing these outputs and the benefits to ultimately be derived from the outputs. In part, it is a combination of the Work Breakdown Structure and Product Breakdown Structure.
Five aspects of defining a project scope are as follows:
The production of a Work Breakdown Structure will identify the work packages involved in the scope of the project (diagram?). The work packages are the lowest level of the tree, which is hierarchical in nature, and the point at which the activities involved do not require any further subdivisions.
A Product Breakdown Structure is similar to a Work Breakdown Structure but defines the products which the project will deliver (diagram?). The Product Breakdown Structure will give you a set of interrelated products to be produced by the project which is important for change and configuration management.
Not sure about other points – Organisational Breakdown Structure and RAM/RACI
Or should the four be project, outcomes, outputs and benefits?
Explain five uses of work breakdown structures, including how their use is of benefit.
Five uses of a Work Breakdown Structure are as follows:
-
A Work Breakdown Structure is used to break the tasks in a project down to their lowest, most detailed level resulting in the formation and understanding of Work Packages. These resulting Work Packages are delegated to one person or party who is accountable and are discrete packages of work. This is a benefit because it gives clarity on what work packages are required to complete a project successfully, allowing more effective planning and project management.
-
A Work Breakdown Structure defines all the work required to complete a project on all levels. This gives the project manager an oversight on everything that is necessary which is a benefit as it will enable more effective management and a greater chance of success.
-
When combined with a Responsibility Assignment Matrix, the work packages resulting from the Work Breakdown Structure allow the project manager to allocate roles and responsibilities to team members. This is a benefit because it provides clarity on roles and responsibilities to all team members.
Not sure about 4 and 5
List and describe four steps in a typical requirements management process.
Explain why requirements management is important.
Four steps in a typical requirements management process are as follows:
-
Capture
-
Analysis
-
Justification
-
test
Capture – at the beginning of a project the users’ requirements must be captured. There are several ways to do so, such as brainstorming, surveys, prototyping, written specifications or questionnaires. It is important to capture all and any requirements so that the project has the greatest chance of fulfilling them with the minimum of change.
Once captured all requirements must be analysed to see how they can be achieved through the course of the project. The requirements will be analysed on the basis of their value, priority, the time taken to achieve them and processes required to do so. These factors, together with any overlap or gaps, must be considered in order that the requirements the project is aiming to satisfy are identified and understood.
Once analysed, requirements may need prioritising and justifying for inclusino in the project. One tool for this is MoSCoW:
Must have – vital, business critical requirements
Should have – nice to have if time and scope allows
Could have – desirable, but can be done later
Won’t have – will not be included
Defining requirements according to the above allows the project manager to define a set of requirements the project can deliver on.
Clearly, if requirements are set for a project they must be tested so that a judgement on the project’s success can be made. Different tests will be required for different requirements and these should be identified at the beginning of the project.
Requirements management is important because, without it, the project does not have a defined goal to work towards, leading to confusion. A lack of requirements management can also lead to a large number of changes throughout the project as the users change or add to the requirements they have. Changes generally add costs and delay to a project so minimising it is important.
List and describe five steps in a change management process.
5 steps in a change management process are:
-
Change request and recording
-
Initial evaluation
-
Detailed review
-
Recommendation and decision
-
Implementation and update plans
A change request will generally come from a user. Once received, the basic information should be recorded in the change log. The change log entry should include the change number (to easily identify it), the requestor, a brief description, the date it was requested, its status and a brief impact review.
Once received a change request should be subject to an initial review. This initial review is a quick review to determine the change is worthy of a more detailed analysis. The project manager will look to see if the change is viable and worth. If not, no further action will be taken.
If it is decided that a more detailed review is warranted the project manager and team will carry that out. This detailed review will look at the costs of the change and its potential impact on the project and its schedule. A change, if implemented, will change the business case and so must be considered if light of this. During this stage the impact on any other work packages or products must also be considered.
The results of the detailed review would be a recommendation to the sponsor as to whether the change should be implemented. The project sponsor normally has the authority to decide whether changes can be implemented and will accept, reject or defer them.
If the sponsor decides to accept the change the responsibility for implementing it will fall to the project manager. They must include the change into their plans and, through the configuration management process, make sure all associated documents are also updated. Everyone involved must be informed of the changes so everyone is working to the same plans. Once the change is included ni the plan the change management process ends and normal project work resumes.
Explain five potential consequences of changes not being properly managed on the project.
There are several potential consequences of change not being managed properly.
If not properly managed, change can lead to different team members working to different versions of the project plan and specification documents. This can then lead to integration issues when products are delivered which can add time and cost to the project as tasks are revisited to allow integration.
Ineffective change management can also lead to a loss of morale in the team. If team members feel they are not being kept up-to-date about the project and changes affecting it they can become dissatisfied and unmotivated. In turn, this can effect the standard of their work which could jeopardise the project.
There is also a risk, which change is poorly managed, that the output of the project will not satisfy the users’ requirements and will therefore not deliver the benefits envisaged. If different users request different changes, or these changes are not effectively communicated to all stakeholders there is a risk the output will deviate from what is required.
Poor change management control can increase the time and money spent on a project. If not properly evaluated and controlled for changes can cause delays or scheduling problems which have a knock-on effect for delivery time and budgets.
Poor change management can also lead to scope creep where changes are made to the project baseline via informal means. This can add time and cost to the project. Also, with changes made in this way without a formal process, it is highly likely not everyone who needs to be would be informed about the changes.
Not sure about this answer as generally it seems to be saying the same thing (increased costs, delays and unhappy stakeholders) in several different ways. Not sure what else I should be aiming to say?
Sarah, with questions looking for the benefits of, or consequences of it is useful to think of the impact on time, cost, quality, team motivation risk and safety. You can always make an answer from these.
The scope question is more likely to include defining and controlling scope. This question runs across several areas in the BoK. I would tackle this with
1) Talk to the users and stakeholders to define the requirements. Understand the need for the project.
2) Identify the product or deliverables to be produced and structure these as a PBS
3) Define a WBS.
4) Track the completion of the products to makes sure we are not getting scope creep.
5) Implement change control to control changes in scope in a formal way.
It is a tricky question because it spans several areas of the body of knowledge.
The WBS is also used to define work packages that are allocated to team members to deliver and it forms the base of the structure used for bottom up estimating. Again this answer pulls from several areas of the Body of Knowledge.