The Atlas is a remarkable detector.  It weighs as much as the Eiffel tower, consists of 10 million parts, and generates more data each day than Twitter does.  But as a recent Economist article states, as impressive is the fact that it is a collaboration involving more than 3,000 researchers from 175 institutes in 38 countries.  Combine that with the fact that industrial management structures differ from research projects, in that accountability and directives to team members lie with the institutions, and not with the project management.

The article cites a number of reasons why research projects frequently meet, and often exceed, their expectations.  The list covers issues like the natural inclination of scientists to challenge authority (thereby leading to better solutions) and the ability of projects to “absorb uncertainty”, something industry tends to be averse to.

But I think that the most important reason is that research projects provide the room for people to find their place and to unfold their full potential.  Sure, there are employers in industry that allow – or even encourage – this as well.  But in science, this is almost a must.  “People become scientists to extend the frontiers of knowledge. For many, it is an obsession.”

The challenge in research projects is to liberate this potential.  In practice, there are two challenges:

(1) The effort vaporizes: If everybody follows their own pet project, then people may have fun, but the whole won’t fit together.  The result is a scattered bucket of half-finished software, a loose collection of research papers, “case studies” that are little more than toy projects, and so on.

(2) People get frustrated: And the frustration may have many reasons: It can be overly firm management, but also the opposite: If there isn’t a manager to keep the researcher’s back free, it can be as frustrating. It can be caused by delays from other teams, not producing the outputs that are needed to proceed.  Once frustration kicks in, motivation bottoms out.

Managing researchers in a science project is a little like herding cats. To make a science project successful, and to address the two issues stated, leadership is required.  We at Formal Mind have a lot of experience in bringing industry and scientists together, and we are currently managing a work package (WP7) of the openETCS itea2 project.

So: How can you lead a joint research project to success?  Here are some of the lessons that we learned:

• Make sure all have a clear understanding of the underlying goal.  If this is there, then every activity can be put into context: Does it aid the reaching of the goal or not?  This can prevent researchers from working on topics that “kind of fit into the project”, but are not useful for achieving the project aim.  It’s also amazing how often people have differing understandings of a project’s goal.
• Support meritocracy.  Recognize the doers and support them as much as you can.  Those are the people who are really excited – make sure that you don’t stop them, but direct them to make sure that their work contributes to the underlying goal.  You’ll be amazed how infectious motivated people are.  With a little bit of luck, their energy will mobilize those around them.
• Support communication.  Even within one organization, it is difficult to ensure that everybody gets the memo.  On big research projects, there is rarely an up to date list of all participants.  Fortunately, social media make it much easier for communication structures to establish themselves.  Suggest tools for communication.  Once a tool is established, discourage the use of redundant tools (e.g. only one mailing list provider, one instant messaging service, one Wiki, etc.).
• Aggregate information. Once a project is underway, information overload quickly appears.  New team members in particular are often overwhelmed: They are confronted with mailing list archives containing thousands of messages, and once they subscribe, receive hundreds of mails every day, incapable of distinguishing the important from the mundane. Aggregating communication is a lot of work that pays of big time.  In openETCS, there is a weekly status email summarizing the most important developments (usually just half a dozen items).  These are then archived on a wiki page, allowing new team members to follow the development of the work package from inception to the present within half an hour.
• Negotiate, then escalate.  Alas, things don’t always go smoothly.  As a project (or work package) leader, the people don’t work for you directly, you don’t have managerial authority.  Because of that, it is crucial to understand the underlying reason for slow performance or inactivity.  While escalation is a regular management tool, I advise to use it cautiously, as it can create a lot of bad energy and politics.  In my experience, people want to do good work.  Chances are that you will get a motivated team, if you manage to understand the team and remove their obstacles.

Some of this advice may seem like common sense.  Yet, over the years I have seen quite a few research projects where there was room for improvement.  Taking this to heart may turn a successful research project into an outstanding one.

Help & Newsletter

If you need help bringing science and industry together, please talk to us. We are always interested in contributing to research efforts in the area of systems engineering.

If you like to hear about ProR, RMF and requirements on a regular basis, consider subscribing to our newsletter.  We send relevant and useful information once or twice a month.

Work for us!

Research-centric jobs in industry are rare.  Formal Mind provides an environment that gives talented scientists the ability to apply their skills in industry while staying on the cutting edge.  We leave you room to perform active research parallel to doing your day job.  Check out openings >>

Image courtesy of Danilo Rizzuti / FreeDigitalPhotos.net

Image of Atlas licensed under CCSA 2.0