In the next series of blogs, I will be providing some proven tips for Project Success and what you can do to help your team to deliver successful projects. This blog is focused around Project documentation.
Project Documentation can be area that you either love or hate as a Project Manager. WBS, PMP, RMP and other abbreviations can have your head swimming but it doesnt need to be so complex! The PMBOK has a great overview of all of the inputs/outputs that you need to have for a project and using this as your baseline can really help guide you on the path to success. An example of this is below with the Work Breakdown Structure.
One reason why I invest a larger proportion of my time into having such good documentation is to ensure that we have a good solid foundation to be able to start the project with the best chance of success. I am strong advocate towards the 80/20 rule and believe that it really can take away a lot of the headaches that you may have later in the project.
Is it really important?
This is often a question that is asked by Stakeholders who are eager for you to start the project. Or reply that “as long as you have the basics, it’s fine”. I reply the following:
“A project is like building a house. The documentation is the foundation of this house. If we skip steps or don’t do it properly, we are left with unstable foundations which can cause issues later on”.
I would also make sure that when you’re working on your project documentation that you look at prioritising and being very clear for what needs to be worked on first. This can also save time in making sure that you have the necessary information for the artifacts as they appear.
What about agile?
I have heard from team members the following: “Emily, we’re working Agile, we don’t need to focus on documentation! It’s anti agile!”. My reply is: The Agile Manifesto clearly states: “Working software over comprehensive documentation” but it does not mean NO documentation. You need to make sure that you have a clear framework available and where several agile projects go wrong is where they do not devote sufficient time to establishing this framework of documentation and guidance.
Tips and Tricks for success
- Identify which Documentation needs to be done and which order
You can use the PMBOK here or your organisation’s documentation order for what needs to be completed when. There may already be documentation created as part of the viability/presales phase so don’t be afraid to use this as your starting point.
- Use Templates (if they exist) and don’t reinvent the wheel
One area where a lot of Junior Project Managers struggle is knowing where to start or how a document should look. I’d recommend that you look for templates that might exist from your PMO to know if there’s already a clear way that a document should look like.
If you’re looking for templates, you can use online tools or repositories like: Projectmanagement.com or the Digital Project Manager. Be aware that you will need to adapt templates to fit your industry/goals.
- Look at Lessons Learned
This is similar to the point above but you may already have a wealth of information that you can be reused from a lessons learned repository. This could help you identify risks/communication plans and/or stakeholder matrixes/impact. If there is no lessons learned repository then i’d recommend that you think of starting one from this point forward.
- Set aside time to do the work!
This might seem really logical but I often use my calendar to block several hours to devote to writing documentation or I use a Work from Home day to focus on documentation and getting into a draft state. Don’t be afraid to block out time and make sure that you stick to it!
- Have it peer reviewed
Writing documentation can be a soul destroying activity and sometimes you may get caught so much in the detail that you miss critical information or make simple errors. Having your documentation peer-reviewed before releasing out of the project, can be invaluable to help ensure quality.
A tip that I like to use is that I work for 2-3hrs on one bit of documentation and then give myself a “mental break” and work on another activity or do some sport to clear my mind and refresh for the next block of work or meetings.
- Review it often (and update accordingly)
How many times do you update your core documentation on a project? Never? Rarely? One activity that I like to do is to go through the documentation on a quarterly basis and understand if we’re still aligned or if I’m missing anything important.
If you can get your Project Documentation into a good order, it’ll help the execution of your project and hopefully relieve some of the stress that you may experience during a project execution phase!