How to Get Project Scope Data Collection Cranking

At the beginning of the scoping stage of projects, teams wrap their arms around a problem, asking all sorts of questions to validate whether the problem is really a problem and to quantify the magnitude of the problem to inform scope, including prioritization. Data collection/information gathering is a critical part of this stage.

A common approach to data/information gathering is that there are no bad questions. This gimmicky statement is simply untrue. There are information requests that can slow down or derail the effective scoping of a project. Indeed, data gathering should be handled with care and project leads should seek to facilitate appropriately the applicability and feasibility of data collection, while also promoting and ensuring inclusiveness across team members.

To ensure that information gathering is effective and efficient, we use three guiding tactics at Weave’s Digital Transformation Center:

1. Ensure that all the appropriate stakeholders are looped in and given the opportunity to contribute, while also placing a firm deadline for contributions. While the desire to move fast might incentivize project leads to keep the list of stakeholders small, a serious misstep is leaving out critical stakeholders that should be involved. I have found that including a wide breadth of stakeholders and setting a firm deadline for contributions is a good way to keep the train moving, with personal outreach to the most important stakeholders to facilitate feedback.
2. The objective of the project needs to be well defined. What are you trying to change because you are addressing the problem? Too often, teams meet and allow objective creep to seep in. Pretty soon, there is an incredible list of five things that will be impacted by the initiative. The better approach is to keep it simple: determine an unambiguously defined objective that everyone can align and agree upon. This will help refine and focus the data gathering effort. If you can’t make it past this point, you probably want to place the project in the parking lot until the objective is better understood or prioritized across stakeholders
3. Document and rigorously debate problem statements. Don’t accept unchecked stats. This is a scientific practitioner’s dream come true. For every problem statement, ask yourself, “How can I prove that this is a problem?” The answers to that question for each problem statement becomes the meat of your data gathering effort.

Data gathering at this stage should focus on achieving information sufficiency, which means obtaining enough or adequate data to inform the problem. (Side note: I love the word sufficiency as it relates to data, project or product management. It seems to encapsulate so well the principle of optimization, where any less still leaves more to be desired and any more is excessive). For complex or risky projects, data sufficiency will mean more careful analysis. An example of this would be the drug approval process with the FDA, which has a series of trials and approvals before wide-scale release is possible. Alternatively, simple and reversible projects would require much less information or data to best define the problem. As project teams focus on data sufficiency during the early scoping of an initiative, it will help them to ask the right questions and to collect the right data based on the objective of the initiative.

A two-axis effort-importance matrix can be used to map out your data gathering strategy. Of course, the easy ones to deal with are the high importance, low effort (low hanging fruit) and the low importance, high effort (candidates for discarding) quadrants. Experience will determine the cutoff point for low importance, low effort quadrant. That leaves the difficult one: high importance, high effort…

We have learned to approach this quadrant by asking the following questions:

1. Is the data readily available?
2. If not, how costly is the effort to get the data (including resources/time)?
3. What proxies might exist to inform the problem sufficiently?
4. How trustworthy is existing data?
5. What is the threshold of data quality required to inform this problem?

This quadrant is perhaps the biggest contributor to delays in scoping. I have found that establishing reasonable, but firm deadlines help, allowing for flexibility when flexibility is merited. However, the best way to move forward is to continually reflect on the concept of data sufficiency. Rather than delay progress, we constantly ask, “Is the data good enough to inform the problem at this stage?” If the answer is yes, we accept the risk/uncertainty and proceed. If the answer is no, we determine the plan of attack.

Although these steps are simple, they work. They are an integral part of our scoping framework at Weave and it has helped us to accelerate our ability to scope projects effectively and efficiently!