I work on a large line-of-business legacy application, my projects are very much NOT green field. The dev teams are small, usually 2 developers, 1 system tester, plus part-time PM and BA resources. For every hour we spend cutting code, we spend a scary amount of time doing something else. I've listed the rough areas and in brackets the amount of time spent in hours:

  • Requirements gathering, business and systems analysis (0.5)
  • Functional and technical design (0.5)
  • Cutting code (1.0)
  • System testing, including test planning and developer time fixing bugs (1.5)
  • Developer time fixing bugs arising from user acceptance testing (0.5)
  • Deployment planning, deployment and post deployment support (0.5)
  • Project management, requirements and design walk-throughs (0.5)

Is this typical?

  • This is slightly unclear - are you asking this of developers, or PM's? If developers, this would be better placed on Programmers. These aren't standard tasks of a PM.
    – SpoonerNZ
    Commented Oct 29, 2013 at 11:33
  • Hi SpoonerNZ, thanks for your reply. I guess I'm thinking of everyone in the IT Project team, more specifically, anyone whose time gets charged to the project. So for me, that would be developer, QA/sys tester, PM, Business Analyst Commented Oct 29, 2013 at 12:57
  • 1
    I've edited the question heavily for formatting, and made it less of an opinion-based poll. Hopefully the crux of your question is clearer now.
    – Todd A. Jacobs
    Commented Oct 29, 2013 at 17:04

2 Answers 2


I will argue that writing code is probably one of the least important parts of the project. In my view it is a means to an end, at the end of the day you are translating the requirements of a customer into a particular syntax that can be executed by a machine to deliver benefits to that customer.

  • "Requirements gathering, business and systems analysis" and "Functional and technical design" - You should spend far more time on these than writing code. If requirements and design aren't clear you are dooming yourself to a lot of rework and wasted time at best, or to a project product that fails to deliver the planned benefits at worst.
  • "System testing, including test planning and developer time fixing bugs" and "Developer time fixing bugs arising from user acceptance testing" - I don't think anybody puts the time into these that they should, there is too much pressure to get something out fast. Ideally you allocate a substantial amount of time in your plans for testing and fixing bugs (at a guess 20-30% of total project time). This sounds like a lot but remember that you have no way to predict a priori how many bugs you will have or how hard they will be to resolve.
  • "Deployment planning, deployment and post deployment support" - You can have the best code in the world but if your deployment is poor your project won't reap the benefits it should. By analogy, I can build the best engineered car in the world but if I don't have a good plan for selling them and maintaining them after the initial sale I will be out of business sooner rather than later.
  • "Project management, requirements and design walkthroughs" - This is totally dependent on the criticality and complexity of your project. You will need more oversight/governance for even the simplest project if it will make or break your company. That being said, project oversight is probably the one piece that I would tailor to let me allocate more budget to coding.
  • Thanks for your answer Doug B, please see my comment under CodeGnome's answer for a fuller show of appreciation! Commented Oct 30, 2013 at 8:28


You've described a scenario where your process overhead is actually only around 10%. That certainly seems adequate for most purposes.

You may be mis-categorizing prerequisites and dependencies as process overhead. By doing so, you have incorrectly determined that your process is wasting 80% of your available man-hours (or incurring process overhead of around 500%) when in fact your process overhead appears to be well below the 35% average for American industry as a whole.

Acceptable levels of process overhead are really just management targets, and will vary by organization, job sector, and project management framework. There is no single number which is ideal across all scenarios.

Process Prerequisites

In a way, you're looking at things backwards because your question axiomatically assumes that writing code is the primary purpose of your project management process. It isn't. Delivering value in a predictable and controlled fashion is the raison d'être for project management.

In general, most of the additional steps you've listed as overhead aren't. As an example, requirements-gathering isn't really overhead since you can't deliver working code if you don't know what code to write, or what that code is supposed to do once it's written. Gathering requirements is therefore a prerequisite to writing the code; or, if you prefer to turn it around, writing code has a dependency on requirements-gathering.

Most of the steps you've listed add value to the project. They ensure that you are building the right things, and in the right order. That classifies them as prerequisites and dependencies, rather than waste.

Process Overhead

While there's surely a technical definition, in practical terms process overhead is all the stuff that adds no intrinsic value to the deliverables, but is nevertheless necessary to the functioning of the project itself. Project meetings, project management artifacts, and project communications are often good examples of typical overhead.

Do the Math

You've defined a process that totals 5 man-hours per feature, of which only 30 minutes should be classified as overhead. You are therefore spending only 10% of your project time in process overhead. In contrast, a typical Scrum project often requires around 30% overhead for its processes.

Unless you have a specific business driver for reducing that number below 10%, I don't see an actual problem. However, if management or your development team feels that there is waste that can be trimmed, by all means feel free to see where you can make some incremental improvements without cutting quality.

  • 1
    Thanks for your extremely useful answers CodeGnone and Doug B. I actually think our division of time is fine, but am under significant pressure to alter it, and wanted to see if I am being unreasonable. Commented Oct 30, 2013 at 8:30
  • Really fantastic answer, @CodeGnome. I'll be citing this wisdom. :) Commented Nov 3, 2015 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.