10 Basic Suggestions for Planning and Managing Data Intensive Projects
Introduction
If you’re a project manager you’ve probably read articles or attended seminars titled something like “Why Projects Fail.” I’ve written stuff like that myself.
When you are faced with planning or managing a “data intensive project,” is there anything in particular you need to keep in mind about this type of project that might help make your project a success?
What follows was written from the perspective of a project manager with experience where a primary project focus has usually been on generating, managing, transforming, or presenting data of various kinds.
There’s nothing really new here. If you have any kind of project management experience you’ll recognize a lot of what follows. Yet it pays to always keep these things in mind since you’ll need to explain what you’re doing — and why — not just to your team but to all your project’s stakeholders.
Here are my “ten basic suggestions”:
- Don’t let tools drive your policy.
- Have a plan and be prepared to change it.
- Know your stakeholders.
- Be transparent.
- Keep track of where you are and where you’re going.
- Be honest about the costs.
- Stay human.
- Support collaboration.
- Always be thinking about boundaries.
- Understand where the data comes from and where it’s going.
1. Don’t let tools drive your policy.
It’s tempting to want to take advantage of the increasingly powerful tools that are available for harvesting, manipulating, analyzing, and presenting data. We obviously have the ability to process and analyze data in ways far superior to what was possible a few short years ago. Still, it’s important not to succumb to the “new shiny object” siren song if it distracts you from doing what needs to be done using the tools already in hand. Also, try to avoid the “When all you have is a hammer everything looks like a nail” trap. Make sure the tool matches the task. This is as true now as it was 30 years ago.
2. Have a plan — and be ready to change it.
Regardless of what project-management “religion” you belong to you need to be able to articulate what you’re trying to accomplish and what the steps are that are needed to take you there. And, you need to be able to share this plan with your team and your stakeholders in a language they understand. At the same time, plans change. It’s just the way things are. The client’s mind changes, sequesters happen, a critical team member leaves, a plane crashes into a building. Remember that your goal is not to preserve “the plan,” your goal is to satisfy the client’s requirements. Also, if your plan is so complex and detailed that just keeping it up-to-date takes your attention away from managing the work, watch out!
3. Know your stakeholders.
“Stakeholder involvement” is another traditional project management success driver especially when you define “stakeholder” as any individual or group that influences the path data take in their lifecycle from the point of creation to usage, replacement, or retirement. Stakeholders won’t always be friends, but you know what they say about keeping friends and enemies “close.”
4. Be transparent.
The opposite of “open” is “closed.” If the goal of your project is to make data open, accessible, and/or useful, then the processes by which this is accomplished may also need to be open. Too much secrecy in a project — especially at the beginning when requirements are being established — can lead to mistrust, inefficiency, and resistance later on. I am reminded of a case study interview I once conducted for a project with a known but knowledgeable critic of my client’s project. “No one ever asked me,” she told me angrily after I finally managed to secure an interview to get her advice. As a result we lost her valuable input.
5. Keep track of where you are and where you’re going.
This “tracking” requirement goes hand-in-hand with the project objectives and the project plan. You need to stay on top of knowing who’s doing what, what needs to be done next, and whether you need to change anything about the project. With data intensive projects you also need some measurement of how the data or data-based deliverables stand at any given time. Progress reporting can’t just focus on schedule maintenance and resource reporting. You also need to track how the data and associated processes and services are progressing as well, especially when you are trying to deliver useful functionality on a regular basis.
6. Be honest about the costs.
Whatever the project setting, be it government, private sector, or nonprofit, resources to perform and manage the data project will need to be estimated, allocated, requisitioned, assigned, and or purchased. One of the most basic definitions of a project manager’s responsibility is making sure the resources (e.g., people, technology, systems, data etc.) are appropriately assigned and managed. Even if no additional resources are budgeted for project — a not unheard of situation especially in government — resources will have to be begged for, borrowed, or stolen. The project manager will be responsible for how resources are managed and how they contribute to project success — ideally “within budget,” however that is defined.
7. Stay human.
No matter how highly automated or algorithmically focused the data project becomes it’s always necessary to keep in mind the human element associated with each piece of data, software, or process. Even when a software release management process is moved to the cloud and its workflow is automated, some human oversight — and communication about the status of the process — will be needed. One of the most important reasons for maintaining the human role in project communication has already been mentioned: when plans change, humans will have to address discrepancies between the plan and what actually happens.
8. Support collaboration.
Team members will need to share information and work together on common tasks. Ideally a common platform for communication and sharing information will be available to all those involved in the project. In reality different teams will most likely use different tools to support different work streams since the information sharing needs of software developers will be different from the needs of executives or marketers. Still, there will need to be agreement on a system via which all team members and stakeholders can communicate. An example might be email or messaging via an Internet-based collaboration tool. This practice must still allow for the specialized collaboration needs of different teams, for example, pre-release testing versus post release user support.
9. Think about boundaries.
Many “open data” programs are initiated in response to a desire to open up data assets for public use via portals, analytical and visualization tools, and API’s. It’s often found that staff members — “internal users” — are also heavy users of easy to use open data systems as well. Thinking about the similarities and differences between internal and external users is something that needs to be incorporated into project planning right from the start. Will the same data access systems and services support both groups? If not, what are the schedule and research implications if the two groups have different needs? Also, what are the implications of having multiple organizations within the organization having responsibility for the data that will be made available through the open data program? Do relationships with these internal groups need to be managed individually? Are there standards or other data transformations processes that will need to be implemented with different data sources? Such “boundary” issues as these — physical, organizational, technical, and political — will need to be considered when drafting the project plan.
10. Understand where the data comes from and where it’s going.
Executive management will be most effective if it understands what processes and transformations will be made to the data as it progresses from initial capture through delivery and retirement. The project manager will need to make sure that management has this understanding. This may be one of the most serious challenges faced by the project manager given that data flow within organizations has for so long been seen as an IT concern.
Conclusions
In the above list I have skipped over many important details given my focus on how generic project management concerns can be adapted to planning and managing projects designed to make make data more accessible and useful.
It is also impossible for the project manager to ignore how data management and data governance are handled in the organization as a whole. An individual project cannot be expected to change how the organization manages data overnight. Part of the project planning process must therefore include an assessment of the organization’s ongoing data management and governance practices and how they interact with the goals of the individual project.
Copyright (c) 2015 by Dennis D. McDonald. For articles like this scroll down. For information about my consulting go here.
