Projects & Project Management

A project is a change from BAU (Business As Usual).


Managing the change is Project Management.


  • Different responsibilities for managing compared to BAU
  • Provision and control of technical resources on project
  • Demonstrate control of work & that’s it’s justified
    • Meets the needs of the business
  • Continually tests justification


4 major areas of project management focus on

  • Features: the deliverables. The scope of the project
  • Quality. What makes its features fir for purpose/satisfactory to the organisation. The acceptance criteria
  • Time. How long to deliver
  • Cost. How much will the project cost


Other areas:

  • Risk. Threats to objectives of the project
  • Benefits. Payback/reward expected from investment in project


Project Management Models

(Big Design Up Front)  (Enough Design Up Front)



  • Depends on understanding requirements in detail
  • Performing detailed planning
  • Features (scope) & quality; fixed
  • Time & cost may drift to accommodate delays
  • Deadlines place quality under pressure
  • Quality can become eroded



  • Planning just before it is needed
  • Plan as we go along, accepting project will change as solution evolves
  • Incremental steps, checking with business to see what they want doing next



  • Proof that rewards (the benefits) outweigh cost of project
  • Business case identifies benefits promised (in a measurable format) compared against costs, timescales and risks
  • Allows Investment Appraisal to demonstrate if investment is sound


Business Case, comprises of:

  • Reason for change
  • Proposed solution
  • Expected benefits
  • Timescales
  • Costs
  • Risks
  • Investment Appraisal
  • Benefits Assessment, detailed in Benefits Realisation Plan


Planning the change:

  • What needs to be produced (the project management products)
  • Resources required to produce products
  • Costs, timescales
  • Schedule of activities



  • Breadth (what is covered)
  • Depth (level of detail)

Comparison of Traditional & Agile methods

Traditional project:

  • 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


Agile project:

  • 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.

DSDM Atern

This site focuses upon the DSDM (Dynamic Systems Development Model) Atern approach to Agile project management.


DSDM Atern*, one of a group of Project Management methodologies which sit under the umbrella term of Agile.


*(the name Atern was coined by the methodology creators and refers to the Artic Tern, a collaborative bird that can travel vast distances and epitomises many facets of the method which are natural ways of working e.g. prioritisation and collaboration.)

Lightweight approaches
Extreme Programming (XP)
Fuller Approaches (but still agile)
DSDM Atern
Agile Unified Process (AUP) 



Originally designed for software development, it has many uses where time and budget are of paramount importance & delivery time needs to be short.


Adopts an incremental approach to evolving solution through number of stages (called Increments in Atern).


Atern is described as Agile with rigour.


5 key techniques:

  1. MoSCoW
  2. Facilitated Workshops
  3. Timeboxing
  4. Iterative development
  5. Modelling


link to DSDM Atern Handbook

Agile Project Management

In the early stages the Project Manager creates a high level plan based on outline requirements and a high level view of the solution.


From there on the end product is created iteratively & incrementally. Each increment building on the output of previous increments. At the end of each stage, the outcome of that stage & experiences gained are to create a detailed plan for the next stage.


Detailed plans are created by team members, Not the Project Manager!
Within each stage the works in close collaboration with the business/customer to understand the detail of the next step to create and validate the evolving solution.


For the Project Manager, the old ‘command & control’ is replaced by a facilitative approach.
The Project Manager focuses on management of an empowered team, ensuring they have all they need to deliver, only stepping in when an exception is escalated from the team.


  • Focus on business outcome
  • Deliver on time, ensuring early ROI
  • Collaboration
  • Prioritised work according to business needs
  • Users accommodate change as part of fixed timescale
  • Quality is not compromised; not over/under engineered
  • Iterative lifecycle for the evolving solution that satisfies the project’s objectives
  • Timeboxes, with clearly specified outcomes leading to control for PM & team
  • Clearly defined roles
  • Work is divided into timeboxes with immovable deadlines & agreed outcomes



EDUF = Enough Design Up Front


Fixed time, budget and quality at Foundations phase, with contingency managed by flexing the features to be delivered in agreement with stakeholders in accordance with MoSCoW rules


MoSCoW and timeboxing ensure Minimum Useable Subset is guaranteed to be delivered on time and in budget.


Quality is fixed in because acceptance criteria is agreed before development commences.



Atern uses a high level Development Plan:

  • Divided into Increments
  • Defining how many development Timeboxes are needed to produce the requirements for each increment
  • With deployments where the Evolving Solution is integrated into normal business
  • Development Timeboxes, where development & production takes place
  • Planned in detail just before work commences


*Timebox = fixed amount of time


To benefit from experience, wherever possible, plans should be created just before they are needed!


Any project must be aligned to clearly defined strategic goals and focus upon early deliverables of real benefit to the business.


Key stakeholders must:

  • Understand the business objectives and be empowered and collaborate to deliver the right solution
  • Be prepared to deliver a fit-for-purpose solution
  • Be prepared to accept change is inevitable, as they understand more about the solution being developed
  • Accept that the solution will be delivered in agreed the timescale, according to the priorities set by the business



  • Vital stakeholders buy in to the philosophy
  • Working solution an agreed date
  • Should not expect 100%
  • Stakeholders drive what is important, for their business needs
  • Be open and clear about the philosophy & the way Atern delivers from the start
  • Be prepared for stakeholders initial concerns


In Atern projects, the majority of negotiation is around fine detail not major headlines.

8 Principles

Non adherence / compromising the principles undermines the philosophy and is considered a risk.


Discuss the principles at the start of the project & ensure buy-in.


Symbol Summary Description
1 Focus on business need Deliver what the business needs when it needs it. The true business priorities must be understood with a sound business case.

  • Understand business priorities
  • Establish business case
  • Seek continuous business sponsorship & commitment
  • Guarantee Minimum Usable Subset
2 Deliver on time Timeboxes are planned in advance and the timeframe set. The dates never change; features are varied depending on business priorities, in order to achieve the deadline.

  • Timebox the work
  • Focus on business priorities
  • Always hit deadlines
3 Collaborate Teams work in a spirit of active co-operation and commitment. Collaboration encourages understanding, speed and shared ownership. The teams must be empowered and include the business representatives.

  • Encourages increased understanding, greater speed & shared ownership
  • Involve right stakeholders at the right time
  • Ensure team members are empowered to make decisions
  • Actively involve business
  • Build a one team culture
  • Atern Business Visionary, Business Ambassador and Business Advisor roles bring appropriate subject matter experts into project to contribute to solution
  • Business analyst is responsible for facilitating high level collaboration between team members
  • Facilitated workshops enable stakeholders to share knowledge with the project team
4 Never compromise on quality A solution has to be “good enough”. The level of quality is set at the outset. Projects must test early and continuously and review constantly.

  • Level of quality is agreed at the start
  • Work is aimed at achieving that level, no more, no less
  • Solution has to be good enough
  • If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable
    • Ensure quality does not become a variable
    • Design, document and test appropriately
    • Build in quality by constant reviews
    • Test early & continuously
    • MoSCoW & timeboxing ensure testing is appropriate, without introducing unnecessary risks
5 Build incrementally from firm foundations Increments allow the business to take advantage of work before the final product is complete, encouraging stakeholder confidence and feedback.  This is based on doing just enough upfront analysis to proceed and accepting that detail emerges later.

  • EDUF (Enough design Up Front)
  • Incremental delivery
  • Increments deployed into operational use for early ROI
  • Strive for early delivery of business benefit where possible
  • Continually confirm correct solution being built
  • Formally re-assess priorities & project viability with each delivered increment
  • Implement this principle using Atern lifecycle
6 Develop Iteratively Accept that work is not always right first time. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.

  • EDUF (Enough Design Up Front)
  • Iterative approach on all projects
  • Build customer feedback into each iteration
  • Accept most detail emerges later rather than sooner
  • Embrace change, the right solution will not emerge without it
  • Be creative, experiment, learn, evolve
7 Communicate continuously & clearly Use facilitated workshops, daily standups, modeling, prototyping, presentations and encourage informal face-to-face communication.

  • Run daily stand-ups
  • Facilitated workshops
  • Rich communication techniques such as modelling & prototyping
  • Present instances if the evolving solution early & often
  • Keep documentation lean & timely
  • Manage stakeholder expectations throughout the project
  • Encourage informal face to face communication at all levels
8 Demonstrate control The team needs to be proactive when monitoring and controlling progress in line with Foundations Phase. They need to constantly evaluate the project viability based on the business objectives.

  • Monitor & control progress in line with foundation phase products, especially the business case
  • Use appropriate level of formality for tracking & reporting
  • Make plans & progress visible to all
  • Measure progress through focus on delivery of specialist products, rather than complicated activities
  • Manage pro-actively
  • Evaluate continuing project viability based on business objectives


ISF – Instrumental Success Factors:

  • Acceptance of Atern philosophy before starting work
  • Empowerment of SDT (Solution development Team)
  • Commitment from the business to provide a Business Ambassador & Business Advisor
  • Incremental delivery
  • Access by SDT to business roles (e.g. through colocation)
  • SDT stability
  • SDT skills
  • SDT size ~ 7 +/-2
  • Supportive commercial relationship


PAQ  (Project Approach Questionnaire) identifies & confirm level of achievement of above ISFs & to assess potential risk areas to be addressed. Typically completed during feasibility & re-assessed as part of foundations.


  • ISFs need constant monitoring, as they form the key risks to the project
  • Empowerment is two way
    • May need constant reinforcement & coaxing to make their own decisions
    • Daily standup will show whether there are risks here
  • Acceptance of the philosophy
  • Colocation. If unable room where all can come together from time to time. Give focus for the project
  • Large teams can be subdivided into smaller teams
  • Never compromise on business time. If they’re not committed why should you be?


Lifecycle is both iterative & incremental.


Atern integrates a PM lifecycle and a product development lifecycle into a single framework.


Each phase has objectives & pre-conditions, & delivers products that are used to assess progress.


Acceptance of products enables agreement project can move safely from one lifecycle phase to another.





1    Pre-Project Formalises a proposal for a project.

  • Describe the business problem to be solved
  • Identify the Business Sponsor & Business Visionary
  • Confirm project is in line with strategy
  • Scope, plan and resource feasibility phase
  • Output is a Terms of Reference


2    Feasibility Viability of project should be continually assessed, to ensure benefits outweigh costs

  • Establishes whether viable solution
  • Identify benefits
  • Outline possible approaches, including strategies for sourcing solution & project management
  • Describe organisational governance
  • State first cut estimates of timescale & costs
  • Plan & resource Foundations phase
  • Pre-conditions:
    • Terms of Reference must have been approved
    • Resources are available for feasibility
    • Business Visionary has sufficient time to help shape the project


3    Foundations Aimed at establishing firm & enduring foundations for project

  • Baseline high level requirements
  • Describe business processes to be supported by proposed solution
  • Identify information used, created & updated by proposed solution
  • Describe strategies for all aspects of solution deployment
  • Detail Business case
  • Start designing solution architecture & identifying physical / infrastructure elements of solution
  • Define technical implementation standards
  • Describe how quality will be assured
  • Establish appropriate governance & organisation for project
  • Describe solution development lifecycle, along with techniques to be applied in managing the project & for demonstrating & communicating progress
  • Pre-conditions:
    • Agreement of feasibility assessment (if created)


4    Exploration Iteratively & incrementally investigate detailed business requirements & translate them into a viable solution

  • Elaborate on requirements captured & baselined in PRL during Foundations
  • Explore full detail of business need & provide detailed requirements for evolving solution
  • To create functional solution that demonstrably meets needs of business
  • Give wider organisation early view of solution they will eventually operate, support and maintain
  • Evolve Business Area Definition, Systems Architecture Definition products from Foundations phase into models that describe how the solution works & how it supports all impacted business processes & systems
  • Pre-conditions:
    • Business, Solution & Management Foundations products have been collectively accepted
    • Environments (physical & technical) are in place to support the development of the solution


5    Engineering Iteratively & incrementally evolve the preliminary solution created during exploration to achieve full operational readiness

  • Refine evolving solution from Exploration phase to meet agreed acceptance criteria
  • Expand & refine products required to successfully operate & support solution in live operation
  • Pre-conditions:
    • Evolving solution from Exploration phase has been approved
      • Business Visionary has acknowledged features demonstrated are in line with vision
    • Environments are in place to support development of solution
    • All required personnel & stakeholders are engaged as required


6    Deployment Purpose is to get the solution into live use (/ready to ship)

  • Confirm ongoing performance & viability of project & re-plan as required
  • Deploy solution into live business environment
  • Train end users and/or provide documentation to support live operation in business environment
  • Train and/or provide documentation for operations and support staff responsible for supporting & maintaining technical aspects
  • Assess whether deployed solution is likely to enable delivery of intended business benefit described in Business Case
  • After final deployment:
    • Bring project to a close
    • Review overall project performance from technical and/or process and business perspective
  • Pre-conditions:
    • Deployable solution has been approved for deployment


7    Post-Project After last planned deployment (3 – 6 months later)

  • Assess whether the business benefits described in the business case have been achieved
  • Pre-conditions:
    • Solution has been successfully deployed

Roles and Responsibilities


Orange – Business

Blue – facilitate process aspects of the Project

Green – Technical development


Business Sponsor: must hold a sufficiently high position

  • Owns the Business Case
  • Ensures ongoing viability of project in line with the Business Case
  • Ensure funds & other resources are made available
  • Ensure decision making process for escalated project issues is effective and rapid
  • Responds rapidly to escalated issues


Business Visionary:

  • Owns wider implications of any change from organisational perspective
  • Defines the business vision for the project
  • Communicates & promotes business vision
  • Contributes to key requirements, design & review sessions
  • Approves changes to high level requirements in the PRL (Prioritised Requirements List)
  • Ensures collaboration across stakeholder business areas
  • Ensures business resources are available as needed
  • Promoting translation of business vision into working practice
  • Acting as final arbiter of any disagreements between team members


Project Manager:

  • Responsible for delivery of the solution
  • Managing the working environment in which the solution is evolving
  • Communicating with Senior Management with frequency & formality they deem necessary
  • High level project planning & scheduling, but not detailed task planning
  • Monitoring progress against the baselined project plans
  • Managing risk & issues as they arise, escalating to senior business / technical roles as required
  • Managing overall configuration of the project
  • Motivating teams to meet their objectives
  • Managing business involvement with SDTs
  • Resourcing Specialist Roles as required
  • Handling problems escalated from SDTs
  • Coaching SDTs when handling difficult situations
  • PM needs to protect SDT from Project Board to allow them to deliver within their Timebox; keep their velocity
  • Needs to ensure that the SDT know their boundaries -> get on with their job
  • Needs to clarify roles at start


Tech Coordinator: Design authority

  • Agrees & control tech architecture
  • Determine tech environments
  • Advise on & co-ordinating each team’s technical activities
  • Identifying & owning architectural & other technical based risk, escalating to Project Manager
  • Ensuring non-functional requirements are achievable & met
  • Ensuring adherence to appropriate standards of tech best practice
  • Controlling technical configuration of the solution
  • Managing technical aspects of the transition of solution into live use
  • Resolving technical differences between technical team members


Solution Development Team: Empowered to make decisions on a d2d basis

  • Team leader
    • Reports to Project Manager
    • Ensures SDT functions as a whole to meet its objectives
    • Plans & co-ordinates all aspects of product delivery at the detailed level
    • Leadership rather than a management role
    • Ideally elected by peers


  • Business Ambassador
    • Provides business related info from those ultimately using the solution
    • Provides business perspective of solutions fitness for purpose
    • Guides the evolution of the solution
    • Responsible for day to day communication between the project and the business


  • Business Analyst
    • Focuses on relationship between business & technical roles
    • Ensures accurate & decisive direction  to SDT on day to day basis
    • Ensures business needs are analysed & reflected in guidance team needs to generate solution


  • Solution Developer
    • Interprets business requirements and translates them into deployable solution, that meets functional & non-functional needs
    • Ideally allocated full time
    • Otherwise first priority = risk


  • Solution Tester
    • Performs testing in accordance with Tech Testing Strategy throughout project


  • Business Advisor
    • Often a peer of ambassador
    • Provide specific & specialist input to solution development / testing
    • Normally will be an intended user or beneficiary of the solution


  • Technical Advisor
    • Provides specific & specialist technical input:
      • Requirements, deign & review sessions
      • Operational perspective for day to day decisions
      • Operational or support scenarios to help define & test the solution
      • Assurance that the solution is evolving correctly
      • Operational acceptance testing
      • Development of support documentation
      • Training of operations & support staff


Workshop Facilitator

  • Responsible for managing the workshop process
  • Catalyst for preparation & communication
  • Responsible for context of workshop, not content
  • Should be independent of outcome to be achieved in workshop


DSDM Coach

  • Helps team members get the most out of the approach
  • Ideally certified as DSDM Coach, to ensure their competence has been independently validated


Atern is a product (project management speak for deliverables) based approach, that uses delivery of the appropriate products to demonstrate progress - More effective that simple progress reports!


Missing products highlight potential risk, since the product set identifies what needs to be in place to allow a project to safely move forward.


Each phase of the lifecycle formally has products although not all are required and will depend on the project.



Pre-project formalise organisation’s proposal & place in context of the organisation’s other work

  • ToR, contains brief outline of the business need & objectives & scope of project to meet the need
  • Should be short & sharp
  • Scope Plan & resource next phase (Feasibility)


Feasibility: Determines if project is worthwhile, both technically (products can be built) & for the business (project contributes to strategic aims of the organisation & brings satisfactory benefit

  • Creates: Feasibility Assessment (is project worthwhile & doable), includes statement of
    • Outline biz case
    • Outline solution
    • Optional feasibility prototype
  • Outline plan
    • Overview of project based on PAQ
    • Approach to be adopted
    • Likely profile of resources required
    • Description of facilities & tools required to support iterative development process
    • Organisational structure & process for governance
    • Analysis of Risks & Issues impacting on feasibility of project
    • Outline schedule
    • Detailed plan for Foundations phase


Foundations: Aim is to establish firm & enduring foundations for project so the 3 essential perspectives of Business, solution (technical) & (project) management are satisfied that the project is well formed & it’s aims achievable (i.e. it can create what is needed to give the benefits wanted & that the project can be correctly managed).

Planning is high level; detail is provided by the solution development team when they plan their timeboxes.

Products created include:

  • Business foundations: Information & justification for project from a business perspective such as business vision & business case.
  • Management Foundations:
    • Governance & Organisational aspects of project
  • Solutions Foundations:
    • Business Area Definition
    • System Architecture Definition
    • Development Approach Definition
    • Solution Prototype
  • Prioritised Requirements List
    • High level list of requirements that need to be addressed to meet the business case
  • Delivery Control Pack:
    • Control docs & logs which allow the project to be monitored & controlled, typically:
      • Risks & Issue log
      • Change Control records
      • Periodic reports about project progress
  • Delivery Plan:
    • High level schedule of timeboxes, resources & activities covering the development & deployment of the Evolving Solution


Exploration & Engineering, often referred to as Development Timeboxes & combines to take the evolving solution to a point where it is possible to deploy the solution into a production environment. It may not be complete, but should be solid & workable.

May continue to evolve the solution by going through additional cycles of Exploration & Engineering.


Exploration, concerned with putting together required functionality for that part of the project (called an Increment), at end of Exploration phase we have a viable solution which demonstrates the full functionality needed. Does not have to be deployable in terms of robustness/scalability, this comes in the next phase Engineering


Engineering takes the viable solution & makes it deployable.

It is made stable & capable of handling the required work load, for example.


Each Exploration & Engineering phase sits in a Timebox & has rigid start and end dates. Products include:

  • Evolving Solution
  • Solutions Assessment Pack: Collection of items used to prove the evolving solution is being developed to meet the quality expected of it during this Timebox & consists of:
    • Solution Review Records
    • Business Testing Pack
    • Technical Testing Pack
  • Timebox plan: Plan for development Timebox
  • Timebox review record: produced & updated at the reviews that take place during a Timebox; describe what has been achieved to date plus provide source of feedback to the project
  • Deployment plan: detailed plan for the deployment phase which follows a cycle of development timeboxes
  • Benefits Realisation Plan


Deployment, focussed on getting the evolving solution into live use by implementing the deployment Plan from Exploration & Engineering

  • Concerns more than just bolting something into the business
  • Deals with documentation and training
  • Likelihood of solution to provide expected benefit is considered
  • Acts as a key review point, allowing next step of the project to be considered
  • Products include:
    • Project review report: updated at end of each deployment & should provide information to help assess the state of the Evolving Solution & benefits it will provide at this stage of the project. It contains:Project review report
      • Increment Summary
      • Benefits Enablement Summary
      • End of Project Assessment


Post-Project only occurs after the last deployment

  • Consists of performing Benefit Assessment examining the business value actually earned by the project
  • Typically 3 – 6 months after last deployment

MoSCoW Prioritisation

List of Business Requirements created by the business, which is then prioritised into a PRL (Prioritised Requirements List).


  • Agree what the priorities mean early in the project
  • Use all the priorities
  • Challenge Must haves
  • Control % of Must Haves. Target = 60%
    • Above 60% decreases predictability and risk of failure increases
  • Prioritise everything – helps concept become ingrained


  • Must haves
    • Minimum Usable Subset
    • Cannot deliver without this
    • No point delivering on target date without this
    • Not legal without it
    • Unsafe without it
    • Cannot deliver the Business Case without it
  • Should haves
    • Important but not vital
    • May be painful to leave out, but solution is still viable
    • May need some kind of workaround
  • Could haves
    • Wanted / desirable but less important
    • Less impact if left out (compare with a should have)
  • Won’t have (this time)
    • Agreed these requirements will not be delivered
    • Recorded in PRL where they help clarify scope of project, & avoid being  re-introduced via ‘back door’ at a later date

Iterative Development

Process where delivery of a product results from repeated cycle of development activity.


Each execution of the cycle yields a result successively closer to desired outcome.



  • Identify what they need to achiever in this iteration
  • Plan how they are going to do it
  • Evolve the products in question in accordance with their plan
  • Review the outcome with a view to determining whether another iteration is required


Control needs to demonstrated, & recommends using:

  • Timebox control; recommends  three iterations: Investigation, Refinement, Consolidation
  • Timebox Review Records; which should be kept under formal configuration management to provide audit trail of how product evolved
  • Daily standups. Brief. Discuss progress & what to do if anything is blocking progress
  • Solution Review Records (optional), form basis for tracking issues, also need CM 
  • SDT, provided they can demonstrate control,  are expected to left to get on with their work.
  • Management by exception
  • Solution Foundations with agreed scope & priorities, & properly defined Acceptance Criteria should form basis for control


Significant benefits in making ideas, situations and options visible.


Can range from informal models (post it notes on a table) to very detailed complex models using specific notation.


Emphasis on ensuring models enhance communication.


Should be as clearly understood by intended audience as creators.


  • Why
Rationale, ends and means
  • Where
  • Who
People & Responsibilities
  • What
Data & Relationships
  • When
Events, time & scheduling
  • How
Processes & Outputs


In time management, timeboxing allocates a fixed time period, called a time box, to each planned activity.


A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal. Rather than allow work to continue until the goal is reached, and evaluating the time taken, the timebox approach consists of stopping work when the time limit is reached and evaluating what was accomplished.


  • Encourage SDT to finish on time by prioritising, rather than letting Timebox expand
  • Ensure Timebox has correct proportion of Musts, Shoulds & Coulds
  • Check progress by daily standups
  • Build environment of trust & no-blame
  • Ensure Timebox kick-off involves right people
  • Ensure Acceptance Criteria are clear, & clarified further during Investigation
  • Ensure key Risks are identified at Kick-off & monitored during the Timebox
  • Ensure close-out also performs a (retrospective) review of learning points to feed into future timeboxes
  • Typically 2-4 (exceptionally 6) weeks
  • Timebox plan
    • Created by team
    • MoSCoW
    • Milestone dates
    • RnRs
    • Deliverables



Kick off

  • Agree Timebox scope & MoSCoW
  • Ensure SDT understand objectives & accept them as realistic
  • Short session 1-3 hours


  • Investigate work to be done, including agreement on deliverables & quantitative measures that will prove success
  • 10-20% of timebox


  • Work on the solution in line with MoSCoW
  • 60-80% of timebox


  • Finish, ensuring output fit for purpose against Acceptance Criteria
  • Start planning for next timebox
  • 10-20% of timebox

Close Out

  • Formal acceptance of deliverables by Biz Visionary & Tech Co-ord
  • 1-3 hours


Daily Standup

  • Normally run by Team Leader, is opportunity to understand progress against objectives at detailed level & expose issues
  • Attended by all SDT
  • Strict format
    • Each member describes what they’ve done since last standup
    • What they plan to do
    • Any problems, Risks or Issues, slowing progress
  • Short fixed duration
    • No longer than 15mins
    • 2mins per member

Agile Manifesto

Manifesto for Agile Software Development


We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:


  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more.


Principles behind the Agile Manifesto


We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  1. Welcome changing requirements, even in late development. Agile processes harness change for the customer's competitive advantage.
  1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  1. Business people and developers must work together daily throughout the project.
  1. Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  1. Working software is the primary measure of progress.
  1. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace pace indefinitely.
  1. Continuous attention to technical excellence and good design enhances agility.
  1. Simplicity - The art of maximising the amount of work not done - is essential.
  1. The best architectures, requirements and designs emerge from self-organising teams.
  1. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.