Over the next three months there are projects planned which will use 140% of the available resources. In reality this means that we’ve got to hire in freelancers and contractors to cover work and ensure we’re meeting all the commitments. All of the work is strategically significant and high priority, and I’m acutely aware that the funding available to make these things happen is only available until August is unlikely to be available again in the next couple of years so we have a small window of opportunity to get things done. I thought that I’d explain what the developments are and how we’re planning to manage them.
Firstly we’ve had a number of successful small bids by academic colleagues. One of the most interesting of these, led by Doug Clow, is the development of a community based version of iSpot – this project is called iSpot local and is JISC funded for the next six months. The project is around community engagement as much as technology and there are a number of Bio Blitz’s to engage locals. Because the system is can be largely standalone we’re using a freelancer to carry out the work and using a series of hooks to the main iSpot service. The plan is that the iSpot local modules will be made available and can be set-up by anyone using a generic Drupal instance. Then you request an API key to allow your service to connect to iSpot and transfer the data between the services. Without the key you’ll still get the local community toolkit but it only becomes really useful when you can overlay all the data, the ‘spots’, that are localised to your community. There will be a map which will be set to your region or area (you’ll need to configure it initially to set it for your region) and the sightings in your area will then be displayed. The freelancer is having to work pro-actively on a steep learning curve to get the services working efficiently but he has been making good progress and we’re confident that the system will be ready for the first Bio Blitz on the 21st May.
A second project which we’re currently involved in is around the aggregation and presentation of Digital Scholarship data, this is led by Martin Weller, this is interesting because it is getting data feeds from a number of existing services and pulling data to form a view of an academic’s digital profile. As Martin says
Boyer defines scholarship as being based around four functions: discovery, integration, application, and teaching. We can think of digital scholarship then as the changes in all four of these that are brought about by the impact of digital and internet technologies. For example, if we take ‘discovery’ to be largely synonymous with ‘research’ then a digital scholarship view would be interested in the way researchers are collaborating using new technologies, sharing and visualising data, forming research communities using social media, etc
Up to now we’ve been using a contract developer (Richard Greenwood) to build the service but Richard is now required on another project around developing android apps (see below) and so we’re employing a contract developer to complete the final phase of work which is around adding further data feeds and working with the researchers to develop the visualisations.
The third project we’re undertaking is to develop mobile apps for the iSpot service. iSpot recently passed the 10,000 user mark and so it’s at a stage where we’re considering the use cases and the baseline activities that need to be developed through to ‘production’ level service. I’m excited by the opportunity to work with the OU’s Knowledge Media Institute to create mobile apps. We’re concentrating on developing an app for Android and iPhone initially but we’re creating an API which can be used across mobile platforms. Richard Greenwood is going to be working on the API and also developing the beta iPhone app. The apps will allow users to easily use their phones to capture images and upload and share them. Because of the location specific information and the visual aspects of iSpot it is a perfect service to deploy as a mobile app and it will interesting to explore how things like the image carousel and mapping information can be recreated through an app.
The fourth project we’re working, led by Mary Thorpe, is called PePLE, the concept is to create a professional working environment to support social workers, as Mary says…
PePLE is a resource for the training and continuing professional development of social workers that can be used with flexibility to fit in with the operational demands of workplaces. The resources can be used to support independent study or existing employer led provision.
The site is unique in terms of the tools it provides and we had to make the difficult decision (as we did with Cloudworks) to use a framework other that Drupal for it because there were too many constraints within Drupal to allow it to be considered. By the way there’s a good blog post about the decision to move to CodeIgniter by another of the developers, Juliette Culver, for those that want to explore the pro and cons of different PHP framework environments. The work on this project is almost complete and the site is being used as a resource to support OU Health and Social Care courses.
The fifth project we working on is the development of the OU Media Player, which I’ve already blogged about in a previous post. Work is going to plan on this project but we’ve had to be very agile and flexible in our thinking and do some reassignment of work throughout the project, to ensure things get delivered as expected since there are fours units all working together on this project and the timescales are tight. There an early demonstration of the embed service in action (note not yet accessible!).
So these projects are all significant and all have deadlines of end of July. What are the lessons we’re learning for doing all these things together and with limited resource.
1. It’s the people who make the project work. Good people who are flexible in their thinking and are into solving rather than creating problems.
2. Being pragmatic. Don’t think you can do the ‘gold star’ service within three months. In particular getting a realistic scope and keep it realistic. The developers need to be good as deciding when the requirements come in how to manage those against existing ones.
3. Use freelancers and contractors where you can on the commodity items.
4. Keep reporting and documentation to minimum. Rely on the developers to self organise, using tools such as TimePanic to keep active tracking of their time on projects.
5. Organise meetings effectively. In the team we have a system which I’m exploring where we only arrange meetings on Monday or Tuesday and the rest of the week is purely for programming. This allows the ‘flow’ that is needed to develop. So all the team only arrange any project meetings on the Monday or Tuesday in any week. The meetings are kept short and a fixed agenda. I have monthly 1-2-1’s to check progress (the team use Google Docs to record their progress for these 1-2-1’s) and rely on project blogs to keep me informed of any day-to-day changes.
6. Issues are flagged up and recorded and resolved quickly and without fuss or blame. We assign an owner to problems and fix a date to have things resolved. We use the same Drupal module that Drupal.org use for managing bugs and feature enhancements. I bring in project support staff to assist me with organising resolutions if they involve multiple parties/units.
7. Ensure the developers are not ‘managing other people’s monkeys’, I use the 1-2-1’s as an opportunity to explore what the developers spend time on to try to ensure that the majority of time is on the development of the services and not on administration, design, support.
8. Be transparent. Keep active communication channels open with the project team, stakeholders and end users. This can be done in numerous ways and will help to ensure rapid feedback and iteration.
None of these things guarantee success but they help to reduce failure rates.
Weblog of Will Woods 