-
Notifications
You must be signed in to change notification settings - Fork 0
Top risks to project
Harry Moss edited this page Mar 14, 2023
·
3 revisions
| rank this fortnight | rank last fortnight | weeks* on list | risk | risk resolution |
|---|---|---|---|---|
| 1 | 2 | 2 | DSH development environment restricts techincal choices | Initial prototype to ensure that packaging tools and required libraries all work with DSH. Deploying a development environment on the DSH instructions to be added to the repository. |
| 2 | 3 | 2 | unknown bugs in REDCap exported data | Ensure that tool runs correctly on previous years, will need to define final input data and expected output |
| 3 | 1 | 2 | DSH or REDCap access for developers not given in project timeframe | DSH inductions now complete, breaking up tasks that don't require DSH access, create mock data to allow for test driven development. REDCap runthrough useful? |
| 4 | 4 | 2 | creeping requirements | review of requirements every 2 weeks, order by value and push down nice to haves until all high priority issues are completed. Invite Gemma and Teresa to review project board |
| 5 | 5 | 2 | no visibility on progress | visible project board, ideally write code in public repository and under an open source license. Hours used and project documentation in the wiki |
| 6 | 6 | 2 | developers goldplating code, and not producing more valuable items | Tracer-bullet development to ensure that simple end-to-end case has viable structure before expanding will reduce risk of over engineering. Keep Gemma and Teresa involved in project board review |
| 7 | 7 | 2 | released software has low quality | disciplined development practices (version control, review, tests and CI). |
* defined as a 'work week' where developers are 'on' the project
None agreed as resolved so far!