Project planner

Summary

The “project planner” may be better called a project mentor, or architect, or something like that. (If you have a better name, let me know). This role takes a new project request from a customer, figures out what they actually need, and makes the plan for how to do it. If the task is very clear, one could go straight to doing it (Project work), but many times we are the computing expert, not the customers. In these cases, we need to work with the customer (domain expert) to figure out what is needed.

The “project planner” is distinct from Project work since you may hand off the main work to someone else to actually do, possibly serving as their Technical mentor during the project. In short, figuring out what to do is usually harder than doing it (at least it’s a different skill). That’s why we have multiple people involved.

Main challenges/pitfalls

  • Customers may not know what they need (and maybe not even what to ask for). If we do exactly what they ask, we may do the wrong thing. We need to carefully work to find out what the goals are. This is research, and you are a part of a research team, not a contracted developer.

  • The job requires having a broad knowledge of what tools are available and even going and learning more to plan the project.

  • Defining what is our responsibility and what is the customer’s responsibility.

  • Planning enough to know what to do, while taking into account that in research the long-term plan may not be known.

  • Even after you do know what to do, explaining it clearly and concisely enough that the customers and others can understand what is happening. (This often happens when needing to present the project to more customers than the original ones.)

  • All the risks that come with research and software development, combined.

Expectations / checklists

  • Serve as the second contact to projects (first contact may be someone hearing the broad idea and suggesting a meeting) and organize a planning meeting with the right people.

  • During the planning meeting, really figure out what the people need (which may require digging, and also helping to come up with what the right solution is). Assume you are part of a research team, not a contracted developer.

  • Use your experience and communication skills to develop a workable plan along with the customers.

  • Write down the plan so that everyone is on the same page and expectations are known across all sides. Clearly allocate the different types of work to RSEs or academics.

  • Avoid the XY problem.

  • Ensure that customers are aware of any risks and you have a plan if the risks come.

  • Have initial finance discussions (team supervisor needs to finalize it).

  • Present the project in the weekly RSE meeting and your evaluation if we should take it or not. During this meeting, also help the team come up with the right people to do the project. You don’t necessarily have to do every project yourself, even if you are involved in planning them.

  • Have the courage to say “no” when that is the best answer.

  • If someone else new is working on the projects, mentor them with the material from Project work.

  • If you aren’t working directly with the project, stay engaged enough to keep the project on-track, either as a Technical mentor, domain mentor, or general mentor role.

External materials

Training program: materials and exercises

Roleplay: Planning meeting of a new RSE project, including filling the template, making a Gitlab issue, etc.