- Project, Programme and Portfolio Management
- No comments
Essential to projects within which you might consider utilising Agile (with a capital ‘A’) methodologies (such as Scrum and Kanban) is a list of requirements of which some are more important than others. Without such a list there is no basis for carrying out ‘sprints’ because there is no ‘backlog’ of prioritised ‘features’ described by ‘user stories’.
Project management should always aspire to be agile (with a lower case ‘a’) in order that there can be quick responses to new risks, issues and changes, but the application of Agile (with a capital ‘A’) methodologies introduces complexity that should be utilised only if there are clear benefits of doing so, rather than using simpler alternatives.
Such a simple alternative is to use a technique that has been around (and used successfully) for a long time called MoSCoW. To use this technique you list the requirements under four headings, namely:
- Must have
- Should have
- Could have
- Won’t have
The MoSCoW document becomes a key project management asset for controlling scope and stakeholder expectations, and should therefore be maintained under configuration management. It is an important consideration for planning, whereby the tasks and effort required to deliver each set of requirements (Must have, Should have and Could have) should be made clear by tagging or cross-referencing.
There should be frequent reviews with stakeholders during delivery of the requirements/features at which time, if the reviews result in change requests, the MoSCoW document should be formally updated. The plan should then be reviewed and adjusted accordingly. If a time-boxed approach is being applied to the delivery phase of the project, then the priorities of the requirements that are planned to be delivered (i.e. the scope) will change without affecting the project schedule; otherwise the changes may affect project timing (and therefore, usually, project cost).
The project plan should have a risk log (with schedule and cost contingencies) associated with it. If the delivery phase of the project is time-boxed, then the risks will be that stakeholder satisfaction might be reduced if the number of requirements delivered is low; whereas if it is planned to deliver as many of the requirements as possible within a flexing timescale, then there will be risks to project timing and cost. These should be estimated and included within timing and cost contingencies during project initiation and maintained thereafter in relation to project progress.
Quality of deliverables should be ensured by including appropriate testing within the project plan. If time pressures drive decisions to reduce testing then the risk log should be updated accordingly. This is, unfortunately, common of course, hence poorly performing projects often exhibit quality issues rather than (or as well as) incur increased project costs, although the ‘costs’ of reduced stakeholder satisfaction and/or post-project rectification are often (arguably) greater.
If you would like more help with how to apply MoSCoW to be agile, please get in touch.