Minimum PM documents for a small IT company

Question

I work in a small software company (1-50 Employees) as an Assistant Project Manager. I have been studying the PMP study notes for quite a while now and wondering if there are too many documents involved in a project; e.g. Project scope document, requirements traceability matrix, etc. Now, the projects we develop are mostly outsourced to us and the duration is mostly 3-6 months. We prepare only 2 documents, that is, a requirements document which describes all the requirements in detail and second, a technical design document providing all the technical design of the product we are developing. It has been working fine so far, we have had lots of successful projects with just these 2 documents.

Since the last few months, we have lost some customers, and in one case, the log of open issues was not maintained, and in another case, the communications plan was not laid properly. Which means we need to adopt some of the processes of PMBOK, but I do not think we can adopt all of these in our small projects. So what are the minimum essential documents to make (ie. WBS is mandatory) which will almost ensure the success of the project?

Answer 1

The issue is not just that documentation was poor, rather that some of your planning deliverables were either not done or not implemented. Documentation in and of itself won't help you.

That being said, documentation provides evidence that your team has thought through what you need to do and has developed a reasonable, feasible and achievable plan. The key thing to remember is that you can reduce documentation but you cannot short-change the planning process. For a simple project there is no reason why you can't have a single, relatively brief document that covers the same ground that would require multiple documents on a complex project. Where the challenge lies is in tailoring the level of detail in your documents to the needs of your project.

So let's talk about minimum content rather than minimum documents. In my opinion, there are three broad buckets that you need before you start a project:

• A business case. Without this you can't tell if your project will deliver value for money, which ultimately is the only real measure of success of a project. So some kind of cost/benefit analysis that you can revisit regularly to ensure your effort remains justifiable.
• Project product description. A description of the end goal and how the different sub-products fit into the overall picture. This provides you with a basis for developing things like a WBS.
• "Project initiation information". The sum total of what you need to know to be able to actually manage the project. So things like milestones/schedule, governance structure/stakeholder analysis/RACI matrix, WBS, scope statement, budget, key risks, etc.

Once a project is underway you will need to manage:

• Reporting. You need a way to report status to your team, customer and leadership, as well as tracking things like action items, decisions, risks, lessons learned etc.
• Delivery. This will be sector dependent, but generally things like requirements, acceptance criteria, etc.

Once a project is complete you will need to be able to communicate how your project performed against it's business case (so some kind of planning around benefits realization), lessons learned, etc.

Answer 2

You are looking at this incorrectly. A document itself is only as valuable as the paper on which it is written. Like the risk log, for example, folks will typically labor over the log so it is almost museum quality and forget they are supposed to be navigating rough waters.

Documentation is nothing more than 1) evidence that some type of planning took place, some type of analysis took place, to keep track of something, and some type of decision was made; and 2) to communicate those things and keep everyone on the same page. So the answer to your question is, you document so you can achieve those two objectives.

The question or point of view you need to ask or have is, what level of formality of the document do I need for this particular project. If you are working on a rather simple project, rather short duration, only a few resources, not a lot of money, not a ton of risk, you can get by documenting your plan on the back of napkin, i.e., short and simple, two or three pages, maybe four. If you are working a complex project, never been done before, 200+ team members, millions of bucks, etc., you are writing volumes.

Answer 3

Coming from a similar sized company within the software development industry, producing similar IT projects for clients ranging from 2-6 months builds I have a good understanding where you're coming from. It sounds like you have good processes in place for managing your projects, which includes documentation processes, however the problem that I'm hearing is that these processes are not being enforced.

To answer your question, I believe the following documentation (templates provided as download links) are essential for any project (regardless of size). This assumes that your proposal/costing document has been accepted.

1. STATEMENT OF WORKS (SOW) - this is a formal document that captures and defines the project requirements, deliverables, and timeline that you will stick to in order to deliver the specified work for a client. The statement of work should also include how success will be assessed. The SOW document comprises of the following sections:

   • Project Stakeholders: list each of the key project stakeholders & their role/s in the projects
   • Project Summary: outline in 1 or more paragraphs, who the client is and what the project is about
   • Project Success Criteria: provide a summary of and list of the criteria that must be achieved in order for this project to be deemed successful. What does the client want to achieve, from which ROI for the project will be measured?
   • Project Requirements, Goals & Objectives: List all the clients feature, functionality & design requirements. What are the project goals & business needs? What needs to be achieved as result of this project going ahead? Describe the key project objectives here.
   • Project Templates/Screens: list the key website / app templates and screens here. Highlight any screens/templates that are Phase specific. For example if something is mentioned as a feature requirements but cannot but delivered within Phase 1 budget, then list it here as a Phase II feature request.
   • Functionality: here you should list all the projects functionality in more detail. Make sure that you thoroughly think through each piece of functionality and if/how it would work within the overall project development. If it is an app development project, ensure that you have considered how both the online & offline functionality will work.
   • Technical Requirements: list all the technical requirements here

2. PROJECT PLAN:

   • A Project Plan is a formal, approved document used to guide both the execution and control over the project.
   • The project manager creates the project plan with input from the project team and key stakeholders.
   • The plan should be agreed and approved by the project team members and its key stakeholders.
   • If you work in an agile manner like we do, then break down your project into Sprints (as per the template).
   • As the project progresses and things change the project plan should get updated accordingly

3. FUNCTIONAL SPECIFICATION DOCUMENT (FSD): A Functional Specification Document (FSD) is the document that describes the requested behaviour of the end software solution. Some comments:

   • Our FSD's cover all technical and functional aspects.
   • For every piece of functionality, try and provide details from both a Users point of view (i.e. User Stories) AND a Functional perspective. You will see in the template provided how we do this.
   • Think of everything when writing the document. Ask yourself what if a user does this? And then what happens? And then? This will help you get to the functionality 'endpoint'.
   • As your project changes, update the FSD. The FSD by the end of the project should be the software manual, which then gets used by your QA Testing team to test against. As the testers complete their QA, they should highlight the FSD section in a colour (we use green), so that the client can see progress during sprints as to what functionality is complete vs incomplete. By the end of the project the entire FSD should be green - meaning all functionality defined in the FSD is correct and has been implemented.

There are more documents that you can use, but the above 3 are the absolute minimum for a smooth project delivery.

Answer 4

I work more in infrastructure and systems and I consider the absolute minimum documents are:

• Scope Statement
• Deployment Plan

I personally push hard for the Project Charter but our management team has not been interested in following most PMBoK ideas (lots of silos - very functional organization).

Why these two? The scope statement is the primary method to explain what is included and not included so that we can avoid scope creep. It is amazing how even simple projects can mean completely different things to different people. Having a written document published in a public location helps minimize that.

Deployment Plan is not a normal part of the PMBoK but it as close as we get to a project planning document. Our version of the deployment plan includes the communications plan, most of a WBS, and most of the stakeholder registry. Unfortunately, it is the only document where cross-functional review and approvals are addressed.

For a software development team, I would recommend:

• Stakeholder Registry (that includes the communications method that works best for that stakeholder)
• Basic WBS such as New Feature List/Bug Fix List for the current release
• Project Schedule (rough or estimated if probably fine)
• Communications Plan

You could combine these into one document and call it a "Pre-Release Plan"