- Detailed requirements -> specification -> plan
- Viewed as ‘well understood’
- Relies on fixing requirements early
- Difficult for customers because they don’t know exactly what they want
- Forced into defining something they don’t understand
- Baselined requirements can only be changed through formal change control
- At project delivery, the end product is not what the customer would’ve chose because understanding & circumstances may have changed.
- Meeting real needs means using change control
- Change control is essential, changes can be expensive.
- Impact analysis illustrates effect of change on time, budget, quality, risks, benefits.
- The later in the project life cycle a change is raised, the more it tends to cost as there can be more rework needed
- Quality control, inspection testing come towards end of project.
- If project running late, choice between doing ALL planned quality control activities OR delivering on time.
- Generally delivery on time squeezes quality control, leading to delivery of outputs that don’t deliver as well as they’re supposed to
- Correction of defects can be expensive, & like change requests the later in the project they’re identified, the more they tend to cost.
- Sometimes correction costs deliver less value & are therefore left in place
- Generally, not all requirements are equal.
- Some are essential, other desirable, some are just cosmetic.
- Some offer significant return, others very little.
- Because all requirements must be delivered, together, important/ high value requirements are held up waiting for cosmetic requirements of little value. ROI can be delayed.
- Project can overrun on time and budget
- Fixing requirements/features by allowing time, budgets & quality to vary even when they’re not supposed to
- Less sequential
- Focus on what business sees as important
- Guarantee to meet quality standards
- Deliver on time
- Deliver on budget
Requirements are captured at a high level early on, detail is allowed to evolve
- Collaboration & communication are used to understand lower level details as project unfolds
- Builds change & innovation into design & development, and has effect of reducing cost of change
- Change control still retained to adjust breadth of scope, meaning customers can add detail to requirements, but if they want to add new requirements then change control is invoked
Quality is built in since quality control takes place throughout the project instead of being stuck on the end. Achieved by checking a bit at a time, & checking integration of components as they’re produced. If possible, testing is automated so re-checking, or regression testing, can be done simply and easily
Agile projects will not necessarily deliver the full scope! Trade off that allows Agile to fix time, budget and quality of the project by flexing the scope. Meaning requirements have to prioritised -> MoSCoW, as decided by business/customer/user, not technical project team members, or those who have an understanding of the business needs.
Agile projects include business oriented people alongside specialists. Not just business sponsor, but those with business role so decisions can be made from business perspective, leading to understanding business need is built into project’s output
- Allows project to evolve
- Decisions made at last responsible moment
- Embraces change, recognising without it, often deliver wrong output
- Emphasis interactions between people, better communication than documents
- Undertakes quality control throughout project instead of end
- Recognises not all elements of scope are equally valuable
- Flexes scope to meet deadlines & budgetary constraints
- Acknowledges business focussed people needed as much as specialists
- Allows early ROI
Some features are so important that people will use them immediately & the organisation will benefit having them available asap
MoSCoW: Prioritisation scheme of requirements/features
- Must have: So important, project will not go ahead if they can’t be delivered
- Should have: Very important, painful to do without; workarounds only possible for short amount of time
- Could have: Less important, workarounds could be sustained for extended time if necessary
- Won’t (this time): Maybe important in future, but not needed yet & will be left out
Prioritisation allows flex to scope to keep project on time and budget
If not enough time/budget to deliver everything then business can choose which ‘could have’ to leave out. If no ‘could haves’ then business chooses which ‘should have’s to leave out.
Proportions of Musts, Shoulds & Coulds are important. Recommended:
- Must have = no more than 60% of effort
- Should have = ~20% effort
- Could have: = remaining 20% effort
Business case can be made on basis of delivering Musts & Shoulds with Coulds being viewed as contingency
Evolution of requirements.
On Agile projects, no attempt is made to capture low level detail of requirements as this is seen as being counterproductive, since it is unlikely they are well understood at the beginning & that understanding is likely to change as the project unfolds
However requirements are still gathered, but don’t capture low level detail until required
- On any project, traditional/Agile, the viability of the project should be based on a few high level requirements, typically <10
- Once viability established you need to plan how to run the project which requires more detail. Difference with Agile is that the detail is limited early in the project.
- Take <10 high level requirements and add a level of detail. Typically we now have <100 requirements, which is far fewer than by the end of the project, or traditional project
- These <100 can be MoSCoW prioritised
- Planning & budgeting is based on these <100 requirements
- Don’t plan in detail until shortly before we need that plan
- Low level details of requirements are obtained shortly before we need them to create a product, allowing the business & technical team members to explore detailed requirements together
Business involvement is critical to success of project because:
- 1st principle of Agile Project Management is ‘Focus on business need’
- Business members are there as decision makers
- Requirements allowed to evolve & business say what they want
- Relies on collaboration between business & specialists
- Requirements documents are seen as providing poor levels of understanding compared to what can be achieved by business & specialists talking to each other
When it comes to flexing scope – to stay on time and budget, decisions need to be made about what requirements/features to drop. Whilst there may be specialist input into decision making, only the business can make those decisions as they understand what is important from a business perspective.