DotGov Pipeline Development
What is the problem?
Hackney’s problem Background What did we do? Highlight reports required but compliance low ● RAG did not reflect status of the project ● Monthly meeting to discuss our pipeline ● Poor user experience reviewing highlight reports ● Reviewed existing SAAS solutions ● ICT Management lacked the MI necessary to review ● Interviewed and spoke to external organisations ● portfolio. Suppliers unable to engage with Hackney and lacked ● insight into priorities And developed…. A Trello board Procurement would lack understanding of wider context ● SMEs confidence in prioritising and submitting bids ● https://trello.com/b/D2JEsGb4/ict-project-board
Hackney’s problem What did we learn? -Benefitted from all -Easy to understand project information in overview of projects one place -Visibility of timescales -Signposting to project -Still required a deeper -Common naming assets conventions understanding of -Required reporting portfolio beyond the life of a project -View ICT projects outside their portfolio -Alerted when key things changed Delivery Manager Directors and Heads of Service ICT Management
Hackney’s problem What did we learn? -Valued being able to see what was emerging -Clear pipeline of the - Didn’t engage with and prioritised bids projects that related to the Alpha but needed their work accordingly signposting (through social media) to become aware of relevant projects that Hackney was doing Colleagues Other public bodies Suppliers
Hackney’s problem Our hypotheses Pipeline should prompt further conversations rather than replace them Pipeline should be the ‘single repository of truth’ rather than one of a number of tools Pipeline should enable users to subscribe for updates to a particular project If Pipeline holds the least possible information then it will remain flexible to the needs of individual projects and teams If Pipeline does not enable customisation for organisational sub-structures (eg council directorates) then it will be of limited value outside one organisation
What functions would a light touch project reporting tool provide?
What Hackney did next...
Project brief CLARITY OF PURPOSE “To build a clear and consistent way of reporting and sharing the status and details of projects to enable collaborative working within local authority and public sector organisations”
Research approach
Research approach REVIEWED PIPELINE CONDUCTED WORKSHOP BUILT PROTOTYPE Reviewed core capabilities of Reviewed existing reporting methods Built the tool in dev the existing tool Collated user needs and pains Iteratively tested it with users Discussed features and functionality Added to and groomed the backlog for pipeline BRIEF PLANNED WORKSHOP ANALYSED RESEARCH PLAYED IT BACK Kick-off meeting Agreed objectives Analysed workshop data Show & Tell Feedback and iterate Drafted research questions Iterated user needs Agreed plan on next steps Prioritised user needs for build
Who’s involved?
Power/interest stakeholder grid Mapping of stakeholders relative to their power in decision-making and their interest in the project. This was developed in a workshop with the core stakeholders closest to the project. Keep satisfied Monitor closely ● Service boards ● Lead user researcher ● Local government commentators ● Relationship managers ● Product owner ● Hackney DMT ● Hackney delivery managers POWER Monitor loosely Keep informed ● MHCLG ● Suppliers ● Other local authorities ● Other Hackney user researchers ● IT teams & senior leaders ● Service Assessment Team members ● Central government colleagues ● Hackney senior leaders / Mayor ● Local Government Association (LGA) ● Mayor of London Office ● Open source devs INTEREST
Stakeholders and users ADMINISTRATORS are the system users WATCHERS access information through who manage the permissions of all other users. CONTRIBUTORS are members of projects. the system but do not have permissions to add The owners of projects are automatically They can add, edit and remove information / edit any information. They use the system on allocated administrator status to be able to related to the project. Contributor permissions an interest-only-basis to get project create projects and manage the members under allow contributions to only the projects they are information / updates / changes. these projects. listed as members on. CORE CAPABILITIES CORE CAPABILITIES CORE CAPABILITIES ● Create, archive, and close ● Add, edit and remove ● View projects and projects information to projects related information ● Add members to projects they are members of
What are their needs?
What are their pains? Though great work was There are data protection concerns The framework could done, the platform has and it is not clear how much and benefit from being not evolved since 2014 what level of information should be updated shared Project information is outdated or incomplete and filling out the tool may cause a duplicate effort with existing siloed council tools Platform not widely adopted by other councils The platform could be better promoted to encourage greater uptake and value
What do they need? Wide uptake of the platform by Ongoing evolution To view projects open of the platform with both internal and external users for collaboration, and - Hackney and other councils and changing needs / contact details of the capabilities local authorities team members Control over the permissions / access of users To get notifications when projects are created / updated / changed Define the minimum required inputs for the platform to be valuable without being To view projects and time-consuming key project information
What content do they want? NAMES OF IMPORTANT FIELDS ● ● ● ● ● ● ● ● ● ●
What have we done?
The first iteration
Testing and feedback “I’d �i�� � ta� �l��� w�e�� t�� si�� �� t�e ��r� re���c�� h�� of��� t�e ��g �� u��d.” “Tag� �h���� be � pa�� of ��� se���h ��oc���” “I wo��� l��e p�e��c���e t��� , w�i�h ge����te ���s ���vi����y u��� b� ��he� p�o��c�� in ����r o� �r���e�c� ”
“Bas�� �� m� �ro���t�, I'd �a�t �� ��e t���g� I wo��� c��a�� �n a ���j��� b�i�� s��� as o�t���es, go���, li�� t� ���um��� re����to��/gi���b/s�a�k ���n���, et�” Den��� R “Wha� �y��� �f co���b��a���n ar� �� lo����g �o�? Can �� ��n�i��r � s�e�t��� t�a� w���� ra��� f��� ju�� d����s�i�g �� s�a��n� ��e�s, al� �h� ��� to ���r�� fu���n�?” Cat� �
The second iteration “ Sig����ca�� im���v��e�t in ��� lo�� ��d �e��” The ‘Ad� a �r����t’ pa�� �� mu�� “ mo�� us�� �r�e��l�” Bre���r���s a�� lo����l an� �� t�� �ig�� “ or���”...“I li�� �h� �i�k to ��� G�� p�o��c� p�a��s”
“ Nic� ��� c�e�� v��u��s ” Ric���d S “The ta�� ar� de����te�� us���� - I li�� �h�� a ��t” Em�a H
What are the barriers to take up?
What’s next?
Building on the good feedback and momentum Deliver the Interface with User Squeeze out the Support the tool for prioritised backlog Research Library value of the work the benefit of users Sprint by sprint, Linking the projects The tool is only Agree how the tool is prioritisation, build, test raised on the tool to the valuable if it is used by supported (run, research conducted as real people improve) c.3-4 weeks of further part of their progression development already in Promote Provision this the backlog Go broader to include collaboration across other project networks (e.g. other components (e.g. boroughs, GLA, architecture, policy) LocalGovDigital Slack)
Examples from the backlog Building out a feed that will keep people informed, and make the tool sticky See explanatory text with a sentence explaining what the field should be filled with Automated workflow that keeps information fresh - like moving things from concept to the archive after X months of inactivity
https://pipeline.localgov.digital/ LocalGovDigital Slack: #pipeline-dev nicholas.teeman@hackney.gov.uk @Nic_Teeman
Recommend
More recommend
