Face it; the timeline will never be long enough. Most nonprofit organizations don’t have enough time to do all the regular day-to-day work that’s required to raise the money, run the programs, pay the bills, report to the stakeholders, and further the mission overall. Add to that carving out time to plan and execute on a data integration project, and you might as well give up and go home.
Just kidding. Of course, time is at a premium; it always is and always will be. But, with proper planning, execution, monitoring, and accountability, you should be able to carve out the time you need to complete your integration initiative, use that time effectively and as intended, and have additional time built in for contingencies and the unexpected.
Timeline and Project Planning
The very first thing that needs to be done is to acknowledge the need and the time for proper planning. Planning includes identifying a project owner – that could be a departmental leader or a project manager brought in to run the project overall. It’s then her or his responsibility (typically with the collaboration of other team members) to outline all of the key project activities, chronologize them, assign task and RACI roles, and finally, assign a timeframe for each along with relevant dependencies.
Cogent and pressure-free planning is the first step to being able to create a realistic timeline that includes all required project tasks along with contingencies. The RACI Matrix, discussed in Part 1 of this series, is one of the planning tools you will use. Another would likely be a written project plan that includes each project task and who’s responsible, but also realistic starting and ending dates, a detailed description of the task, and any dependencies, ie, other tasks or activities that have to be done before this particular task can start.
There are a number of widely available project planning tools that can be used, some of them free, or with free versions.
Effective timeline estimation is dependent on the following critical project components:
- Identifying each project activity and task.
- Knowing who is responsible and how long the activity or task will take, based on the person doing it.
- For any task or activity, knowing what the dependencies are, and what the estimated dependency timeframe(s) is/are. Dependencies are any activities or tasks that have to be completed before the activity or task in question can begin. An example of that is data mapping. Data mapping is a key integration activity, but it is dependent on identifying the specific data elements that have to be integrated from one system to another. Until those data fields are specified, they cannot be mapped.
- Incidental items that have to be accounted for – when team members are on vacation, when a certain event or campaign will take priority over everything else, when the office will be closed for a holiday, etc. Sometimes, additional time is built in for decision-making, if an organization has a history of needing more time than less to make certain decisions.
Once you have identified all of the information above, you can record and chronologize each task, and you can assign beginning and ending dates, and thus build your timeline overall.
Below is an example of an integration project timeline using Smartsheet’s free version. Note that on the right side, Smartsheet has built a Gantt Chart, which visually represents the timeline based on the start date, end date, and duration of each task.
Risk Mitigation, Contingency Planning, and Recovery
It’s rare that any project timeline gets executed exactly as planned. While some projects may be completed early, the majority are not, and while delays can be embarrassing, what’s worse is that those who were relying on the new integration to support them in their work must continue to rely on old, slow, and/or broken processes all the longer. To a great extent, risk mitigation is about properly setting expectations with key stakeholders and other team members. If you think that a project will take three months, and the project timeline shows four months, well, you get the idea.
The best way to mitigate against anything that may slow you down or take longer than anticipated is to build contingency time into your timeline. You don’t have to do that for every task, but you should consider it for any activity or task that is a key dependency for something else. The ‘right’ amount of contingency time is going to be different for every project and every project team, but 30% is often a standard and 40% is not uncommon. That can be applied to every task or only to tasks where there is a greater level of uncertainty.
Should you find that your project timeline has gone completely off the rails (a key team member leaves your organization; you discover a fundamental design flaw), you really only have one choice: re-establish the planning and estimation process, and furnish your stakeholders with a revised project timeline, along with a mitigation plan to ensure that the issues that caused the delay have been or will be effectively addressed.
Data systems that have different functions – from major CRM systems to smaller ‘point’ systems that do just one thing (eg, take payments) – were generally designed in a vacuum: they weren’t inherently built to ‘play well with others’. In the final installment of this series, we’ll look at the challenges of innate differences between data systems, how technology can address them, and the long-term impact of leveraging data integration technology.
Request a demo
[pardot-form width=”250″ height=”500″ id=”1205″ title=”Demo”]
Stu Manewith, CFRE joined Omatic Software six years ago and serves as the company’s Director of Thought Leadership and Advocacy. In that role, he is Omatic’s nonprofit sector domain specialist and subject-matter expert and is responsible for actively promoting and demonstrating Omatic’s position as the nonprofit industry’s leading partner in the areas of data health and integration. Prior to Omatic, Stu spent 13 years at Blackbaud, working with Raiser’s Edge, Financial Edge, and Blackbaud CRM client organizations as a consultant, solution architect, and practice manager. Previously, Stu spent the first half of his career as a nonprofit executive, fundraiser, and finance director, working in both the healthcare and arts/cultural arenas of the nonprofit sector. He holds business degrees from Washington University and the University of Wisconsin, and he earned his CFRE credential in 1999.