7. Project Scope Management Flashcards
Describe elements scope management includes
High level scope definition
Gather and categorised requirements
Detailed scope definition
Scope controlled through change control and config management
What factors to consider when developing a scope
What products are required to deliver the capability needed for benefits realisation.
What are the boundaries and main constraints. Defines what is in and out of scope. May define the systems interfaces that are in out.
Assumptions - need to be documented.ie is certification in or out.
Resources available - Who available to deliver?
What are the stages of requirements management
Gather requirements
- Wants and needs of stakeholders
- Ensure clear understanding of what the solution must do.
- Workshops, questionnaires, specialist knowledge, surveys.
- Requirements at this stage described as functional ie solution to achieve.
Analyse requirements
- Requirements further defined
- Look for gaps, overlaps and conflicts between requirements
- Each requirement should be unique, verifiable with an agreed acceptance criteria to enable progressive acceptance during transition.
Justify requirements
- Not all Requirements have same priority.
- All requirements to be justified by those requiring them.
- List of wants may be greater than what viable from business case.
- MoSCoW
Baseline Requirements
- Requirements must be agreed and signed off before solution development begins
- Must have consensus with stakeholders otherwise conflicts and scope creep later.
- Marks point of agreement and starting point.
- Change under version control giving audit trail.
Test During implementation
- Vital to ensure progressive checking that solution meets requirements
- Can be seen as series of reality checks
- Important to refer back to original requirements to avoid stray.
What are the 5 stages of config management
Planning - Any product specific procedures and how they will be applied. Need to doc. roles and responsibilities.
Identification - Final product deliverables broken down
Control - Ensure changes controlled.
Status Accounting- Records and reports of deliverables.
Verification audit - Usually at end of a project lifecycle stage.
Why may change controls arise?
- issues arise or risk materialise
• new or change in stakeholder requirements
• new regulations
• plans no longer valid
What are the stages of change control
Raise and log change Initial evaluation Detailed evaluation Recommendation Update plan and implement
Explain three steps in a requirements management process that help to establish the scope of a project – 30 marks (10 marks each)
Gather Requirements. • This is a process done early in a project lifecycle to ensure stakeholder requirements are captured and documented. • This is important as it will enable the project team to get buy in from the stakeholders by getting a good initial view of the requirements through stakeholder engagement and gain a fuller understanding of what the solution must do.
• It is good practice to gather requirements from subject matter experts and users, which helps ensure that requirements are gathered from stakeholders familiar with the “as is” state as well as those who will ultimately use the final solution.
• The final output of the process is a centralised, documented list of stakeholder functional and non-functional requirements, which can then be used for further analysis.
a)/2 Requirements Analysis.
• This is the process in which the team reviews the gathered requirements and identifies gaps and overlaps in the requirement list.
• This helps ensure that effort is not wasted on duplicates as well as mitigating the risk of a missed requirement.
• Each requirement is given a unique identifier, which enables the team to track a requirement throughout each phase of a project lifecycle.
• Each individual requirement is analysed and progressively elaborated to ensure it is testable with measurable acceptance criteria which helps ensure successful handover to business as usual.
• Requirements are also analysed to ensure they are traceable, and thus aligned, to the business case. This ensures they are consistent with the vision and objectives of the project.
a)/3 Baseline Requirements.
• This is a process in which the Steering Group formally accepts the gathered and analysed list of requirements which are deemed as in scope for the project.
• Any changes or additions to the requirements baseline is subject to formal change control. This enables the project team to implement a change control process against an agreed baseline.
• An agreed prioritisation of the baselined requirements is essential for determining the urgency of future work. This provides a valuable input into future analysis should the project need to de-scope elements of the work.
• The baseline provides all stakeholders with a common understanding of what the project will achieve, what will be delivered and the rationale behind what is included in the baseline and why some requirements were deemed out of scope.
• This provides valuable information for subsequent lessons learned reviews
Explain two breakdown structures that are used to develop the scope of a project – 20 marks (10 marks each)
Product Breakdown Structure (PBS).
• This is a graphical hierarchical representation of the products a project is required to produce so that the scope is clear and unambiguous. This will allow a baseline of scope to be produced.
• The product is broken down into categories. A house, for the example, is broken down into categories such as walls, roof, windows, landscape, plumbing and electrical. This will allow responsibility for these deliverables to be allocated to the suppliers/specialist.
• The suppliers/specialist can then further develop the scope is a more detailed way. For example, landscape is broken down into driveway, garden, patio, etc. This ensures that scope is fully understood before the work begins and the goals are clear.
• The PBS is presented to the stakeholders for review to verify completeness thus assuring no elements are missing. It also provides a baseline to enable the team to create the Work Breakdown Structure (WBS).
b)/2 Work Breakdown Structure (WBS).
• This is a graphical hierarchical representation of the activities required to produce all the products in the PBS.
• The suppliers/specialists will help identify these activities and the developed WBS will be used for analytical estimation (or bottom up) estimating to get an accurate overall cost, and level of effort (e.g. man/hours) for the project. This is important where a fixed price is being sought.
• The WBS can also be used to produce Work Packages which consist of one or more activities grouped together to be handover to the suppliers/specialists. They will then potentially break the activities down to a more detailed level to allow the work to begin.
• This ensures that the work is fully costed and understood before it starts increasing the likelihood of success
Explain three steps in a change control process – 30 marks (10 marks each)
Raise and log a change request.
• This step captures the details of the change request (CR) and formally submits them to the project manager.
• This ensures there is a formal process available for requesting changes, and mitigates the risk of informal, undocumented changes being introduced to the project scope.
• The key elements of the CR are captured on a change request form which allows for further analysis of the impact of the requested change to the project’s scope, cost, schedule, resources, and risk.
• The existing of a formal mechanism for raising CR’s provides confidence and assurance to team members that changes have a controlled point of entry into the overall change control process.
a)/2 Initial evaluation.
• This step evaluates the request to decide whether or not to conduct further analysis on the CR. This protects the project from spending time and resources on detailed analysis for changes that should not be implemented.
• It also provides for a decision point on who will fund any required further analysis. For example, a customer may request a complicated CR which will require considerable effort and cost to analyse effectively.
• The supplier can use the outcome of this step to formally ask the customer if they are willing to pay for the analysis.
• The documented decisions made during this step are valuable inputs into lessons learned for subsequent review and dissemination.
a)/3 Update Plans and Implement.
• During this step, the project team must implement the change as well as update all related project documentation and configuration records to accurately reflect the new status.
• This allows for a formal link between the change control process (CCP) and configuration management, thus ensuring that documentation is kept in line with completed changes (e.g. version number updates).
• This will help ensure the successful transfer of final products to business as usual (BAU) because all changes will be represented. This allows BAU to support and use project outcomes effectively.
• This step of the CCP acts as a communication medium which makes stakeholders aware that the change has been accepted and provides status reporting regarding the progress of implementation.
Explain two activities in a configuration management process that help to manage the scope of a project – 20 marks (10 marks each)
Identification.
• This is part of the overall scoping activity where each configuration item is identified and given a unique number. This enables the team to track updates to the product scope throughout the project lifecycle.
• This allows for accurate accounting and tracking of the configuration item, which provides a communication link to stakeholders regarding updates made to the product scope.
• The Product Breakdown Structure (PBS) is the key scope document used during this step as it provides the project team with a basis to identify the elements of the product which need to be tracked and managed.
• The identified and uniquely numbered configuration items provide a baseline for implementing any approved scope changes which are being implemented.
• It also identifies items which do not requirement configuration management such as progress reports and project logs thus saving unnecessary effort and administration.
b)/2 Verification and audit.
• This checks that the actual product scope is accurately reflected in the configuration documentation; this is done prior to handover to operations.
• This helps mitigate the risk of discrepancies in the documented scope vs the actual scope and so avoids support issues further along in the product lifecycle.
• Where there is a discrepancy, documentation should be updated to reflect the ‘as built’ state.
• Additionally, as the audit is independent of the project team, it provides confidence to stakeholders that configuration documentation accurately represents the current state of the product scope.
• Results of the verification audit can provide valuable input into lessons learned regarding how well scope was documented during the project as well as identify any needed corrective actions.
