Thirty days is enough to test an ONA pilot on one process. You can learn whether useful signals are accumulating, where the data has gaps, and which network pattern deserves a check with employees. A month will not produce a complete company map or prove that an intervention worked.
A useful pilot therefore starts before anyone draws a network. The team chooses one work question, sets the network boundary, and agrees on the decision it expects to make. Collection, analysis, and reporting all follow from that choice.
What a 30-day ONA pilot can establish
Organizational network analysis represents people or groups as nodes and a defined work relationship as a tie. A survey might show whom people approach for expertise. Communication metadata records contact patterns. Active work signals capture a particular action such as help, an idea, or a reported problem. These methods answer different questions.
In a bounded team with frequent interactions, a month may reveal recurring connections, gaps between groups, or dependence on a few coordinators. With a larger scope, low-frequency work, or limited participation, the result may be more modest: proof that the setup works and a list of questions for the next phase.
The month-end report should state four things plainly: what was observed, how much of the relevant network was visible, what remains uncertain, and what the team will investigate next.
Before the pilot
Start with a decision
Choose a question connected to work. For example:
- Where should knowledge about recurring customer issues go next?
- Which roles need to connect during a product launch?
- Does a critical process depend on one person to coordinate several groups?
- Are ideas and problem reports reaching the teams that can act on them?
“Understand collaboration” is too broad. A focused question determines the people, period, tie type, and evidence that belong in the pilot.
Define the network boundary and the tie
Write down who is in scope and why: one team, a project, a location, or the groups involved in an end-to-end process. Then define the relationship. Advice, help, information exchange, and idea flow are not interchangeable.
Agneessens and Labianca's review connects the network boundary, formal structures, sampling, approach to participants, and feedback plan to the original research question. Those decisions need to align before collection begins, not after the map appears.
Choose a source and explain it
A short network survey asks about a tie directly but depends on participation and recall. Work-system metadata offers scale without explaining what a contact meant. Actions in a platform preserve the context of a particular event but miss work recorded elsewhere.
Before launch, explain the purpose, data source, retention period, audience, and limits on use. Collect the least personal data needed for the question. Legal and organizational requirements vary, so involve the people responsible for privacy, legal review, HR, and employee representation in your organization.
Decide what a useful result looks like
Choose a few indicators before opening the map: repeated ties across a handoff, representation of the relevant groups, or the same role connecting several teams. Record the blind spots beside them—systems outside the pilot, low-frequency work, membership changes, and incomplete participation.
The 30-day timeline
| Timing | Focus | What to do | Deliverable |
|---|---|---|---|
| Days 1–3 | Scope | Confirm the question, boundary, tie, method, owners, access rules, and employee explanation. Check the roster and baseline context. | One-page brief and approved collection plan |
| Days 4–7 | Launch | Bring the group into the pilot. Make sure people understand the question and can complete the requested action. Run the first quality check. | Live pilot and issue log |
| Days 8–14 | Coverage | Compare participation or signal volume across the groups and roles that matter. Fix access, wording, or workflow problems before interpreting the network. | Coverage note and documented adjustments |
| Days 15–21 | Patterns | Review recurring ties, themes, cross-group connections, and possible concentration around a process. Keep observations separate from explanations. | Short list of patterns and open questions |
| Days 22–27 | Validation | Discuss the patterns with employees and managers. Compare them with handoffs, decision paths, and records of recurring issues. | Validated findings, caveats, and candidate actions |
| Days 28–30 | Decision | Prepare a short report covering method, scope, coverage, findings, limits, and one or two next steps. Assign owners and a follow-up measure. | Pilot readout and action plan |
If the evidence is sparse, extend observation or narrow the question. Do not fill gaps with assumptions to meet the day-30 deadline.
How to read early network patterns
Keep three levels separate:
- Observed signal. What the method recorded. Help-related actions, for example, repeatedly connected two teams during the pilot.
- Hypothesis. What the pattern may mean. The teams might share a dependency, with one role carrying work across the boundary.
- Management conclusion. What the organization decides after checking the hypothesis with people and process evidence—perhaps naming a handoff owner or creating direct contact between the teams.
The same pattern can support several explanations. A person with many ties may be a valuable connector, hold a role that naturally receives requests, or be compensating for a broken process. A group with few ties may be appropriately specialized, absent from the selected system, or underrepresented in collection.
Missing survey data need special attention. In a simulation study, Huang, Zhang, and Li found that ignoring tie non-response could underestimate network degree and centralization; the effect varied with network structure and the missingness conditions. No single response rate makes every network map valid. Report coverage for the groups that matter to the decision.
Later comparisons should use the same boundary and method. One month describes a particular period. It does not establish that a tie is stable or that a change caused the next result.
Common ONA pilot mistakes
Trying to map the whole company
A large boundary adds launch and interpretation work. Start with a process or cross-functional group. Expand after the question, evidence, and decision fit together.
Treating every interaction as the same tie
A message, expertise request, thank-you, and idea submission carry different meanings. Do not combine them into a general “collaboration score” without a clear definition.
Reading centrality as performance
Network metrics describe a position in the selected network. They do not independently measure quality, expertise, leadership potential, or employee value.
Missing uneven coverage
If one location, shift, or role is less visible in the source, the map partly reflects collection. Show the gap and fix access or sampling where possible.
Ending with a map
For each proposed action, identify the observed pattern behind it, the owner, and the evidence that would show whether the change helped.
How HiveHR supports the pilot
In HiveHR, organizational signals come from actions employees take inside the platform. A participant can thank a colleague for specific help, suggest an idea, or report a work problem. Repeated actions help a team examine where contributions and issues appear within the selected process.
If enough relevant activity accumulates during the month, the team gets an initial network view and hypotheses to validate. Sparse data are useful too: they show that the boundary, collection conditions, or observation period needs work.
Use our guide to key person dependency when ties appear concentrated. The article on informal leaders explains why centrality alone does not establish influence.
Frequently asked questions
Can you run organizational network analysis in 30 days?
You can run a bounded pilot in 30 days if the question, method, approvals, and collection setup are ready. The result is an initial view and a test of data quality, not a guaranteed complete network map.
What should an ONA pilot measure?
Measure one clearly defined work relationship tied to a decision, such as requests for expertise, help with a process, or information flow between specified teams.
How many employees should take part in an ONA survey?
There is no universal sample size or response threshold. The needed coverage depends on the boundary, network size, tie type, and analysis. Show who is represented and how non-response limits the result.
What data can organizational network analysis use?
ONA may use network surveys, interaction metadata from work systems, or explicit work actions captured in a platform. Each source has blind spots that belong in the report.
What should an ONA report include?
Include the question, boundary, method, observation period, coverage, patterns, limitations, validation work, and proposed action.
Does HiveHR create a complete map of every workplace relationship?
No. Its initial view is based on actions recorded in the platform, including recognition, ideas, and problem reports. It does not cover every workplace interaction.
Start the pilot with one question
Choose a process that needs a more reliable connection and run a 30-day HiveHR pilot. On day 30, make one testable decision: what will change, who owns it, and when the team will check the signal again.
Sources
- Agneessens, F., & Labianca, G. (2022). Collecting survey-based social network information in work organizations. Social Networks, 68, 31–47.
- Huang, F., Zhang, M., & Li, Y. (2019). A Comparison Study of Tie Non-response Treatments in Social Networks Analysis. Frontiers in Psychology, 9, 2766.
- Kossinets, G. (2006). Effects of Missing Data in Social Networks. Social Networks, 28(3), 247–268.
- Cross, R. What Is Organizational Network Analysis (ONA)? Connected Commons.