Five Advanced Document Management for Large Projects
Document management is a process for managing how you plan, store and retrieve documents on a project. Managing documentation is usually a part of the broader communication management process. Most projects don't need to worry about formal document management processes. However, if your project produces a lot of documents you should think ahead of time about how you will store them so that they are easy to find later.
Of course you should think about naming standards, directory structure and common document formats. In addition, large projects should also consider the following.
- Assign a document librarian. The responsibilities of the librarian are as follows:
- Coordinate activity that is related to the document repository
- Establish, maintain, and enforce document repository standards and monitor them for conformance
- Identify and resolve repository problems
- Monitor and control access and updates to the repository
- Define access rules. The access rules describe items such as who can review documents and who can update them. Most documents should be accessible for the entire team to read. Some documents may need to be more secure. However, you should also be clear on the documents that team members can access and update.
- Define repository update procedures. All team members will need full access to their own documents. However, the project manager needs to decide whether anyone can make updates to other team member’s documents as well. For instance, some documents might be open for anyone to update. Others need to be locked down to prevent updating without proper authority.
- Determine retention and purging timeframes. Purging old documents ensures that the information on the repository is relevant. For instance, weekly individual Status Reports may not be needed after three months. On the other hand, the Project Charter document is needed for the life of the project.
- Hold periodic repository review. If your document repository is very complicated, it may make sense to perform a periodic review of the repository and the overall document management processes. The librarian will be responsible for coordinating this review.
Use These Nine Elements to Complete a Statement of Work
Partnering with high performing suppliers can be critical to delivering successful projects. Whether you're hiring a supplier to deliver equipment, provide consultancy or simply make the coffee—the key is to document your requirements for their delivery upfront within a "Statement of Work" (SOW). Without a detailed SOW) it will be difficult to manage your suppliers performance, as you will not have a clearly laid out set of requirements upon which to base their performance.
(Note that some organizations use an SOW on internal projects - often as another name for a Charter. However, I am using the term now as a procurement document - that is, between a buyer and a seller.)
Although you may have a formal supplier contract in place, the contract will most likely specify the legal aspects of the relationship - not the specific procurement requirements of your project in detail. The SOW is used to:
Creating a detailed Statement of Work is not too difficult a task. Complete the following steps to create a comprehensive SOW for your project.
1. Background. Describe any perspective or background information that makes sense for the project. For instance, you may wish only to work with suppliers over a certain company size, with experience providing certain types of products and a detailed knowledge of your industry and local market. You may also require that the supplier has a certain number of years experience and clients who can to act as referees.
2. Deliverables. Provide a detailed description of the deliverables and or services to be provided by the supplier. For each product, describe in detail its components (if a 'good') as well as any skill-sets required (if a 'service').
3. Dates. Clearly state the dates within which deliverables must be complete, and any other expectations for the deliverables or services.
4. Training. Identify the training required by your project team, if any, to ensure that maximum benefits are gained from the goods and services provided by the supplier.
5. Documentation. List any documentation to be supplied, such as an Operating Manual, User Guide, Business Processes or Support Procedures.
6. Support. Describe the level of support required of the supplier by specifying thing like the support hours needed and the level of support to be given.
7. Other materials. Include any other materials and equipment to be provided by the supplier to the project team.
8. Acceptance. Describe the process for acceptance of each deliverable, to ensure that deliverables are formally reviewed and accepted by the project team before they are deemed 'complete'.
9. Payment terms. Identify the conditions and terms for making payment to a supplier for goods and services rendered.
That's it. If you complete each of the steps listed above, you will create a comprehensive Statement of Work which can be used to get the most out of your supplier relationship.
Describe Project Value Using a Business Case
It can be hard to compare and prioritize the projects in your portfolio because there are many different types of projects. Some projects might increase revenue, some might decrease costs and some might help build internal capability. All of them have some benefit but it may not be easy to know which ones are the most valuable and which ones are the most aligned to your goals and strategies.
The way that you compare projects is through a common Business Case. The Business Case describes the reasons and the justification for the project. It also contains high-level information on the project, including estimated costs, risks, deliverables, assumptions, and the expected business benefits and value. The sponsor is responsible for the Business Case.
Business Cases should contain the following information:
- Description of the project. This is a description of what is being proposed. Be sure that it provides enough information so that others can understand the work that is being proposed.
- Assumptions. List the circumstances or events that must occur for the project to be successful. Assumptions are the things that are considered to be true even though they are not 100% facts. There is some uncertainty, but the Business Case “assumes” certain things to be true for the purpose of planning and definition.
- Risks. List the circumstances or events that would be a major impediment to the success of the project. Risks have a probability of occurring, but they are not guaranteed to occur. Risks generally are seen as bad things that have a detrimental impact on the project.
- Financial model. Your organization must create the common financial model for all projects (ROI, EVA, etc.). This is extremely important if you are going to compare projects on an apples-to-apples basis.
- Estimated business benefit. You must try to determine tangible and intangible benefits in terms of your common financial model. Some business benefit may be indirect, but the benefits should be as tangible as possible to compare favorable with other projects.
- Estimated cost. Provide as accurate estimate of the cost as possible. Your department may set a standard for the level of accuracy required. For the Business Case, you might look for estimated cost to be within 35%-50%.
- Alignment. Validate the alignment by specifying how this work contributes to your organization's goals and strategies. Your organization should have a pre-defined model and common rating scheme for alignment so that you can compare projects effectively.
- Is the work required? Specify whether you feel this work is essential. Some work may be required for legal or regulatory reasons, even if it is not aligned and does not have obvious business benefit.
- Urgency. Describe the required timing of the project. Some projects need to start at a certain time. Some projects must be completed by a certain time. Other projects can be executed at any time throughout the coming year.
- Consequence of not performing this year. Describe what the consequences are of not performing the work. In many cases, this is just as important to know as the business benefit and alignment.
But there’s another part to this trend: we are seeing more people failing audits and reaching out for help. If that’s you, don’t worry: I’ve got you covered with this article. And if you are in the middle of your PMP training and preparing your application right now, read on: I have some great tips to help you avoid the headaches audits can bring.
Why PMI® Does AuditsFirst, you should know that being selected for an audit is random. There’s nothing on your application that flagged it as being worthy of a second look. PMI does, however, reserve the right to audit any candidate at any time – that’s clear in the PMP Handbook.
PMI does audits to ensure the standing of the PMP credential. The application team wants to make sure that their policies are fair and that they are only moving people to the next stage of the process who are eligible for the credential.
In other words, audits protect you because they ensure the value of the PMP credential stays high. As PMI can’t subject every application to an audit, they select a proportion to review.
The Audit Ensures That You Are a Project Manager who Leads & Directs ProjectsOne reason that the PMP credential has such a high regard around the world is the fact that it is reserved for a very particular group of people: project managers who lead and direct projects. And the audit ensures that you - the applicant - meet this qualification. So let’s make sure of that:
- You are a project manager if you are the person who has been assigned to lead the project team responsible for achieving the project objectives.
- You are leading and directing if you are ultimately responsible for the tasks as well as have the knowledge and skills specified in the PMP Examination Content Outline.
- And finally it is only considered a project if it is a temporary effort (with a clear beginning and end) undertaken to create a unique product, service or result.
Where the PMP Audit Fits Into the Application ProcessIf you are selected for a PMP audit you’ll find out by email after your payment has been processed.
You’ll have 90 days to provide the information that the audit team needs. Once you’re successfully out the other side of the audit, your one-year examination eligibility period starts.
How You Can Fail The PMI AuditThere are 3 ways that your application could result in an audit failure:
1. No Fault
This is where the audit team can’t verify your education or experience – you either don’t have the experience or education required or it isn’t clearly enough described in your application.
This is the outcome if you choose not to go through with the audit process at all. If you don’t respond to the audit you’ll receive a one year suspension period before you can apply again.
If PMI identify that you have provided false information on your application then you will be permanently suspended from taking any PMI exams. Forever.
Top Reasons For Failing The Audit (And How To Avoid Them)So what could result in your application failing the audit process? Here are some of the top reasons we have gleaned from students and what you can do to avoid them happening to you.
Your experience entries do not meet the requirements of the PMP credentialThe work experience you’ve listed is not aligned with the project management process areas (initiating, planning, executing, monitoring and controlling and closing). It might not be possible for PMI to see what role you took on the project. They need to see that you lead and directed the project.
They also need evidence that you have experience in each of the process areas. You don’t have to show experience in every area for every project but the totality of your application should document that you have experience that stretches across the whole of the Exam Content Outline.
- Make sure your application covers all process areas.
- Use PMI terminology to describe what you did and the tools and techniques you used.
- Try to show your experience across different knowledge areas.
- Focus on what was most important for each project.
- Talk about what you did and how you did it, not what you were responsible for. Describe your contribution in concrete terms.
You’ve submitted experience that wasn’t on projectsPMI doesn’t care about the work you do outside of projects. If you are not clear enough to determine whether they are truly projects, PMI may deem that experience inadmissible.
- Write clear descriptions for your projects.
- Describe the project objective in a sentence.
- Summarize project deliverables by process area (for example, state the project management documents you were personally responsible for in each process)
- Add a single sentence to describe the outcome.
You’ve grouped information about multiple projectsPMI wants to review what you did on each individual project and your application will be rejected if you group information about multiple projects.
- Do not combine your small projects into one.
- List each project separately.
You included voluntary projectsWhile working on projects unpaid can give you considerable experience, for the PMP® application PMI only wants to see projects that “represent professional and compensated work.” If you include voluntary work this could cause you to fail.
- Only include projects that you were compensated for.
You didn’t submit all the required audit information in one goPMI requires that you send all your audit information back in one bundle. If they receive an incomplete submission from you, that’s an automatic fail.
- Making sure you have everything required before you respond to the audit.
Boost Your Chances of SuccessGoing through an audit isn’t the end of the world. If your application is solid, the audit process doesn’t take long and you can start preparing for your exam. If you want to avoid the extra steps and stress that an audit might bring, it helps to have an experienced PMP coach review your application. This can give you confidence and ensure that your investment in your application has the best possible chance of success.
You might also choose to use a PMP coach if you’re preparing a new application after failing an audit. They can help you select appropriate, different projects that are new for PMI’s review: the audit team may not pass projects that previously failed.
If you’ve been audited once you should expect to be audited on your next application. It might not happen: but it’s highly possible. Using the tips in this article you’ll be well prepared in case that happens.
About the author: Cornelius Fichtner, PMP is a noted PMP expert. He has helped over 40,000 students prepare for the PMP Exam with The Project Management PrepCast at http://www.pm-prepcast.com and The PM Exam Simulator at http://www.pm-exam-simulator.com.
Use Status Reports to Manage Expectations
Let’s face it - Status Reports are usually not as effective as they should be. This is true for team members that submit Status Reports to the project manager, as well as project managers that are submitting Status Reports to their major stakeholders. One of the major reasons is that the people completing the reports look upon them as a chore and not as a way to communicate valuable information. You typically get a Status Report that is very brief and says nothing, or else you get a Status Report that contains all the mundane activities that a person did.
The person creating the Status Report needs to write it so that the reader can use the information. The information needs to be of value. The writer should ask whether the information on the Status Report is there to really communicate something valuable or is it just checking a box.
Information to include in your report
Typically the Status Report should focus on the following:
- Accomplishments against the assigned activities on the schedule
- Comments on work that should be completed but is behind schedule
- Problems (issues) encountered, the impact to the project, and what is being done to resolve them
- Scope change requests
- Risks and what is being done to manage them
- Observations that will be useful to the reader
Report on a “frequent enough” basis
The frequency of status reporting is based on the length of the project and the speed in which you need to react. For instance, if your project is two months long and the project manager receives Status Reports from the team members on a monthly basis, there is not enough time to respond if problems are reported. A good rule of thumb is as follows:
- Small projects may not need formal status reporting.
- Team members on medium projects should report status every week.
- Team members on large projects should report status every week or perhaps every two weeks.