What every engineer should know about project management

Project management in an innovative environment is the art of herding very smart cats. It’s the project manager’s (PM’s) job to make sure everyone is working on the correct tasks, that risks are being managed and communicated, and that the stakeholders (i.e. the decision makers) have the information they need to make informed decisions. It’s not the PM’s job to make decisions, but only to make sure the needed decisions are being made by the right people who have all the information they need (or at least, as much of it as possible). For the PM to do her job, she needs certain things from the Individual Contributors (ICs). In this post I’ll discuss what the PM needs from the ICs and why she needs it, but all of the advice can be summed up in one sentence:

Communicate quickly, completely, and candidly.

If you just do that, you can’t go wrong.

The PM is responsible for pulling together input from the team to create the plan:

• What tasks are needed?
• What are the dependencies?
• How long will the tasks take?
• What assumptions are we making?
• What are the risks?

The team will be responsible for delivering to this plan, which is much more likely to go well if everyone in the team has given their input. It’s critically important to capture all of the tasks that will be needed; otherwise you may not have all the skills needed to finish the project. Estimating how long a task will take is challenging, especially if it’s something you’ve never done before. Realistic estimates are best, optimistic ones are the worst: better to finish early than late. It’s the PM’s job to communicate to the stakeholders how confident you are in the schedule. If the most uncertain tasks are on the critical path (i.e. the tasks that if they slip by a day, the project slips by a day) her confidence will be lower than if the uncertain tasks have some slack.

If the plan doesn’t meet the stakeholders’ needs (e.g. a needed design mockup won’t be ready for a board meeting already scheduled) the team should gather to discuss how to adapt the plan, possibly by adding resources or shifting some scope to later in the program.

Every company does project management differently (e.g. Agile, Waterfall, Adaptive), so I’m not going to explain those paradigms here. Follow whatever processes your company uses. The advice on this blog post should apply across all paradigms.

It might not sound important, but the difference between a successful project and a struggling one can be as simple as filling out your timecards and other routine tasks. I once worked with an engineer that felt that filling out his time cards was beneath him. The company procedure was to have your time card completed for the previous week by Monday at noon, and ideally it should be competed at the end of every day. He, on the other hand, would complete his timecard only after much prodding, usually once or twice a month. This made accurate status reports impossible, invoices delayed, and basic metrics used to run the business, like “how many billable hours did we work last week?”, inaccurate.

It’s the responsibility of the PM to be able to answer any question about her projects that might come from the stakeholders, executive team, or functional managers. For her to be successful she needs to be in the loop.

If something goes wrong, let your PM know ASAP. I just heard a story about two engineers in a small company who both screwed up. When the first screwed up he didn’t tell anyone. The mistake was discovered by his manager, who used computer logs to figure out what had happened. When the engineer was asked about it, he lied. When shown the evidence he admitted that it was his fault, but by then it was too late and he was rightfully terminated. When the other engineer screwed up she immediately told the same manager what went wrong and led the charge to fix the problem. Everyone saw her as a hero. We all screw up sometimes; the difference between a hero and a villain is how we respond to our mistakes.

Similarly, if you figure out that some of the inputs or assumptions in the plan are wrong, let your PM know right away. Maybe you’ve worked 15 of the expected 20 hours on a task, and you now estimate it will take 30 hours to complete. Let your PM know immediately. You might be lucky and there’s slack in that task, so there’s no impact. But it might be on the critical path, in which case your PM will need to come up with a plan on how the team will respond and how to communicate with the stakeholders.

As part of the planning process the PM will create a communication plan. Typically the PM will be the primary point of contact with the project stakeholders, but sometimes it makes sense for the ICs to communicate directly with some of the stakeholders, especially if the discussions are highly technical. If that’s the case, it’s critical that the PM is in the loop, for many reasons:

• In these conversations scope increase is often requested (e.g. “While you’re changing that code, why don’t you add an option to change the units to metric”). Managing scope is one of the most difficult and critical tasks for a PM. Many a project has failed due to poorly managed scope creep.
• Information that invalidates an assumption might come up in the conversation.
• The IC might share information about a risk without informing the PM. When this risk isn’t included in the status reports or the risk registry, the team loses credibility with the stakeholder.

As I said in the beginning, it all comes down to communication, but your PM can’t follow every detail. Try and empathize and understand what’s important to share. Your PM doesn’t need to know how you laid-out a circuit board, but she does need to know why you had to violate design rules to make everything fit and why you think that’s OK. Your PM doesn’t need to know every line of code, but she does need to know why you’re concerned that you might run out of memory. When in doubt, communicate more; if you’re over sharing, your PM will let you know.

Originally published at https://asilberlining.com on November 18, 2016.