Project Management

Hi all
I am going to take a break from the technical to discuss how to run a project. During my career I have experienced several project managers and have heard from many others about their project managers. Here is my distilled list of how to run a technology (and just about any other) project. I am sure there are other ideas and approaches, but here is my approach. If you like yours better or feel I should modify mine then leave a comment below.

Project management is classically defined with several stages including: initiate, planning, execution, monitoring, and closing. I will talk about higher level ideas about how to manage the project and not the stages. The stages are pretty self-explanatory and a Google search will provide hundreds (if not more) sites about those stages.

Meeting overload is a common problem where people want to “meet and discusses useless stuff that might seem important”. As such a balance needs to be created between what a meeting covers and the frequency of a meeting.

In general for a given project I think having 1 general weekly meeting for 1-1.5 hours a week is reasonable. For a small project (less than 15-20 people, or 4-5 working-groups) this meeting should cover both the high level project status as well as individual reports from each person/working-group. In a large project having two meeting a week can be justified. The first being the general all-hands meeting and the second being a working-group meeting. For example if a project has 5 working-groups, one for electrical, mechanical, autonomy, perception, and testing each one can have a weekly meeting where they discuss the low-level details for what needs done and who is assigned to each task. Then at the all-hands general meeting each group leader can present a quick update on their working group. Having all of the people present at the meeting and not calling in (ie teleconferencing in) is just about always better. Having people on site helps build a team and improves overall communication. Face-to-face communications is important, don’t believe people when they say they can video conference or whatever and be just as effective!

One way to organize the all-hands general meeting is with the use of a quad chart. A quad chart (see main image above) is a Power Point slide (or whatever favorite slide program you use) that is divided into 4 sections. The sections can then be used to concisely give an update for a given working-group. You should have each working group submit the quad chart in advance so that they can be compiled into a single presentation, for a more efficient meeting. The typical contents of a quad chart are:
1. Image (or video)
2. Recent accomplishments (things done in the last week)
3. Upcoming (or key) milestones/dates
4. Risks and possible problems and delays

When there is a looming deadline or milestone approaching it can be appropriate to have a daily standup meeting. A standup meeting is one where you stand (no sitting!) and only lasts for 2-10 minutes; tops! This is a quick meeting where you can divvy up tasks, check on progress, and allows people to talk to each other if there are any issues.

At any all-hands, working group, or standup meeting you should have somebody in charge. Having somebody who can make the executive decision is important when there are competing ideas and/or priorities that need to be sorted out. This person in charge needs to be able to make decisions, if the person is always hesitant to make a decision then the project can lose focus and waste valuable resources chasing the wrong ideas. At some point a decision maker (or engineer) needs to use the best information at hand to make a decision.

Every task should have someones name listed by it. By having a person responsible for every task you make sure that people know what they need to work on, you instill the responsibility into that person, and you know who gets blame (or needs to explain) if something is not completed.

All of the above about delegating tasks and assigning responsibilities assumes that you trust the people you are working with, and that are working for you. If you do not trust the person then they might be the wrong person for the job and can place a strain on everyone. If you don’t trust everyone (or just about everyone) on the project then the problem might be you, and not the other people, and you should re-evaluate yourself.

When you assign tasks to groups try to keep the groups small. Designing by committee is just about always a bad idea. Having a small dedicated tag team that can focus on a problem without interference will usually result in a better solution in less time then a committee would have come up with. The small team is also more agile to make changes as needed or as ideas are developed. The problem with committees is that everyone has an opinion (contrary to popular belief not all opinions are equal). At some point you just need to build something and then if needed you can tweak things later. Design by committee, is just a project that is doomed to fail. If you are forced to use a committee make sure there is a single person that has executive decision to knock down stupid ideas (remember what I said about all ideas not being equal) and can dissolve the committee when the time comes to start executing the idea.

Robotics typically falls in the “extreme” category of project management. This means that there are frequent changes that affect project timelines and ideas. You need to be ready to make changes and stay agile. This get more difficult the more groups that are involved in your project. The key to this is for everyone to stay flexible and not get angry at each other.

When you develop a project schedule you need to make your schedule twice; once forward, and once in reverse. What that practically means is that you want to start from today and create a chart (often called a gant chart) showing how long it will take to do each task. Once you make the forward schedule you can make the reverse schedule by starting from the critical dates and working backwards for when things need to be done. Both the forward and reverse schedule need to agree with each other while adding in some time margin and removing your wishful thinking.

In line with schedules remember that things take time. If your engineer says it will take a full day to make a metal plate with some holes (or two weeks to design a PCB), don’t say something like “why would it take so long to drill a couple of holes (or why would it take so long to put a few components on a board). I have seen many new/inexperienced project managers say stuff like that and get angry at people since things are taking longer then they expect. Remember things take time.

As mentioned before having all of your people in-house can lead to better collaboration between team members. I think this is especially important for complex software development. In a past project I worked on we had a large conference room where most of the software team would sit around the conference table and work. Whenever you had a problem or question about another module you could just look up and ask the appropriate person. I should also mention that there were several side offices that anyone could use if they needed privacy or wanted to make some noise.

Project management software can be useful for tracking schedule, sharing information, and keeping a log of all communications and design decisions. The tricky part is embedding the software into the project teams culture and getting people to use it. Once you get people to start using it, then it can be easier to have people and new team members use it regularly. This often starts with having the project manager using it for communications which forces others on to the software tool. Some common tools include Redmine, Basecamp, Traction, and Trac.

Treat your team good. If they are working late trying to meet a deadline, show some appreciation and bring them some food or something. An even better idea is to always provide perks such as food, snacks, etc.. that keeps people happy and improves productivity

Finally when a project successfully closes remember to take your team out for a nice lunch or dinner. Its tradition 🙂

Liked it? Take a second to support David Kohanbash on Patreon!