Ask IRC & KnowledgePoint

Avoiding the one-way conversation: from Bell to Metcalfe

04 Mar 13

Tim Kent, KnowledgePoint Project Manager

How do you launch a service like KnowledgePoint, when so much value is dependent on content developed by users? 

And how do you do launch an innovation when you don’t know how its users – the very people who will create the content – will in fact use it? 

Two main processes are taking place at the moment that address these questions.  Firstly, the KnowledgePoint partners are pursuing early implementation of KnowledgePoint within their own organisations, and secondly we are preparing for extensive piloting to learn more about real-life usage of the system. 

Here I expand on these activities with a view to answering these first questions about launch. 

Early organisational implementation
KnowledgePoint’s approach since initial prototype development has been ‘test early, test often’.  The reason for this has been a deep curiosity about how users will respond – though it does also match responsive approaches to software development.  In short, we have been trying not to go too far before testing our thinking partly because it’s good practice -- and partly because we can’t wait to find out! 

While our full implementation programme is not due to start for some months, the partners are already keen to begin using KnowledgePoint.  There are great benefits to beginning this process early. 

It means we can’t hide behind a distant ‘big launch’ date – we have to make sure we are getting things right, right now.  And we also begin to set out a repeatable process for implementing KnowledgePoint which we hope will benefit other organisations across the sector. 

The first stage we are seeing is to upload past technical enquiry information.  This instantly brings high quality content to the site.  So simply by beginning this process, new organisational users immediately bring value to the platform. 

Many of the partners have begun this process – and in the case of EngineerAid and IRC, they are currently setting about a full-scale transfer.  The other partners have equally ambitious programmes in the pipeline.

This is a really great development.  It means KnowledgePoint partners are already moving a key business function from operating mostly within their own walls to a strategy of working as a group, sharing information, and pooling resources.  We hope to see many other individuals and organisations taking part as we build a fantastic collective resource. 

Piloting
The KnowledgePoint platform has so far been developed to the proof-of-concept-level. In this current development phase, it is necessary to ensure that the platform and processes are set for the demanding environments facing humanitarian and development actors.

At the core of this process is a phase of thematic piloting with feedback into process and software development. 

Key outcomes of the process are to understand platform successes and failures, to build awareness among partner organisations and communities, and to deliver core system improvements.
The four thematic areas that have been identified as critical to test during the development phase pilot projects include:
(i) availability and usability in low-bandwidth settings;
(ii) provision of TSS where security concerns reduce access by personnel;
(iii) promotion of improved and direct access to expertise for a wide range of local and international stakeholders; and
(iv) rapid response and establishing good practice in an emergency setting in near real time.  

We will be using a challenging, peer-reviewed process for developing pilot plans.  Issues we will look to address include:
• Does the pilot have potential to scale and be replicated?
• By piloting, what will we know about KnowledgePoint that will help to understand its value to users?
• How will we measure the successes and failures of the KnowledgePoint system within the pilot to assist our learning?
• How will the pilot be conducted to maximise value for money?
• How will we design to minimise the burden of supporting pilot studies for stakeholders engaged in development and humanitarian operations? 

Wrapping up…

So to return to the original questions, how do you launch a system based on user-generated content, before you have users and before you have content?  And how do you make sure your innovation doesn’t drift away from these prospective users? 

In the title, I mention not just Bell but also Metcalfe. Alexander Graham Bell didn’t invent the telephone… he invented two telephones.  Sorry, it’s pointing out the obvious, but it does touch on an important principle: when people try to create a network from scratch, there is a danger it can become a one-way conversation. 

Robert Metcalfe suggested that the value of a network is proportional to the square of the number using that network.  The quantitative part of the equation – the ‘number’ of users – often receives early focus.  But equally significant is the qualifier – the number ‘using’ the network.  It’s easy to think the value is in member numbers, and then go for the big launch approach.  But how are these signed- up users engaging with the platform?  What utility are they getting from it?  The power, figuratively and mathematically, of the network – it’s value and therefore potential for scalability and sustainability – is as much dependent on this qualitative side, as the quantitative element of user numbers. 

For these reasons, we have placed much emphasis on pilots and initial, small-scale implementations so we can test as we go, seeding the site with great content, making sure that we understand what works for users and why, what doesn’t and how it can be improved. 

In the next blog, I look forward to giving updates on the areas we have chosen to pilot the platform, and progress in implementing among the partner organisations. 
 

Go to this site

Refining the KnowledgePoint prototype

09 Nov 12

Work on the KnowledgePoint platform has focussed recently on creating an improved experience for the user.  We initially aimed to build a proof of concept prototype.  Having done so, it has become clear that the most important thing that can happen would be to improve the look and feel of the site, how someone interacts with it, to meet both expectations of experienced web users and clarity for newer web users. 

Over an intensive two week period working with Aptivate, a number of design improvements were identified, and a prioritised selection of recommendations will be implemented by our main developers. 

Continuing a theme of sharing processes and experiences that may be of interest to other innovation projects, this blog post briefly outlines how these design improvements were identified. 

User personas

The first stage of the redesign process involved the development of three ‘personas’ – imaginary but representative users – who captured the core requirements of the system.  The users were: someone with deep expertise from an academic institution; someone who volunteers for an agency to help handle existing enquiries; and a person who works in a national-level partner organisation as an engineer. 

The exercise suggested the needs of these people would encompass many of the needs of more traditional actors – one of the aims of using user personas is to rationalise the number of needs you are trying to meet.  Later, our project will focus more on the specific and more demanding challenges that humanitarian actors face. 

User stories and user journeys

A number of ‘user stories’ were developed for each of these personas, describing not only how they would like to use the system, but where and when they would use KnowledgePoint, what their goals or concerns might be, their relationship with technology, and many other factors. 

To create ‘user journeys’, we took some key tasks that a user may need to carry out – essentially an output and a workflow to get there.  The user journeys are simplified to one title, such as ‘ask a question’, but encompass the several steps involved, shown here:

The image below shows how we captured this.  The four columns each represent a user journey.  Within each column is a number red or yellow cards (a virtual post-it note or file card) representing a story.  In the software we are using, you can then click on each card and see more details about the story.  The software is KanbanTool, who have very kindly donated a license to the KnowledgePoint project.

The cards can be moved around vertically to change the priority in which you will address them, and similarly, the next step will be to move the individual cards horizontally into an ‘in progress’ column – where our developers will turn the stories into usable features.

Attached to each card is a mock-up of what the screen might look like when a user is at that point in a journey.  The screen wireframe uses a tool we have used previously called Balsamiq, and also a standard design package.  An example of the screenshot for the story ‘search for an answer’ is below, first as a wireframe… 

...and also as a more illustrative mock-up:

Design review

For the time being, we have hidden features and functionality that does not fit with the user journeys we have verified.  This will allow us to review the usability of the most basic elements of answering and asking a question.  The overall visual impression has been moved closer to what people expect of an up-to-date, interactive platform – while this was not a full re-branding exercise, it will help in the essential task of making the site more usable. 

Finally, Aptivate used an exciting approach known as responsive design to allow the page to be optimised for different screen layouts.  This is an alternative to creating separate sites for mobile devices, for example.  The features that are visible and the layout of the site change to fit whatever screen size you have, and whether you are viewing your mobile device in portrait or landscape.  In a few weeks we will be able to share the results of this refinement in what I hope will be an exciting and more rewarding experience that will encourage the overall success of the platform. 

File attachment: 

Pic 1 Pic2 Pic 3 Pic 4 Pic 5

Go to this site

Final weeks of the Invention Phase: reflecting on progress and challenges

24 Aug 12

In our last blog post on the Invention Phase of KnowledgePoint, we described how we were setting up the software development stage.  The software development has been forging ahead, and we are now entering the final few weeks.  In this post I describe what we have found and reflect on challenges we have faced.

One of the early tasks was to develop sketches, or mock-ups, of how the final site might look.  These designs for an ideal platform have been followed, as the images below show. But while it may look like the site we had envisaged, would it work in the way we had hoped?   To answer this, we have not only been testing the site ourselves but also with the invaluable help of volunteer users.  

KnowledgePoint mock-up from October last year (top) and our test site (bottom)

It is great to reports that KnowledgePoint works as we had hoped as a platform for responding to technical enquiries, and allowing people to do so collaboratively.  Throughout the development phase we have conducted user trials on parallel versions of KnowledgePoint, phasing releases to different groups.  Continuous testing has allowed us to make sure the site is usable from the very start.  Our twenty (plus) early users have been asked to try tasks such as posting questions or responding to answers.  There have been hitches of course, but the overall finding is that the platform is already usable. 

User testing is also telling us what needs to be improved – indeed this is the most important function.  This invention phase has given us a great opportunity to trial features that are exciting but are less certain to work in practice, so the feedback has been vital.  In the end, I hope we have managed to get a balance of solid, core features with some more advanced approaches that we hope will be useful to the community. 

In terms of challenges, our key project issue has been timing, and there have been two main areas of delay.  The first was in finalising our specification and researching technologies on which to base the development. In hindsight, the extra time was a worthwhile investment, in that it resulted in a solid specification and helped identify an appropriate technology that gave us an ideal basis for development. 

The second area of slippage was during the software development itself.  Here we were dealing with the unknowns that are inevitably associated with invention.  I will digress a little on this subject in the hope that this may also be of interest to other projects! 

One analysis of managing project changes represents project parameters in an ‘iron triangle’: 

For projects particularly where there are many unknowns, the idea, represented above, is that it is difficult to hold multiple targets – resources, schedule and scope – constant without sacrificing quality.  Moreover, it is common for one or two aspects to increase (say, schedule and resources) in order to keep one or two others on track (for example, quality and scope).  

For our project, we will achieve our targets for functionality, budget and quality.  But we did this at the expense of our intended schedule: when new challenges emerged, we delayed while we resolved them rather than sacrificing functionality or quality, or increasing the budget.  Lessons have come from this that we will apply to the next phase of development and implementation.  We look forward to sharing more of our experience and possible solutions in further detail in our project retrospective.

Projects are of course delivered that meet all scope, schedule and budget targets.  But the lesson is as much for the planning stage as delivery, where one can answer the question: if new challenges emerge, of the elements in the ‘iron triangle’ what must be constant and what can change?  The counter-intuitive answer from Agile software development approaches is to make scope flexible and retain control of timing, budget and quality.  While we used some Agile approaches in the development, we did not go so far as to agree to let go of scope.  We will consider for the next phase if we should change tactics in this regard, or if the project outcomes have justified our approach, and we may be dealing with fewer uncertainties. 

None of this is to say that timing has been viewed as less critical.  Timing matters particularly for KnowledgePoint because, above all, if we take too long the high demand for ways to deal with technical advisory services will lead to separate solutions being developed, and the benefits of a shared, collaborative platform will have been missed. 

Fortunately, we are now looking at just a few weeks before we complete the project, and we are really eager to share with the community the prototype platform – and begin on the next phase of our development. 

We will let everyone know where to find KnowledgePoint and how to use it next month.  Although this will officially be a Beta (prototype) version, you should find all the tools there necessary to ask and answer questions collaboratively. 

Still, our work will only just be beginning as we begin to prepare the prototype for extensive piloting in the next phase.

Go to this site

A large HIF grant award!

15 Nov 12

We were thrilled to learn that KnowledgePoint will be supported by a large HIF grant award for a platform to deliver collaborative, timely and high quality technical support to humanitarian and development operations. This follows on from KnowledgePoint’s small HIF award for the Invention Phase of this innovation. With that phase nearing completion, we are looking to move from the prototyping to the delivery of a robust, user-ready tool. We see the route forward not just in our project proposal, but also from the lessons of the HIF process itself, and seeking the continued, invaluable support and participation of others in the sector.

Read more or Humanitarian Innovation Fund, 30 July 2012

Building and trials begin

17 Apr 12

In my previous post, I reported on the completion of the final specification, Stage 3.  We’ve now moved on to the prototype software build, stage 4 out of 5 development stages. 

As part of this phase, the KnowledgePoint platform is now open as a test site for limited-release trialling!  If you would like to take part, please email info@knowledgepoint.org.  We have a full list for the first two weeks of testing, but please do let us know if you would be interested in being involved in the next release.  More information on the trials can be found toward the end of this post. 

Finding our development team

The KnowledgePoint project is run by a consortium that currently includes RedR, WaterAid, IRC international Water and Sanitation Centre, Practical Action and EngineerAid.  From this alliance, we created a procurement panel to oversee the selection of candidate software developers. 

Our procurement decision would of course be founded on the cornerstones of cost, quality and timeliness.  But as anyone who has been part of software procurement knows, you rarely have three directly comparable options or an obvious list of candidates to start from. 

We want to build something that meets unique requirements.  At our KnowledgePoint Forum in the Hague in December, we heard compelling arguments that we should, nonetheless, avoid trying to create software from scratch; we should ‘stand on the shoulders of giants’, and build something innovative from existing components.  We’re particularly grateful to Deepak Menon of India Water Portal and Mark Westra of AKVO, among others who attended, for their advice on the software approach. 

Going straight for the main giant, we spoke to a tech company that is an industry leader in this field.  They supported the project wholeheartedly – but wanted us to work within their existing software, which unfortunately meant losing some of our key requirements for our operating environment. 

When asked, “what would it take” for them to meet our specification, they replied that they had received and rejected comparable proposals from multi-billion dollar companies.  The product philosophy is everything for such pioneers of the information age, and in their view they were being asked to stray too far from it.  And we don’t want money, they added, closing off a traditional route that clearly others had tried.   

There were few alternatives at this level, so the search went on to the wealth of agencies, design houses and lone developers, who may be based anywhere in the world. 

To narrow the search, we focused on identifying organisations and individuals who had worked on similar technology and preferably using open source software. Eventually we narrowed it down to three that best matched our needs.  But our final decision in fact involved asking two organisations to work together. 

The best option that met our criteria for talent and expertise in our core technology was based in Santiago de Chile, who also offered a competitive tender.  The main problem is that they were not set up as a software consultancy; although an established business, they would in essence be working through one person as a lone developer.  Independent of how highly we think of that lone developer, there is an unavoidable risk in putting all your code in one basket. 

We saw that by combining them with another organisation, Aptivate, we were able to fill the risk gaps that we had identified in using a lone developer.  Aptivate have huge experience in delivering IT projects for humanitarian and development organisations, and furthermore they had worked with the same core software before.  They specialise in many of the same approaches that we are prioritising (essentially, open-source, agile, low-bandwidth developments).    

Acting as technical advisors, Aptivate are providing everything from code reviews to project management support, and mastery of agile software methodology.  At the same time, our core software developer is providing great code and ploughing through the features we’ve specified.  Now we are in a position to test out what we have built so far. 

Trials

While our core platform is still very much in development, KnowledgePoint is following an agile approach to software that prioritises early user testing.  This has many advantages for an innovative project.  It focuses attention on user needs whilst providing a flexible project structure.  So when feedback (almost inevitably) requires changes to the software, risk and cost have been reduced by allowing problems to surface early.  The agile methodology is highly participatory, which fits well with the overall aims of our project. 

The trials are limited in scope so that there is time to respond to feedback individually and answer trial questions.  The trial site is currently at its most basic level – but new features will be released every two weeks for people to try out!

Once we have completed all iterations, we plan that KnowledgePoint will be in a position to conduct full-scale, controlled tests on live enquiries. 

With each release, we will also increase the number of people using the trial site, building a greater community.  Please do let us know if you would be interested in being involved by contacting us directly using the email address above. 

We hope people trialling the site will pose and respond to some test enquiries in the domain of Technical Support, but also just have a look around what we have built.  Testers won’t be required to fill in lengthy feedback forms, but if there’s something you would like to tell us, we do hope to hear any comments or suggestions at all you might have. 

***

 A quick final note on software, to say thank you to Balsamiq, who provided pro bono licenses to use their mock-up software, which has allowed us to put more funding towards core software innovation.  As blogged previously, you can see what we did with their software here. 

Go to this site

Progress at six months

16 Feb 12

With a comprehensive specification for the KnowledgePoint platform in place, based on extensive stakeholder feedback, the HIF KnowledgePoint project has reached the six month mark.  This update comes as we are about to embark on the build phase of the project. 

In my previous blog post, I reviewed the first two scoping stages.  Since then, we have completed our functional specification (Stage 3) and are about to begin the construction of a working prototype (Stage 4). 

A quick recap on our project: KnowledgePoint is intended to make essential technical support easier to access and to allow providers to collaborate and pool expertise. To achieve this, we are creating a web-based tool that will provide better ways for exchanging and capturing knowledge and experience.  Our project seeks to invent a suitable process and to test it in a working prototype. 

Stage 3: Design and specification

Project time has so far been split evenly between research in Stages 1 and 2, and creating the design and specification in Stage 3.  The context of the project is the invention phase of an innovation, and the inspiration and creativity that this implies were particularly vital for this third stage. 

For inspiration, we surveyed some of the key developments in web-based software that best matched the feedback we had received from stakeholders.  We picked the elements that fitted best, and described additional elements that we thought we needed.  We also built an early mock-up of what such a site might look like.  These allowed us to visualise what we wanted to achieve in the end, and provided a laboratory for our ideas before formalising them in a full specification. 

After exploring the possibilities, embodying these ideas in a solid specification was the next challenge.  Each one of the five organisations that constitute the core working group provided valuable input into the specification.  The group worked to create a consistent specification that could meet the assorted aims without comprising the unity of the design.  The specification that has arisen is solid and it’s great to see that the different organisations in the group have created a sinlge way forward for providing a great TSS tool. 

 ***

The build stage will begin within the next ten days, which we are expecting to approach in a series of releases that will allow us to test and review the platform in an iterative process. 

This will mark the start of a key phase of KnowledgePoint, and I look forward to providing updates on the new releases over the coming weeks. 

Tim Kent – Project Manager, KnowledgePoint 

Go to this site

The latest WASH sector innovation is not a pump but communication

19 Dec 11

About ten years ago I remember the revolutionary feeling of no longer needing to drive three hours back from a rural community with whom I was working in order to get advice on how to tackle a particularly complicated technical challenge. This was not because I had miraculously become a more experienced engineer overnight, but due to the fact that I was now able to call the office via a somewhat large and clunky mobile phone. The fact that I had to climb to the top of the recently constructed water reservoir to do so, did not really matter, as I had saved about three days in delays. Revolutionary yes, but it had taken about a year’s worth of wrangling with management to get the then expensive mobile phone contracts funded. (Posted on the HIF Blog by Erik Harvey- WaterAid)

Read the full blog post

Three months on for KnowledgePoint and the HIF

19 Dec 11

2 Nov 2011. The HIF KnowledgePoint project has been running for three months, and, as a result of our HIF grant, we have been able to increase dramatically our rate of progress towards collaborative knowledge-sharing for technical support.  Here is a brief overview of progress so far.

The first stage of our work sought to gather views on KnowledgePoint from stakeholders, and then to match those perspectives to a review of existing technology. The processes and technical requirements implied by the interviews and research in Stage one were amalgamated into a draft specification. The specification in turn was reformulated as a mockup, a graphical draft of how the system could work before any development begins. (posted to HIF blog by Timothy Kent, project manager KnowledgePoint)

Read the full blog post