Ready, set, launch: implementation and delivery for your lab’s project
www.nesta.org.uk/blog/ready-set-launch-implementation-and-delivery-for-your-labs-project/
www.nesta.org.uk/blog/ready-set-launch-implementation-and-delivery-for-your-labs-project/
This month’s issue of Tech4Labs offers some helpful tips and tools to help your lab plan for the roadblocks, pivots and iterations you’ll likely encounter as you get your lab project up and running.
Earlier this month at LabWorks in London, a group of public sector innovation experts considered whether the ideal public sector innovation lab (PSI lab) model is the x-team or the i-team.
x-team: A team mandated with creating a culture of open innovation across an organisation or wider public sector
i-team: A team that directly engages with building and diffusing innovative solutions on behalf of other government agencies
In practice they suggested this is a 'false dichotomy' - most PSI labs aim for more of a ‘blended approach’: developing innovative solutions while working to unlock the wider organisation’s innovative capacity.
Few labs are responsible for direct public service delivery themselves. Instead, they tend to work closely with agencies across government, and with external partners, to fund or support new solutions, with implementation tasked to the relevant government partner.
So whether the form of the solutions being developed by the lab are programmes (e.g. Nesta Innovation Lab’s Digital Education programme), products (e.g. a new website or an idea generation app for public sector staff) or services (e.g. Challenge.gov), implementation and delivery will mean something slightly different for the lab. Given the highly collaborative multi-stakeholder approach adopted by various labs, delivery and implementation will need to allow enough space for relationship management, communication and tight project management techniques.
Having read past Tech4Labs issues, you’ll hopefully recognise that we embrace fallibility as a “feature” rather than a “bug” of labs. Unlike traditional bureaucracies where experimentation is frowned upon and failure unthinkable, labs build in experimentation as a permanent fixture and plan for it. In this month's issue we’ll turn to tips and tools coming from fields such as product development to help your Lab plan for the roadblocks, pivots and iterations you’ll likely encounter as you get your lab projects up and running.
Launching a project involves numerous resources and requires coordination, particularly given a lot of the people tasked with delivery won’t work inside your team. Depending on the nature of the project being delivered, a few teams that usually get involved include: project team, engineering team, legal team, finance team, PR & marketing team, customer support team, etc. The most successful PSI labs identify relevant external partners early on, plan for budgets, legal changes, and wherever possible include named staff who’ll be responsible for delivery post-launch. Work with everyone involved to create a baseline of some sort - this will pay off down the line when you're thinking about the project’s impact.
For labs, one of the biggest challenges is coordinating all these stakeholders, ensuring the right amount of information is being shared, and fostering a culture of learning from the things that don’t go perfectly. Create a dedicated mailing list for the various stakeholders and schedule regular "cross functional" team meetings. Feel free to leverage your usual tools for such tasks, e.g. Google Apps, Microsoft Exchange, etc.
Some project management tools can also be useful, especially when they integrate nicely with productivity tools you already use, e.g. Asana, Flow, BaseCamp, Producteev, Trello. For more software-centric projects and products, GitHub (using GitHub issues) or JIRA are useful. A simple Google Doc can effectively share information among team members (using @mention inside comments can bring issues to a specific person’s attention), discussing them and resolving them ahead of the launch. Before settling on a specific tool be sure all stakeholders are on board - it may be helpful to assess which tools they’re already familiar with and their willingness to use new tools.
Keeping track of these communications, documents and discussions through the project development process can be a good opportunity to deepen your institutional learning, e.g. to compare the current project with others, provide project estimates, or in certain cases to resolve legal issues.
Every product is different and planning is more an art than a science, and documentation from past projects launched may help "guestimate" development time.
Software engineering has developed various methodologies for planning development, e.g. Scrum, SEMAT [4] with various artefacts such as planning poker cards (to let the project team estimate collaboratively the time a given task will take) or Alpha State Cards. Tools like Pivotal Tracker and various similar products incorporate such ideas. Check them out and see if they are applicable to your situation. You can for instance take some inspiration from planning poker cards so end users can vote for features they want to see in your product. You can think of doing "participatory budgeting, but for your project".
The most common and generic tool for planning is a Gantt chart, which "illustrates the start and finish dates of the terminal elements and summary elements of a project" and identifies dependencies between elements. A Gantt chart is commonly used to represent not just the theoretical planning (assuming everything goes as planned) but also the actual execution.
There are lot of tools to produce Gantt charts. Make sure you pick the one that fits your needs, especially if collaboration is critical. Microsoft Project and OmniPlan let you define tasks, resources and allocations. Check here for some free alternatives. A regular spreadsheet (Excel, Google Sheets) is also a perfectly valid option to represent your project dependencies.
There are many different kinds of launches. A big distinction to make is between launching something new and launching a feature for something that already exists. The former tends to be more challenging as you are breaking new ground. For a ‘feature launch’, you can usually reuse processes that were put in place when the programme, product or service was first launched.
Your lab project launch can take many forms, depending on the goal, the resources and the risks you are willing to take. We enumerate a few scenarios we have seen in practice:
Type of launch What it is When to use it silent launch you launch but don't tell anyone(a) you are concerned that a big launch will mean your product/service will be unable to cope with demand
(b) you don't want to switch on the PR machine yet
(c) you want deniability if the launch is not as successful as expected
invitation only only users with an invite can access the product(a) you want to limit the number of users
(b) you want to select your user population
(c) you artificially want to create scarcity and interest for your product
waiting list only the first N users can access the service; then they have to wait Same as before quid pro quo you ask users to do something for you in order to access the product, e.g. make a tweet, invite friends, etc.(a) you care about viral growth and leverage users to do to the work for you
(b) this could be a particularly useful strategy where a lab wants to overcome challenges around achieving scale
big event you combine your launch with a big event (a) you can leverage an existing event where your project fits well within the event and eventgoers are likely to try your product pre-announce you announce your product before it is ready(a) you want to build expectation
(b) you want a critical mass of users for when your product is ready
(c) you are interested in getting some early feedback in order to make some changes to your product
You may find it useful to create a checklist for your lab project launch[3]. Check these resources for inspiration [1, 6, 8]. Combining this with a spreadsheet or any task management or to-do list tool and you should be able to share and manage the list, e.g. Remember The Milk, Toodledo, Wunderlist, Google Keep.
Don’t just wait for the project to go wrong to do a post-mortem. A pre-mortem [5, 7] which lists everything that could go wrong, might be appropriate. For each item, the lab and wider delivery team should have a solution for it, with responsibilities clearly delegated to assigned ‘owners’.
Legal. Make sure you have a good legal cover, including trademark, rights for the material you use (e.g. pictures), privacy statements. Engage your legal team early on to make sure they’re clear on all aspects and aims of your project.
PR. Work with your PR team to make sure you have both proactive and reactive messaging ready and pre-approved (use your pre-mortem as an opportunity to pre-empt this).
Testing. We’ve written in past issues about the importance of carrying out user testing on your lab projects as early on in the project development process as possible - and this is just as relevant whether your lab outputs are online or offline. Avoid a situation where your first interaction with the end user is the day of your launch.
If your product is a piece of software, you’ll also need to make sure you have done enough software testing. Native apps need to be tested on the range of phones being targeted. Test responsive apps on various form factors (phone, phablet, tablet, laptop, desktop, etc.) and various web browsers (Chrome, Firefox, Safari, Internet Explorer, etc.). Do some load testing for cloud services to test for capacity ahead of time, with tools like The Grinder, Gatling, Tsung, JMeter or Locust. (Lest you forget what happened with Healthcare.gov!) Use a monitoring service that makes sure your service is up and alerts you when it is not (check here for a comparison).
Miscellaneous. Make sure you anticipate issues beyond your control and plan for them. For instance, acquiring an internet domain, setting a SSL certificate, waiting on executive sign off from a key external stakeholder or planning through logistics of a physical event. Consider leveraging other communities to learn about best launch practices, e.g. Kickstarter [2].
As mentioned above, we use the term ‘launch’ in a very broad sense. Launching can include: putting a mobile app on the App Store, pushing a new version of a paper form to ask for a business permit, deploying a new process to claim social benefits, organising a one-day event for participatory budgeting, etc.
Depending on your goals, it may be wise to pick your launch date(s) carefully - avoiding big events unless you’re going with a silent launch. Plan the sequencing of your launch - especially if your launch project involves multiple components. For instance, if your project involves a website and a mobile app, you’ll need to hold off launching the the site until the mobile app is ready. Boomerang and scheduled tweets (e.g. via SproutSocial, HootSuite) are good tools to coordinate social media, like sending notifications or invitations that will be part of your launch. Most cloud services make it very easy to bring servers up and down and change the configuration of a given service. In certain cases, a ‘war room’ (physical or virtual) might be a good tactic.
A project launch is a major milestone. Don't forget to enjoy the moment and celebrate with everyone involved. Remember to document aspects of the launch. Not every project can afford a film crew to capture your launch, but camera phone pictures, screenshots, etc. are a good way to record the launch as it unfolds. You may find it useful to capture and share related social media activity using a tool like Storify.
Remember iterations and continuous improvements are central to the lab approach - and this will apply regardless of whether your launch is limited in time (a day, a week) or longer term. Monitoring and data gathering on how your programme, product or service is doing are key. HEART metrics mentioned in a previous column are a good starting point. Customer surveys (see TechLabs issue #1) or more in-depth customer feedback sessions can help you access user experiences.
A post-mortem [9] is a good way to take a step back and look at what worked well and what did not, gathering lessons learned as you go. This is a good opportunity to continue improving the process for the next iteration and your next launch.
Maintaining good communication with key project stakeholders beyond implementation is crucial. Regular multi-stakeholder check-ins can quickly flag potential issues before they become major, and can prevent the lab being seen as a one-off consultancy. Your project plan should thus reflect post-launch support (considering sustainability both in terms of cost structure and knowledge transfer).
Building, delivering and launching a project is a major milestone for your lab - whether it's your team doing the delivering or not.
"Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning." Sir Winston Churchill.
To paraphrase Churchill, it is not the end but rather the end of the beginning, because for the first time real users will interact with your creation. This presents one of the greatest opportunities to assess what worked, and vitally, what didn’t. Use this opportunity to communicate the added value and culture of your lab by being open about this process, recording your outputs as well as the outcomes . You may want to consider repurposing all this into an outward-facing blog or short report to codify your lab’s learning, remembering the cardinal lab rule - fallibility is a strong possibility. For every approach that doesn't work you’re gathering important insights that can support further efforts towards the right solution.
To continue the conversation, and to offer feedback and suggestions on the tools above:
Share your comments
On Twitter using #Tech4Labs
Special thanks to Julia Root for comments on early versions of this draft.
Resources[1] 14 Essential Elements of a Flawless Product Launch: http://blog.hubspot.com/marketing/elements-flawless-product-launch-li.
[2] 6 Tips From Kickstarter on How to Run a Successful Crowdfunding Campaign: 2014. http://www.entrepreneur.com/article/234707.
[3] Gawande, A. 2011. The Checklist Manifesto: How to Get Things Right. Picador.
[6] Launch Checklist: http://100startup.com/resources/launch-checklist.pdf.
[7] Tervooren, T. The Pre-Mortem: A Simple Technique To Save Any Project From Failure.
[8] The 40 Step Checklist for a Highly Successful Launch: http://paidtoexist.com/launch-checklist/.
[9] The Keys to a Successful Postmortem: http://www.clickz.com/clickz/column/1692002/the-keys-successful-postmortem.
Photo Credit: jurvetson via Compfight cc
<!--/*--><![CDATA[/* ><!--*/ #mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ /*--><!]]>*/
* indicates required
Email Address *
First Name
Last Name
Organisation
Position
Country
Email Format
