- Details
The programming we choose to do in our team is like the neck in the hourglass representing life science research and technology:
- There are many grains of sand above us. Those represent all the software tools developed in life science research.
- There is a large void below us. This represents the need for widely applicable tools in the life sciences.
- At the bottom there are also grains of sand. They are well settled. These represent the current technology: commercially available tools and well-serviced open source packages.
How does the sand get from the top to the bottom? Via the neck of development. It is narrow; only few academic tools make it to the bottom. The flow through the neck is powered by:
- push: a few academic groups that have the capability and capacity to make their tools available
- pull: a few companies that look far ahead and are able to see and use the potential of an academic tool
In our hourglass of life science tools, new sand is being added at the top all the time. And most of it overflows the beaker after a while. Some tools never deliver what the author thought they would do. Some are made to solve a single problem and rightfully abandoned when that is done. But many tools are published and left as orphans. Only a selection of tools that promise to be useful for a larger audience ever make it to the neck.
In practice, the neck is too narrow. There are many more valuable tools than are taken up. A team like ours can help to make the neck larger by making existing research tools applicable for wider use as a service to life scientists with a clear need (we call it professionalization). But it is sometimes hard to convince funding parties to pay for this. It is also hard to convince researchers to work on making their software better: professionalization does not generate new high-impact papers. We work on convincing the funding parties that it is better to professionalize existing successes than to reinvent them using research money. And we work on convincing the scientists that professionalization of their output will lead to higher citation scores on their existing publications.
Science wants novelty. And the current Dutch finance climate is directed towards applied science, towards innovation in society. Look at the picture, and you can see that these are hard to combine. Innovation starts where novelty ends. The only way to make the combination is to include development.
Photo by graymalkn on flickr
- Details
Ann Martin explains how IMI work at #datasharing11 in a room with a Volendam harbor view
#conference
- Details
The biopartner accelerator building (Leiden) is officially opened today. #work
- Details
The project management podcast episode 189, talks about what projects can learn from social media. I recognized many points relevant to our organization!
- Details
In an organization with more than two people, most likely there is a hierarchy. Some people are managing others.
On the other hand, project leaders are not necessarily managers of the members of the project team. Project leaders can not give orders to get things done. In our organization it is even worse: project team members are employed by different universities and hospitals, and the project leaders are in our separate group. Orders will not work.
A question that comes up sometimes is: how can one manage a project and its team members without giving orders? Sometimes this comes in the form: for you things are much easier, you are the boss and can tell everyone what to do; I do not have such power over the project team. My answer to that is: how often do I order you what to do? And if I'm not ordering you what to do, how do we run a coherent organization?
The clue is: don't tell people what to do, convince them instead. Build trust (this takes a while), and then use your expertise to convince the members of the team to align.
In fact in larger organizations, managers do not use orders a whole lot. Trust (and expertise) are much more effective. And this gets stronger higher up in the organization, up to the CEO. The biggest problem with managerial power is that it wears off when you use it. Trust grows when used properly.
Don't manage by giving orders. Act like the big company CEO.
For more inspiration, listen to this Manager Tools cast.
[Image credit: Giving orders by lincolndisplayimages.com on flickr]
- Details
We did experiment quite a bit with different ways of having our group meetings. At most of our meetings some of the group members are joining us from remote locations, and we want the remote members to be full meeting participants.
For a little while we only shared the sound with the remote participants, using skype. That worked rather well, but it brought the difficulty that the remote participants could not see the same screen that we were projecting on the wall in our meeting room. If we had only one remote participant, we could transmit a lo-fi image through video skype, but this was hardly better than no screen at all.
We then started trying different web-meeting software: a free trial of gotomeeting, and the free version of dimdim (when it was still available). Gotomeeting had the problem that it is not supporting Windows, Mac and Linux equally. Dimdim had better support for different operating systems, but had much worse sound quality and the video was sometimes completely black or delayed by as much as 10 seconds. These "official" solutions did therefore not lead to better communication for us.
Our problem was solved when we realized that we could use skype for audio, and all share the same screen by using VNC. We installed a VNC server with (readonly) java client on one of our linux servers. During a meeting, the meeting facilitator is in control via a read-write VNC session while the other participants only watch. Audio connection is done via skype as before, delivering good quality audio through a special external speaker/microphone combination.
This made us very happy, without monthly subscription costs. I'd like to hear in the comments about other alternatives you have explored.
Update: Esther van Enckevort explains in a posting on her blog how to set up a VNC server like we did.
- Details
How important is it to prioritize?
Lets assume we have 4 ideal projects A, B, C, D, and an ideal project team. Each of these projects takes 3 months to complete. They are all equally important. We work on them in parallel. When will the projects be ready? Project A will be ready after 12 months. Project B will be ready in 12 months. Project C will be ready in 12 months. And Project D will be ready in 12 months.
Now, what happens when we prioritize and work on the projects in alphabetical order? When will the projects be ready now? Project A will be ready after 3 months. Project B will be ready after 6 months. Project C will be ready after 9 months. And project D will be ready after 12 months. Everyone except the customer of project D will be better off! Fantastic, isn't it?
Unfortunately, this is not the perception of your customers. Each of them sees a 3 month project and wants it finished in 3 months. The customer in project D does not want to hear "we will start on your project in 9 months". All too often, priorities therefore change. Every month, at a project team review, you will be forced to reprioritize. What is the effect? Project A will be ready after 9 months. Project B will be ready after 10 months. Project C will be ready after 11 months. Project D will be ready after 12 months.
What a waste. Don't fall into this trap. Prioritize, and stick with the choice.
[Image credit: goldstardeputy]