I'm a newbie PM. I am a programmer before. So, what document/diagram is needed or better to have in a software project?

  • Vision and expected benefits - updated and maintained over time - it's definitely THE ONE document that'll help ascertain value delivered :) (The others are in the answers :)
    – PhD
    Commented Mar 11, 2012 at 17:24

6 Answers 6


So, what document/diagram is needed or better to have in a software project?

In short, Those ones that helps you.

You could write down all available documentation and generate all possible diagrams... and if you don't know how to use them / keep them updated, it will be a waste of time.

I'd say that maybe the inner question would be what's the most important document a newbie PM needs to worry about?.

On this sense, I believe that having the project scope properly documented (including specially what will NOT be included on the deliverables) would be first thing you'd need to go for.


  • what document seems likely will be "updated"?
    – lovespring
    Commented Mar 8, 2012 at 13:23
  • Well, a Gantt Chart for instance ideally would need a daily update based on the team's results...
    – Tiago Cardoso
    Commented Mar 8, 2012 at 13:48
  • Your bolded point is huge. We use PM tools to compensate for human frailty. The tools that compensate for my weakness are different than the ones for yours, and different from the original poster. In part, tools are a personal decision.
    – MathAttack
    Commented Mar 11, 2012 at 0:47
  • 1
    Agreed, @MathAttack. My point is... for a broad question, a broader answer. As you stated, each project has it's own needs... but in general, the most important docs are the ones that are usable / add value to the management.
    – Tiago Cardoso
    Commented Mar 19, 2012 at 22:08
  • @tiago - agree completely
    – MathAttack
    Commented Mar 20, 2012 at 0:31

There is of course a lot of documents that are MUSTs in software project, but the one that is in the center and in my perspective the most important one is Product requirements document (PRD). All other documents as software plan, implications, shipping criteria are based on what is in PRD.

PRD should contain following information:

  • Overview - short description what is the project about
  • Glossary - to be sure that everybody is thinking about the terms used in PRD in the same way
  • Actors - who is who in the project
    • owner
    • approvers
    • project team
    • ...
  • Requirements - possibly most important part, but should not be the only one as all other parts of PRD make the picture complete
    • Functional
    • Technical
    • System
    • Legal
    • ...
  • Constraints or Implications - what other project are affecting or are affected
  • Time-line - just high level, another document should contain detail plan
  • Links to other documents - PRD cannot contain everything, but should at least point to everything important
  • Other - mostly information specific to organization

Of course every company or project could have different needs and subsequently section in PRD, but every PRD in a company should have same or very similar structure so everybody can understand it very quickly.

  • there are no musts as is evident in Agile projects which would have little of the above. Commented Mar 10, 2012 at 0:05
  • and that's a real shock to traditional waterfall style developers who have a hundred reasons why it sounds crazy. I know I did before I got into it. Commented Mar 10, 2012 at 0:06
  • One thing I find useful in this doc is the business case. This helps prioritize the requirements.
    – MathAttack
    Commented Mar 11, 2012 at 0:44
  • Regarding the Agile project I think there is a need for similar document too, but some of the parts don't have to be filled in at the beginning. PRD is quite high-level document, in agile world more than in waterfall one. And it is more open to changes in agile world. But I think even project that is agile have to have clear high-level idea about what should be the results of the project, who are the actors, when should be the project delivered, etc. Maybe PRD is not the correct title for agile project...
    – Juraj
    Commented Mar 12, 2012 at 11:50

Depends very much on what project management method you plan on using. The minimum set of required documents scales from "just a Kanban board with task cards pinned to them" (for doing minimal Kanban), to Project Backlog, Sprint Backlog, Burndown Chart (for scrum), to that what Juraj wrote and way, way more beyond that (prince 2 comes to mind).

Documentation is important for:

  • project managers, for defining project scope, and prevent scope creep
  • stakeholders, for getting progress information
  • the team, for knowing what to do next
  • the support people, for knowing how to answer customer questions
  • the developer 3 years from now, because he needs to know where to start if the software needs to be updated, or fixed, and you are not around anymore

Think about your project, and think about it's context in the systems allready running at your company today. How are those systems affected by your project, what will be different, what is no longer possible, once your project is deployed. Start by documenting that, and many more ideas will follow.


Very few universals in Project Management. The tools and temates depend on the project, team and manager. An experienced manager building a space shuttle uses different tools than a new manager building websites with creatives.

With all that said, here is what I use almost every time...

  • Issue, risks and actions lists in Excel with owners and dates.

  • Staffing plan listing roles and responsibilities.

  • High level scope, which ideally contains the business case.

  • High level plan with critical path dates.

Many times I use more, but rarely do I have less than a high level version of the above.


The correct and precise answer depends a bit upon the size, complexity and specific phase of the project, and there are few arguments against what has been mentioned in other answers. However imho the one document that integrates all your PM activities, independent from any method you will use, is a (deliverable focused) Work breakdown Structure (together with a WBS dictionary).

It will help you

  • Define the scope of your project
  • Plan and budget
  • Determine required resources
  • determine risks and quality assurance requirements

and most of all, it will help you to communicate in a structured manner all of the above.


I assume it is rather small project, not a space shuttle ;-), so I quote Tiago, only those documents that are really needed. But the question remains, which are needed?

For sure "Success Criteria of the Project". Having such a document, you will know, what is really important for the project and client. Based on Success Criteria you will decide, if for example timing is crucial, if so, then you definitely need detailed schedule. The same applies to each particular point of the success criteria list.

Tricky might be only risk register. Newbie PMs usually forget about this document, and it might seem unnecessary, but its worth to spend some time on it, at least to identify most important risks.

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