Com Dev Island Part 2

How organizational islands are formed

See first: Com Dev Island Part 1

Organizational islands aren't unique to Community Development, of course. They can occur in any type of organization and can be split off across divisions, teams, functional areas within teams, or even team members themselves.

In regard to Community Development specifically, and municipalities more generally, here are some of the ways I have seen islands form.

1. Physical Distance

When teams are not easily accessible to one another, they naturally move further apart. While the tools that remote teams use have improved over the years, they still place a barrier on communication and connection among team members.

Communities we have seen struggle the most in inter-departmental workflow and communication are those where the departments are located in separate buildings. Co-locating within the same building makes it possible to resolve issues face-to-face, encouraging quicker resolution to challenges. Meetings and discussions can also be performed more often and more rapidly as less planning is involved and others are able to stop by another department quickly to work things out.

The most efficient teams are not only located in the same building but on the same floor or even in the same open space as others. This not only allows for quick communication but also more familiarity with each other. Getting to know others in the workplace by passing them in the hall or break room helps humanize others you may only communicate with periodically.

As teams work more and more remote, it's less difficult to maintain these connections with those in your department through the use of daily "stand-up" meetings. However, for teams within your organization who have integrated processes with another but no daily contact, this approach does little to match the advantages of physical proximity. If remote work is a long-term approach, cross-team attendance in stand-ups can help bridge the gap.

Besides logistical issues, physical distance creates stress on team members when interdepartmental coordination is required. Simple challenges can seem like a 'can of worms' where merely approaching the other team will cause more challenges than it will solve. This pushes team members even further away from each other and results in decisions that fail to account for all stakeholders.

Lastly, physical distance can create a disjointed process for the customer. Applying for a permit at one building or floor, then being required to pay in another and possibly even coming back to pick-up the permit is highly inefficient. Many of these process issues can be resolved by technology but it requires cross-departmental cooperation which is something that may be a challenge to any organization already on islands.

2. Software Platform Variations

Another major cause of islands being formed between departments is when each use different software platforms that don't communicate.

In many municipalities it is common to see Finance, Utilities, Com Dev, Public Works, Parks, and Public Safety all using different systems. While there are often-times justifiable reasons each team chose the vendor they did, the array of systems limits insight across the enterprise for administrators.

One of the biggest challenges in an ERP search can be gaining consensus on a single platform across departments.

Many ERP vendors have a great financial management platform but do poorly to compete in other areas such as community development. Other vendors specialize in a specific domain like Com Dev, Fire, Public Safety, or Parks. While these vendors may sometimes offer a better product than ERP vendors for that specific domain, they may lack proper integration into the other products that are needed to connect your islands. There are vendors out there who do well in multiple domains, however.

Without proper integration between systems, you will be maintaining separate versions of common records such as parcel, accounts, and customers. This makes processes such as lien searches, FOIA requests, dependency approvals, business intelligence aggregation, or even basic record lookup and payment challenging.

Having worked on the software vendor side of the industry for so long, one of the most commonly overlooked requirements on RFP's in my opinion was the lack of detail and specificity included in integrations between systems and/or the lack of a required single solution. These are areas that not only need to be specified in an RFP but also defined to a level of detail that can be measured and graded during vendor demo's. There are many integrations that exist in the market that fall drastically short of their purpose. Having an experienced partner who can help guide you through this process is key to achieving the results your teams need to bridge these gaps.

Limiting platform variations can help promote cross-departmental visibility (including Business Intelligence) and interoperability which will reduce manual process steps and increase real-time communication and issue resolution. Achieving these goals helps manage cross-departmental dependencies, aligning your teams closer toward a single goal and moving the islands a little closer together.

3. Common Knowledge

Humans communicate and solve problems more effectively when we have common knowledge.

Take this excerpt from the Stanford Metaphysics Lab's study on the topic of Common Knowledge:

"Common knowledge is a phenomenon which underwrites much of social life. In order to communicate or otherwise coordinate their behavior successfully, individuals typically require mutual or common understandings or background knowledge. Indeed, if a particular interaction results in “failure”, the usual explanation for this is that the agents involved did not have the common knowledge that would have resulted in success. If a married couple are separated in a department store, they stand a good chance of finding one another because their common knowledge of each others’ tastes and experiences leads them each to look for the other in a part of the store both know that both would tend to frequent. Since the spouses both love cappuccino, each expects the other to go to the coffee bar, and they find one another. But in a less happy case, if a pedestrian causes a minor traffic jam by crossing against a red light, she explains her mistake as the result of her not noticing, and therefore not knowing, the status of the traffic signal that all the motorists knew. The spouses coordinate successfully given their common knowledge, while the pedestrian and the motorists miscoordinate as the result of a breakdown in common knowledge."

Read the rest here: https://plato.stanford.edu/entries/common-knowledge/

People or entities that lack common knowledge across departments often make assumptions and subsequent decisions poorly. Those in leadership positions who receive all of their information about a person or team from secondary sources typically make poor decisions that affect that individual or team. When an individual or team is constantly on the receiving end of misguided decisions, they become increasingly isolated as they lose trust for those in charge. Even if the secondary source appears to present information to leadership with good intentions and/or have credentials or experience (but not entirely related to the affected team) that seems to indicate sound judgment or character, they can misrepresent the fact of situations or background data that would have been necessary to achieve a good outcome. Community Development is a very complex domain that requires a lot of experience to understand the intricacies of it. Seeking out direct representation from domain subject matter experts within it provides the best opportunity to not only make the best decisions for the business unit but also keep you aligned with the mission of your organization, which is the mission of each department.

Leadership personnel aren't the only ones who can cause islands through lack of common knowledge, of course. Team members within each department can push their respective departments from each other through lack of common knowledge as well. Com Dev teams who don't take time to understand basic accounting principles, billing processes, public works processes and roles, public application process feedback, leadership guidance, and so on, can unnecessarily put themselves on an island within an organization by failing to understand all of the input and outputs, causes and effects of their department's decisions and actions.

By failing to gain better understanding of related processes, teams fail to see the impact of poor communication or impact on downline stakeholders. When teams share common knowledge, they know when business processes that they may be changing will affect other teams. Leaders who identify these possible intersections early on and bring in qualified representation from affected teams not only build a better process but move the island closer to others.

The public is often the most overlooked stakeholder in this area. Sharing common knowledge with the public, who is a department customer, is the only way to ensure that process changes actually improve service delivery. It's important that experience doesn't supersede active, recent feedback when considering the customers role in decisions. It's important to communicate with and survey the public to gain insight into the outcome of initiatives aimed at streamlining processes and providing better visibility. Anything short of that does not truly allow you to gain common knowledge with the public.

4. Power Struggles

In a lot of organizations, there is an undercurrent that pulls departments down or separates them further onto islands and that is power struggles.

Depending how departments and divisions are formed, a power struggle can be formed as department heads, management, or even team members try to position themselves with leverage within their department or organization.

Department leaders who are not open-minded can make decisions that purposefully are not inclusive of other departments and may even negatively affect other departments. This may be due to prior struggles where their department was steamrolled in decision-making processes and they are now attempting to defend against that, or it could simply be from personality differences between department heads. While there are a lot of potential reasons for the origin of these battles that are better left for organizational psychologists, the end result is the same. These power struggles do not advance the mission of the organization and will inevitably push departments further away from each other and cause extreme isolation.

Without getting into the psychology of these situations, one thing to be careful about is the response. While the best path forward may seem to be the removal of the people appearing to be the source of the issue, the real issues may lie elsewhere. If people felt they needed to defend or shield their teams against decisions negatively affecting them, a better approach is likely to first listen to their concerns and develop common knowledge. It's possible that they became defensive over time due to a recurring, barrage of one-sided organizational decisions that favored one team or department over the next.

Community Development departments, along with a few other teams can oftentimes be further down the power curve in many organizations where their work has been historically considered secondary to the mission of the organization and can sometimes even be looked at negatively due the controversial nature of ordinance enforcement within a community.

Some team members within these departments can also feel looked down upon by their peers who may have more formal education than them. Some inspectors for instance lack a post-secondary degree but instead have a vast amount of detailed understanding and technical expertise in the skilled trades. While they have studied, learned, worked, and excelled just as others within the organization have, sometimes a class system can form within an organization from stereotypes formed by those without the understanding of their intelligence and expertise, and the technical difficulty of their jobs.

Intake staff can feel similarly but are routinely required to process applications using a vast amount of critical-thinking abilities to account for the infinite amount of variability in project scopes and customer and regulatory requirements.

Still the members of these teams are left feeling invalidated for their work or under-appreciated by organizations as a whole. I have witnessed this first-hand and received this unfortunate feedback too many times across the country.

Cross-departmental training (common knowledge), open communication, and physical proximity, while not the only methods, are all keys to building mutual respect, which can go far to end power struggles on teams.

Lastly, it's important to understand that teams with external customers will have vastly different perspectives on decisions than ones with internal customers. If leaders or team members of departments seem resistant to changes that seem positive for other teams, it's important to find the differences between the departments that cause these to have a negative effect on them and communicate openly to reconcile them. This cooperation between teams is the endgame for true interoperability.

5. Lack of Interest

There are few issues that I believe are better solved with separation of ways with a team member but lack of interest has this potential.

Lack of interest is a major roadblock to efforts of preventing islands in an organization.

There are many reasons why a team member may lack interest and we won't explore all of these in this series but overcoming this is a necessary first step in any effort. I have unfortunately heard a single phrase many times across many municipal government departments that always had me deeply concerned and it was "that's their thing".

This mentality presents itself in different ways or phrases but the spirit of it is "us and them" or "theirs and ours". It's indicative of cultural issues where team members don't see their roles or departments as complementary of others. They don't see the organization as a unit, nor do they necessarily want to in cases.

Some individuals want to own a process and make it theirs. While ownership of a process in general can be great for onboarding, continual improvement, knowledge transfer, etc., it can be detrimental if the owner doesn't strive for integration with other process owners.

Some team members and even leaders simply lack the interest in integrating with other departments. They either lack greater and broader vision or even simply the motivation to undertake the efforts necessary to integrate their processes. These particular individuals love the island. They have volleyballs with faces drawn on them as friends.

Whatever the reason, lack of interest is among the first issues that should be addressed. Teams who are not all dedicated to a solution will not find one.

6. Return on Investment

Islands are sometimes created when investment in a department isn't commensurate to their value.

This issue plagues both the public and private sector vendors and Com Dev is no exception.

In a lot of communities, Community Development departments are self-sustaining. Many generate enough in application, review, and inspection fees to support their annual budgets. In fact, some adopt a formula developed by the ICC which ties fee calculation dynamically to the number of permits issued, the annual budget, and a local construction cost adjustment. This produces a factor that construction value for each permit is multiplied by to determine the permit fees. In this way, without having to seek new fee adoption each year, departments can almost always assure that they are self-funded.

Many communities are realizing the benefits of strong Community and Economic Development teams in attracting residents, new development, and commerce to their communities. Some however, despite all of the data, still look at Com Dev as overhead or a secondary business unit with little to no return on investment. These are often communities that are rural, stagnant, or built-out but can be others as well.

On the vendor side, many software vendors see Community Development software as a loss-leader. Having a good offering can oftentimes get them in the door in a community where they can later sell the applications that drive their margins such as financial management.

This isn't to say that these vendors don't invest in Com Dev software within their organizations, but many do not put similar resources into this area of their product line or professional services teams. It's very easy to see while sitting through demonstrations which vendors not only understand Com Dev but have a passion for it vs ones who maintain an application to fill out their product line.

This delta in allocation of resources, organizational opportunities and advancement, representation, and even compensation within some vendors and communities drives a major stake in between teams that are all necessary to success.

One issue is that because historically CD was not always valued on the municipal side, funding for Com Dev software was not always allocated sufficiently and not comparable to that of finance or other teams. In response, software vendors were forced to price only what the market could bare for Com Dev software. This in turn resulted in less revenue for Com Dev software being totally eclipsed by that of FM software. Because income is lower, representation, resources, and development of that product line was limited by most software vendors. This resulted in a slower development and release of critical functionality for many Com Dev teams.

What we are seeing now is that Com Dev teams have shown their importance and return on investment within communities. Many have even taken Economic Development under their umbrella and directors are more highly skilled in drawing investment in their communities. Leaders have begun to realize the importance of strong data to serve their business intelligence systems, gain insights on economic development initiatives, and use it to make more intelligent decisions.

Recently, a segment of municipal software that once only served a reactive permitting process now is expected to manage Projects, Planning, Zoning, Code Enforcement, Rental Housing, Business Licenses, Online Permits and Inspections, Electronic Plan Review, Engineering, Bonds and Escrow Management, CDBG Grant Funding, Spatial Integrations, Document Management and Retention Guidelines, and much more.

A modern Com Dev system is really about 6-8 systems in one.

In response, new companies have begun popping up left and right to fulfill these needs while existing vendors are rushing to continue innovating, all while trying to remain competitive on pricing.

Community Development has already begun driving technical innovations through integrations and automations within communities and return high-value data to those who have invested properly in it. This need will likely continue and will force both vendors and municipalities to take a closer look at where resources are best spent in their organizations and potentially help connect islands back together.

Be on the lookout for Part 3 where we will dive into how to connect islands back to each other.

Also, feel free to reach out and share your stories and experiences or feedback regarding this series at kkeyes@munivate.com. I'd love to hear from you.

Munivate offers a range of professional services to Community Development teams such as software procurement and demo consulting to change management, project management, training, and software administration. Message us to learn more at info@munivate.com!