While it’s not directly said, I have come across many engineers who balk at the idea of project management.
“It’s too much paperwork.”
“It’s nothing but process.”
“When do we get to do real work?”
…they might say. My response to that is: If project management is applied in the right dose, it can be extremely helpful, if not utterly necessary, to the success of any project. If a team is large enough, there might be one dedicated person to performing project management (PM) duties. If not, then the onus is on the members of the team to carry out such duties.
What is project management? It’s a communication tool. If you work on a project by yourself, for yourself, with no real deadline, then you can ignore the rest of this post. For the rest of the engineers, programmers, and designers out there, it is nice to have common language to help answer questions like “What exactly do you want me to make?” and “When do you want it done?” That’s where project management comes in.
Part of being a good engineer (I’m including programmers, architects, designers, etc. in here) is having good communication skills. I’m sorry, but I don’t care if you’re a rock star programmer who can reconstruct the Google search algorithm in FORTRAN in an hour by yourself, unless you can find someone who will use it (or at least throw it up on Hack a Day for posterity), no one cares.
And thus we come to the first part of project management: Requirements! Yes, requirements are a good thing. They can be written on a napkin for all I care, but having written requirements help in many ways:
- It’s a form of contract – you and your customer must agree on what’s being built
- They provide something to test to. If your program/gadget/building meets the requirements, there’s a good chance it meets the needs of the customer
- If you’re working on a team, your team has a clear understanding of what to build
Here’s the kicker: requirements can change. They’re not set in stone. You might have to push back on the customer a bit: “OK, we can add that feature, but delivery will slide by an extra month and it will cost you an extra $20,000.” In the end, requirements should be part of a living document that will likely change over the course of a project.
Then there’s the schedule. That seems to be everyone’s favorite. Why should you have one? Because, once again, it’s a useful communication tool. Your customer knows what to expect – when are things supposed to be delivered – and your team knows how much they need to bust their ass (or slack off). If your boss asks you when will the project be delivered, how can you answer that without making some sort of schedule.
If you happen to know the gritty details of the project, then by all means schedule down to the hour. For efforts that have some unknown (“Gee, we don’t have that technology yet, so we’ll have to invent it”), you might need to put some slack or have a set control gate in the middle of the project to determine if it’s still feasible.
If you work in the software world, there are plenty of good methods to help deal with unknowns and feature creep, such as the Agile Method. Things like hardware and mechanical designs take a bit longer (there’s no “compile” button to determine if your gadget worked within a few minutes) and require more traditional approaches like the Waterfall (in my opinion, not optimal) or Iterative methods. Thanks to technology like rapid prototyping, iterations in the hardware world are beginning to take a lot less time.
Finally, there’s the fun part of PM: delivering! Well, there is usually more involved in the delivery part than just handing over a tool or putting it up for sale. You need to work with the customer, sales, etc. to make sure that the tool does what the customer needs. Once again (and I’m pretty sure I’m starting to sound like a broken record), good communication is key here. Documentation is important for the customer (how do we use it?) as well as the engineering team (how do we make more?). I personally enjoy this part of PM – nothing beats the feeling of delivering a tool that gets used and gets praised.
I think that about does it for my rant on why I think project management is important. It’s an important part of any engineering or programming curriculum, even if it’s often shoved aside as just a “soft skill.” We usually don’t live in a bubble, so good PM skills can help a project succeed. Just don’t focus too much on the PM side – or you’ll never get anything done. “Tailoring” is an important skill to all PMs.