ASP.NET Security Consultant

I'm an author, speaker, and generally a the-way-we've-always-done-it-sucks security guy who specializes in web technologies and ASP.NET.

I'm a bit of a health nut too, having lost 50 pounds in 2019 and 2020. Check out my blog for weight loss tips!

Can non-technical Project Managers lead software projects?

Published on: 2011-11-07

Project managers without a background in software are put in a difficult spot when they're asked to manage software projects. To see why, let's start with the tasks a typical project manager is expected to complete:

  1. Ability to create a full project plan
    1. Determining the critical path
    2. Determining which resources are appropriate for available tasks
    3. Planning the project execution timeline
    4. Creating milestones
  2. Tracking project status
    1. Determining what action is appropriate in the event of a time or budget slip
    2. Making sure that action is taken and that it has the desired results
    3. Determining the cause of a time or budget slip
  3. Ensuring that everyone involved in the project has what they need to move forward
    1. If not, removing obstacles/provide needed information

However, not only from my own experience but also hearing developers speak at user groups, hearing developers talk about project managers at other companies, reading blogs about project experiences, etc., I've come to believe that too many project managers out there reactively track status by asking the team for periodic status updates, and do little more. The resulting process followed by the team looks a bit like this:

  1. Critical path planning gets done poorly, when it is done at all
  2. Poorly done critical path planning means resources aren’t added when they are needed
  3. Asking the team for a status only works when the team is both qualified and aware of all the tasks that need to be done
  4. Problems are never prevented because they are never seen until it is too late

Though without intimate knowledge of the software development process it's tough for me to imagine that project managers can do much better. This is because without hands-on experience, it's almost impossible to know what the critical path truly is, which leads to the disasters don the road. But because traditional project managers are expected to perform all of the job duties outlined at the beginning of the post, project managers are very often the ones held most responsible for the success or failure of a project. I cannot think of a greater disconnect between expectations and ability to meet them for any position.

I see three possible solutions to this problem:

  • Only hire software project managers with hands-on experience with technology
  • Move to agile methodologies and put the product owner in charge of the process
  • Keep a non-technical project manager on the project, but make a technical architect the primary person responsible for success of the project

Any of the three could work, but a further discussion of these options are a subject for another blog post.

This article was originally posted here and may have been edited for clarity.