1

When there is a new IT project, what documentation should we begin with? What structure do they usually have. Is there a common standard to compose them? I am entirely new to IT projects, I am investigating and would happy to receive support from more experienced community.

  • 1
    Hi Anna, welcome to PM.SE. I believe your question might be a dup of What document/diagram is must have for a software project?. – Tiago Cardoso Feb 11 at 19:30
  • 2
    Hi Anna, could you please help us understand if there's any specific problem you'd like the community to help you with that's not mentioned on the link above? If the problem is the same, I'd expect the community to consider your question as duplicate and thus, closed. – Tiago Cardoso Feb 12 at 19:02
  • Hello. Now I am starting to work on a new IT project, so I am making a document to about its structure, features. I just want to how do these documents usually look like? – Anna Galstyan Feb 13 at 7:44
  • Hi - have you had a chance to look at the link to the other question? It might clarify your doubts (or at least give you the path to continue your analysis). – Tiago Cardoso Feb 13 at 8:10
  • I will do more attentively. I have just gone through.Thanks Tiago Cardoso. – Anna Galstyan Feb 13 at 8:22
2

There are some documentation instructions in different service management frameworks like Prince2, ITIL and in certifications like IEC-12207, PMMI etc. and some standards for how to draw diagrams like UML.

But if you don't want to be certified and don't care about frameworks and all that (and you don't have to unless it's mandated by law in certain domains) you can just roll your own way of working. While that means you can get by without documentation it doesn't mean you should.

My take on documentation is to bake it into your software development process as much as possible. What this means is that you treat each piece of the process as not done until sufficient documentation has been done. Examples that I have used:

  • When planning a new feature document it's dependencies to other systems. Write some real world usage scenarios. Draw some interaction diagrams of the UI and also the background systems.
  • Document the current architecture in different levels. Have high level diagrams and low level diagrams for each subsystems. When planning new features the draw the changes to the architecture if needed.
  • Use BDD-style scenarios for feature documentation
  • Document your process and how it evolves through time as well.
  • Write down how to do stuff. For examples how to set up development environment. How to make a build to production etc.

There's loads of stuff you can do and what you NEED to do depends on your team, stakeholders, legal requirements etc. But whatever you do, bake documentation in to the process so that Thing X is not ready until sufficient documentation is done. Have it as a part of Definition of Done.

1

In PMBOK terms, you'd begin with the Project Charter. PMI recommends a specific structure for it: https://www.projectmanagement.com/deliverables/289555/Project-Charter-Template

  • I know about Project Charter. As far as we work Agile on IT projects, we do not use PMI standard for documentation. I just wonder is there an accepted standard for my case? – Anna Galstyan Feb 19 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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