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

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.NEW_LINENEW_LINEOne 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.NEW_LINENEW_LINE

NEW_LINENEW_LINE

NEW_LINE

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

NEW_LINEIt 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.NEW_LINENEW_LINEUser 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.NEW_LINENEW_LINEIn 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.NEW_LINENEW_LINEThe 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!NEW_LINENEW_LINEOne analysis of managing project changes represents project parameters in an ‘iron triangle’:NEW_LINENEW_LINE

NEW_LINENEW_LINEFor 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).NEW_LINENEW_LINEFor 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.NEW_LINENEW_LINEProjects 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.NEW_LINENEW_LINENone 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.NEW_LINENEW_LINEFortunately, 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.NEW_LINENEW_LINEWe 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.NEW_LINENEW_LINEStill, our work will only just be beginning as we begin to prepare the prototype for extensive piloting in the next phase.