How Can I Apply My Software Project Management Skills to a Hardware Project?

Question

I've been working in project management in software for a couple years now and loving it, but I'm now going to be transitioning over to a large project that's mostly hardware (still IT). I feel like most project management resources are either a) extremely general, or b) focused on software. (I've seen some focused on construction but that's not really what I'm going to be doing either.) I'm having a hard time seeing how to apply my software project management skills to a hardware project.

Answer 1

Other responses identify the software development / project management split, and that the project management skills are transferable. It is certainly true that development management and project management are not the same thing, although there are overlaps.

Even concentrating on the transferable PM skills, I would highlight two particular issues from my own experience: credibility, and terminology. These are linked, and if you are coming from one area of expertise, you probably won't immediately understand the terminology that is used in another domain. As a software developer, you probably don't know too much about physical connectivity of hardware components (or even what these components do!), etc, and you may feel embarrassed to ask. My advice is to acknowledge your lack of expertise, ask about the things you don't know, and make it very clear that your role is to manage the project, not to manage the tasks of the people you will be working with.

By being open and honest about what you don't know, as well as being clear on your role and its boundaries, you will build credibility, and you will gain the trust and cooperation that you require to succeed.

Answer 2

If you're having trouble transferring certain skills, it's most likely that those are software DEV skills and not PM skills. PM skills (or fundamentals) are usually transferrable across all projects. That's not to say that you don't have PM skills, but that maybe you're looking at trying to transfer the wrong things.

PM skills are about looking at the overall picture, and guiding the project; looking at the risks, the costs, the schedule, the expected outcomes, dealing with stakeholders, etc.

Don't get hung up on names or methodologies, or whether it's hardware or software. Break it down into 'where are we now, where are we going, and what has to happen in the middle'? Identify that middle part, and make sure you have a way to monitor the progress so that you have all the information you need to make decisions. Look at what has to be done and ask, "what don't I know here", and find a way to make sure that gap is covered.

And then as David said "Just get to work". :)

Answer 3

Here is my advice: don't do anything different. Apply the PM skills, knowledge, and techniques you already have and do and press go. The transferability of PM skills across industries is huge. Across products in the same industry, forget about it. Just get to work.

Answer 4

Trevor and David have provided great advice and I give them both nods for that.

I just want to back up their advice by telling you and can and is done. In the last decade project management has gone from being a tacked on job description we give engineers, to a subject matter expertise all its own.

I heard an interview of the outgoing PMI president (Fall, 2011). He talked about how in the early 2000s he was trying to get colleges to implement PM studies. One Ivy League school told him "PM isn't a discipline, it's a class." Today if you Google "project management bachelor degree" you'll get millions of hits.

I've based my career (and a lot of my blog writing) on this concept of project management being a subject matter expertise. I don't have a technical degree, I've never been an engineer. I've worked in customer support, product management, QA, business development and project management in industries as diverse as computer games, handheld devices, speech recognition, enterprise storage software, virtualization and hard drives.

It can be done. Have faith in yourself and focus on the people, not the project. You'll do great. (How do I know? You asked for help. That's a big sign of a good PM).

Answer 5

There should be no problem as the underlying principles of project management are universal.

• Ensure there is a justifiable business case
• Clearly define roles & responsibilities
• Clearly define and focus on what the end products of the project are to avoid scope creep
• Manage the project in stages, progressively elaborating your plans as you move through the project
• Define levels of authority within the project to allow for escalation of issues like cost/time overruns
• Apply what you have learned on past projects to help current projects succeed
• Keep communications open, accurate, proactive and timely
• Tailor your approach to the needs of the project

Answer 6

All projects go through largely the same types of phases. I'm not sure if you're existing experience is in waterfall, or agile techniques, but from a waterfall perspective, your project will go through the following stages:

1. Idea (Terms of Reference)
2. Definition (High Level PMP, Business Case, Risk Assessment etc, Requirements, Functional Spec etc)
3. Build (Technical spec, etc?)
4. Test (Scripts, plans etc)
5. Implementation (Pilot, training)
6. Close (Handover to BAU)

For the waterfall model, taking a look at PRINCE2 documentation would give you an idea of the framework/governance, and DSDM (Atern) could be useful if you're going to work iteratively. Good luck!

Answer 7

Both software and hardware projects have similar structures and stages...

Structure:

• System
  • Product
    • Component
      • ...

Stages:

• Define requirements for system

• Design system structure (products and integration points)

  • Define requirements for products

  • Design product structure (components and integration points)

    • Define requirements for components
    • Design components
    • Implement (SW-code, HD-simulation, HD-rapid prototype, HD-manufacturing)
    • Test components
  • Assemble product
  • Test product
• Assemble system
• Test system

What is important in both is to make sure the process is defined, the plan is and its stages are documented, the requirements are well defined and known to all stake holders, risks have been considered, time has been estimated, points and times of integration are in plan and etc.

The technological aspects can be very different, and you should learn the language that is used (mainly of the requirements and the integration points - not the actual details of how everything is implemented), otherwise miscommunications may occur. Consult with others that have the technical knowledge to make sure you understand things correctly and haven't missed anything.

Take into account, that modifications in hardware can be much more expensive than in software, because you pay for both time and manufacturing, so the plan can not be as flexible and the number of test versions will probably be small.

Also, in hardware you have to take additional elements into account, such as, power consumption, heat, how components physically connect together, how the size and shape of the parts effect the ability to manufacture, maintain and use the products.

Answer 8

I agree that the project management principles transcend software and hardware. However, there are some differences. Here is an interesting article I found that delineates those differences:

From 10 Ways Software Projects Are Different:

In comparing the management of different projects, the first trap that many people fall into is that they do not differentiate between managing the technology and managing the project process. Certainly there is a lot of difference between managing how concrete is placed and how the interface in a software development is placed on a computer screen. But how much difference does that make to managing either project in terms of scope, quality, time, cost, risk and so on?

-- Quoted from Max Wideman

In other words, most of your role is focused on managing the process, not the technology or the implementation details. As a general rule, managing the process is the same no matter what type of project.

In some ways, managing a hardware project could be easier. For example, you have something physical to just whether a deliverable is done or not. In software, it is more cognitive.

Here are some of the differences that you may encounter:

• People Management: - Construction is very physical and regimented whereas software is more creative, less restricted, and requires thought. This may affect how you deal with the people.

• Definition of Done: - The article mentions that it's much clearer what "done" means in a construction project.

• Estimations: - Software estimates can vary widely between people, depending on the approach, and this is acceptable and expected. Software tends to involve more unknowns, and technology changes rapidly. Construction involves processes which don't change much, and the same basic techniques are similar from person to person.

Good luck!