What document/diagram is must have for a software project? [closed]

Question

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

Answer 1

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.

Success!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.