You're reading...
Agile/Scrum, Operational Research, Project Management

How to make your research and analytical projects more “agile” – 22 ideas

foggy_projects_wordcloudI run a 2-day Project Management skills workshop for economists, social science researchers, statisticians and OR people. We talk about agile approaches to managing projects to help reduce risks and improve the chances of successful delivery.

I’ve put together a checklist of 22 ideas to make this type of project more agile (structured around a 4-stage project lifecycle model):

Initiation:

  • Clearly define the research question – the broader it is, the more difficult it will be for the project to be “agile”
  • Prioritise the research objectives – use MoSCoW – engage end-users in this
  • Define how the results will be used with a User Story – “As a […role…], I want […an answer to…], so that I can […purpose…]
  • Identify the deadline for decision-making on option selection – protect that date & get it in key people’s diaries, early

Planning:

  • If possible, define a Minimum Viable Product – what’s the core analysis that must be done to meet the customer/user’s needs?
  • Pin down what’s out of scope and get this agreed with customers/users
  • Break the work into smaller time-boxes – e.g. weekly chunks
  • Book time with key resources early (e.g. QA, Peer Review) – get dates in their diaries
  • Identify external dependencies (e.g. for provision of third-party data) and ensure they know your requirements
  • Build a buffer at the end of the project (soft deadline)
  • Consider adding buffers at key milestones e.g. approval and decision points

Implementation:

  • For very short projects (less than 1 month) hold daily stand-ups (what did you do yesterday, any issues, what will you do today?)
  • For longer projects – decide what the shortest feedback loop time should be to keep things on track – the longer the gap, the bigger the risk of slippage
  • Start writing the report (at least an outline framework) before you do the analysis – decide what doesn’t need to wait until the end
  • Start writing-up the results as soon as they emerge
  • Share emerging results with key stakeholders (customers, users) – get their feedback on whether it meets their needs (you may be able to stop sooner, or may need to change direction)
  • Write-up and publish results in chunks (e.g. for particular demographic groups or for subsets of the research question)
  • Build “rough-cut” models or “proof of concept” models to share with customers & users, before building full models
  • Carry out mini “lessons learned” reviews during implementation – use these to shape remaining plans
  • Avoid multi-tasking – allocate dedicated chunks of time (minimum half-day blocks)

Close-out:

  • Carry out “lessons learned” reviews with the team and customers/users
  • Summarise key data to use when planning future projects (timescales, risks, resource constraints)
Advertisements

Discussion

Comments are closed.

Connect with Ian Seath

Find us on Facebook Improvement Skills Consulting Ltd. on LinkedIn Follow IanJSeath on Twitter

Archives

Copyright Notice

© Improvement Skills Consulting Ltd. and Ian Seath, 2007-19. Unauthorised use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Improvement Skills Consulting Ltd. and Ian Seath with appropriate and specific direction to the original content.

Advertisements
%d bloggers like this: