Project Planning for Document Management
You’ve done you strategy analysis work and now you’re ready to start your information management project. First you’ve got to do some planning! Proper project planning for document management initiatives puts you on the path to project success. And yes, unfortunately, it involves a lot more than putting together a timeline with some milestones.
As an information management professional, you will likely need to lead or be a key member of IM projects during your career. Do you need to be PRINCE2 or PMP certified to be successful? Not necessarily. Nonetheless, understanding the concepts underlying project management methodologies will make your life much easier and your project more predictable.
In this installment of the Insights series on document and information management projects, I’ll go over the things you need to consider—and ultimately manage—when you plan for your next IM project.
Planning for a Document Management Initiative
In the first phase of your document management initiative, strategy analysis, you identify your business needs and align them with business goals and objectives. In the second phase, project planning, you define the activities to get you from current state to the future state.
Almost half—24 out of 49—of the processes described in PMI’s PMBOK are part of the process planning group. Clearly, it’s important. The PMBOK standard states, in part:
The Planning Process Group consists of those processes that establish the total scope of the effort, define and refine the objectives, and develop the course of action required to attain those objectives.PMBOK Guide, 6th ed.
So let’s explore scope, objectives, and course of action a bit more. Scope is all about what you are going to do and what you’re not going to do. Make a point of clearly documenting what is included in scope and what is excluded from scope. Things you include should, of course, align with your project objectives. Once you’ve established what is in scope, you gather requirements and develop a course of action [many of the areas listed in the following table] to “attain those objectives”.
Project Planning Areas
The nine areas listed below align with knowledge areas in the PMBOK. You should consider each area for a document management initiative. Needless to say, the amount of time you need to dedicate to each area will vary depending on the project you’re undertaking. For example, a document management system implementation project will require more time on scope and procurement than a document imaging project, which will likely focus more on quality.
|Area||Activities / Documents|
|Scope (requirements)||Gather requirements|
Requirements, scope statement
|Schedule||Define, sequence and estimate project activities|
|Costs and budget||Estimate costs and create a budget|
Project funding requirements
|Quality||Determine acceptable levels of quality|
Quality plan, quality metrics
|Resources||Determine who you need, and when|
|Communications||Determine what needs to be communicated, to whom, and when|
|Risk management||Identify and analyze risks|
|Procurement||Determine what you’re going to do in-house and what your’re going to buy|
RFP, RFI, RFQ, Bids, SOWs
|Stakeholders||Identify project stakeholders and develop and engagement approach|
Stakeholder engagement plan
Project Planning Sequence
Although the table above has a top-to-bottom order, it shouldn’t be considered the order in which you perform the activities. In fact, the order is simply the order presented in the PMBOK guide. So, some activities may be performed in parallel and others when certain resources are made available to you.
Nonetheless, based on my past experience with document management projects, there is a somewhat logical sequence for these activities, as shown below:
When you start a project, you need to know who’s going to be involved, i.e., your stakeholders. For instance, when you identify your stakeholders early, they’ll be able to contribute to your requirements, provide you with a budget, (finance), support the project (IT, project sponsor), and get you resources (IT, HR, procurement).
At the other end, your cost estimates are driven by the requirements, risk mitigation and quality standards, and the need to procure (or not) resources—either people (consultants) or products. Of course, if and when you procure a vendor or consultant, for example, you need to update your schedule, stakeholder register and communication plans at a minimum.
Level of Effort and Estimating
And how much time should an activity take? Obviously, the only right answer is: It depends. Your organization may already have policies or procedures in place for things like procurement or communications, so you can leverage those kinds of organizational process assets, as they’re called.
Unfortunately, most document management projects are infrequent and somewhat unique. They’re hard to estimate. Therefore, it’s important to focus on scope, schedule and costs since it would be difficult, if not impossible, to use estimates from a “similar” project.
Of course, you still need to estimate. One way to do that is through decomposition, which is a simply breaking something “big” into its smaller [component] parts. In a project plan this is your WBS or work breakdown structure. In the Agile world, it includes your user stories and their assigned story points. Let’s look consider an example:
You need to estimate how long it will take to migrate 10,000 contracts from your Z:\ drive into your fancy new document management system. What are some techniques you can use to break this down:
- Determine how many different kinds of contracts you have (eg, supplier, vendor, NDA, HR, etc.).
- Estimate how many data points (metadata) you need to capture from each different type of contract during migration. How much is automated, how much is manual entry.
- Estimate how many of each kind of contract you have.
- Use the 80/20 rule—e.g., 80% of the contracts are “standard” the other 20% will need more quality control applied and will, therefore, take longer.
The decomposition threshold will vary among projects. One day might be fine or one week might be acceptable, depending on the length of the project. As a guideline, if a single activity takes more than 5% of the estimated time for the entire project (e.g., if you have an activity that will take 3 or more days in a 10 week project…) consider decomposing it. On the other hand, if you’re breaking tasks into hourly increments, you’re probably too far into the weeds. Regardless of your threshold or the methods, there are always ways to break a larger/longer activity into “right-sized” manageable parts.
Project Planning Considerations
Document management projects don’t happen all the time. You wouldn’t want them to! But when business needs necessitate a change—corporate strategy, management decree, or external factors—you, as an information management professional, need to be ready to take the lead. You should not only understand what you need to do from a project perspective, but also why you’re doing it.
This blog provides an overview of nine key areas you should consider when you put on your project management hat. Because the goal was to familiarize you with the planning areas, none were explored in depth…each area would be its own blog! And, perhaps, each will be the subject of a future insights blog.
Finally, remember: Once you’ve identified your business needs, proper planning is a key part of getting everyone—your stakeholders, suppliers, staff—aligned, so they understand what needs to do be done, by whom, and when, to achieve the business goals. Happy planning!
Any questions? Contact us—we’ll help you plan your next project!CONTACT OVITAS