The way I see it, software project management is primarily about leadership. It's being responsible for taking a project from concept to implementation. This requires solving a problem. And steering a team towards an implemented solution. 

This is no trivial task. Solving a problem requires finding a problem that can be solved with software. Hosting such software. And improving value metrics for users. 

Here comes the first art of project management. Problem finding. You and your team want to know what to solve for. And how to get there.

The project manager has to build a narrative of a problem. Draw a map pointing towards a solution. And lead the team to implementation. Resembling how an expedition crew would get to the top of a hill. 

For that narrative, the PM will deal with all sorts of considerations. Instructions, biases, traditions, hierarchies, levels of expertise.You name it, the PM must navigate that complexity. Their narrative should move people towards objectives. 

Good problem finding looks like a confident team. And a good relationship with both internal and external clients. People are not confused about their place in the project. And understand its direction.

Thus, problem finding should to be a priority. And must be refined along the way. Good problem finding will make you faster. And reduce your risk of over-rushing.

The second art of project management is architecture design. The world of software is as vast as it gets. You and your team will have to brainstorm and pick many components. These are some key questions you probably want to answer.

Software from scratch or existing solution? Software from scratch can be quickly developed. But it will have unique infrastructure needs. You'll have to host that complexity. 

Readiness or long term? If you aim for the long term, elegant code seems like a better fit. It produces less downstream trash. But short, dirty solutions are a viable option. 

Compact or distributed? Distributed, modular designs increase the number of connected systems. Allowing each to be hosted and scaled individually. But can be harder to track than monolithic, central designs.

What is the software history of the organization? You might have to stick to the client's tool stack. Your team will require flexibility. And willingness to learn old technology.

What is your version control strategy? As a project manager, Git is your best friend. You will benefit from knowing your versions. And success metrics related to each.

I believe I have stumbled upon a growing, untapped market shaped by labor trends and emerging technologies: the market of non-emergency calls directed to government. Here, I share my thoughts and a possible business opportunity sprouting from it. I am looking for advice on whether or not to pursue it and corrections on the logic I am about to show you.

Every year, citizens call the government millions of times for non-emergency situations. Situations that don't require an emergency response. Those calls start from all sorts of phones and end in government call-centers, who solve the situation by providing information, dispatching units, or adding a service request to a city department. Here is the problem: call-centers are losing people. The US is currently transforming in such a way, that call-center staff is becoming rarer and more specialized. And those who survive the environment are becoming a proud few. Already, bot assistants are being used to respond to non-emergency calls. In an effort to reduce the burden on staff. 

The quality of voice bots just went through a breakthrough. Never has the technology been so developed and so human like. Deployment is trivial. And companies are competing for who can provide the best bot call-center experience. Add to that, we could be looking at millions of minutes of non-emergency conversation. Bots seem to be on route to further expand and answer more non-emergency calls. The market might be big enough to sustain a community of developers, who look to serve at least two clients: citizens and government. Citizens looking for city services and information. And government looking to respond to citizen petitions (using the most diverse software). Each one with it's own challenges. My question is, is it wise to develop non-emergency bot technology and community? Is it worth it?  

And here is a breakdown of the possible size of the market. I try to provide two extremes. 

-Annually, around 240 million calls are made to 911. Of these, I'll assume (rather conservatively) that 40% to 60% are non-emergency, translating to approximately 96 to 144 million non-emergency calls each year. 

-311 is smaller, and has not been strictly implemented nationally. Low usage areas can experience 0.2 calls per person per year. And high usage systems like NYC311 can experience up to 4 calls per person per year. I'll assume that 66 to 660 million 311 non-emergency calls happen annually.

-Combining 911 and 311 estimates, the total number of non-emergency calls ranges from 162 to 804 million annually.

-I'll assume the average call duration for both 911 and 311 is between 2 to 5 minutes.

-Resulting in the large range of 324 to 4,020 million minutes of non-emergency calls every year.

-Modern voice bot development ranges from $0.08 to $0.3 per minute. This is not considering your own infrastructure. Nor operational expenses.

The market could be large. The retiring workforce is leaving a large blank, already being filled by bots. It seems like the US will trend towards non-emergency bots. 

The trend is clear. Cities all over the world are implementing 311 systems. This is not a surprise: there is value in letting citizens inform the work that a city must do. It saves oversight costs. Instead of having your department of sanitation track and check every restaurant for rats, you can rely on citizens to point where the rats are. Same with many other city needs.

Chicago, New York, Los Angeles, Toronto, and plenty of other large and medium north american cities have 311 systems in place. Yet, there is no clear market leader. Cities have developed custom solutions to meet their needs. This, I believe, occurs because local government has strict internal rules and regulations that force software customization. That is why you have many consultancy groups implementing custom solutions even when 311 needs don't largely defer. Salesforce is a tool of preference. In-house Microsoft too.

In the large landscape of 311 solutions, some are lackadaisical. Call Centers are expensive. Self-service applications are imprecise when assigning service requests to city departments. Backend models are convoluted. And government operators cannot handle system change requests made by other departments. The problem is that government rarely pursues 311 improvement, even when it is easy to achieve.

Take Chicago as example. Right now, Chicago has the possibility of modernizing their 311 Salesforce system by leveraging Agentforce to create bots that better route service requests and answer calls from citizens. Chicago could be saving big in Call Center operations, and could be working in efficient service request routing. But the Office of Emergency Management and Communications (OEMC), owner of the Chi311, has a full plate managing the platform and is short in staff. Even if executives at OEMC decided to modernize Chi311, bureaucratic barriers impede and discourage such work. Local government is not ready for innovation. It's immature and understaffed.

So, how do you flood this millionaire, up for grabs market? I don't know. But here is an idea.

Let's start by building something together. If you are interested in improving 311, contact me. I think it will happen with or without me or you. Because the market is too large, and it keeps growing worldwide. I believe this is a key window in time. One that correlates with other government technology windows.

I have recently covered how local public health is inflexible and why it hurts. Here I try to cover how to incentivize flexibility.

The list of negatives is blunt and long. But I believe we can do plenty about it. It is up to the people at local public health to accept the challenge of culture change.

These incentives feel kind and professional. But it's serious business.

Increase accountability, increase freedom. In local public health there is a lot of busy work and bureaucratic barriers. The idea here is to lift barriers of work while demanding more out of the workforce. Let the workforce use their best abilities to achieve the strategy and vision of the organization. Make them owners of important projects. And request KPIs of their work.

Local public health must find a balance. Only increasing accountability might lead to a pressured workforce that have their hands tied. And only increasing freedom might lead the workforce to be unaccountable.

No more bullying. First things first: no yelling, no belittling. No trampling over others. It quickly burns people. It makes them less efficient at work. Bullying happens. And folks tend to sugar coat it. Confrontations and bad behaviors slide. Let your workforce know that they can reach out for help.

Encourage numbers. Specially KPIs. Encourage the build of data pipelines to feed those KPIs. Abide by them and make them your guiding star. Allow the workforce to try creative ways to improve those KPIs. Remind the workforce continuously about their status. And set thresholds to know what is acceptable and what is not.

Pass the monkey. If you are in public health leadership, you are probably dealing with plenty of projects, changing priorities, and moving deadlines. And also you are probably dealing with other administrative tasks. Like time keeping. Pass tasks to your employees. Let them handle projects globally. They can feed the projects and free time for you to pursue other, bigger projects.

Discourage bureaucracy. Local public health is full of sign offs, witnesses, official communications, and other approval mechanisms. You need to get through a lot of thumbs up to make a project happen. Why do we need so many layers of approval? The way I see it, approvals are a way folks tie themselves to a process to gain relevance. Individuals win leverage but the organization loses efficiency. Approvals could instead become feedback. Making sure that everyone who gave feedback is noted. It seems better to reserve approvals for the bigger decisions.

l have been working in local public health for some time now. 

And throughout these months, I have seen a plethora of organizational issues, hindering the efficiency of our organization and lowering morale of staff.  

Many of these issues are thoroughly covered in business literature. That is, these are not new, affect plenty of other organizations and, most importantly, can be overcomed. 

After plenty of conversations and much sharing with other members, I felt compelled to summarize my observations to further share and, hopefully, empower staff to find solutions. 

My premise is this: kinder, more purposeful work is possible. And it can be achieved by loosening up the tight organizational rules that govern us. The way I see it, all of these organizational issues refer to flexibility. And yes, government can be more flexible. We have to start by acknowledging.

The Public Health Workforce Interests and Needs Survey (PH WINS) is the most complete scan of the US Public Health workforce. They see some of the pain points I have seen. I recommend checking their work. 

Let’s get right into it. I see three major organizational issues.

We are bureaucratic. Our roles are strict. And work gets crazy.

Bureaucratic, because we have to get through many approval layers when we are pushing for projects. These approval layers slow down projects and do not necessarily increase the quality of our product. Strict roles, because our roles tightly define what we are to do and who we are to communicate with. And crazy, because we can multi-task, feel tired, or feel lost.

Out of these large problems I see other smaller problems sprout.

Some lack work. There are plenty of development pathways in undeveloped Public Health organizations. Plenty to do. But work is so cumbersome and restricted that there are few routes to create and deprecate work. Automatization is hard to pull-off. And people defend with teeth and nails the little work they own. There is a tight ownership grip.

Bureaucracy is alive and kicking. We have to go through a multitude of approvals to push for projects. Plenty of sign-offs, good-to-go’s, and thumbs up, no matter how small the project is. The more people involved in approval, the better. Witnesses are higly considered.

We have decision bottlenecks. The people who must approve projects are overwhelmed, thus working as bottlenecks that delay projects.

It’s crazy sometimes. Some working long hours. Constantly running. Eyes red due to being tired. Bad moods. Many multitasking, putting out fires in many places at the same time. Many answering to the latest, most recent thread, leaving little time for long term objectives. Lots of ASAPs.

Death by power-point. We often want detailed requirements and documentation; detailed meeting notes, email threads, and workflows; proofs of conversations and decisions. These are important we are told. Yet, there is little discussion on why such thoroughness is required, or who the audience reading these documents is.

Culture of silence. It is highly regarded to not stir the pot. As long as you stay in your lane, you won’t get in trouble. Try not to question commands. The rule of fist works. So if I outrank you, it is better for you to follow the orders.

Status quo. Plenty look to lay low, stay out of trouble, and clock out as soon as possible. There is resistance to new, different, tasks. If you are an executive, you might face staff saying no to your requests. There is little room for staff to find ways to improve processes, and creativity is not highly considered.

Role stiffness. You were hired to do one job, and one job you will probably do. It's hard to push for a better fit.

Little trust. Executives and managers want to be present in most if not all decisions. Not fully trusting the decision making of staff. If staff gets in trouble, they will too. Communication outside the organization must be careful and approved first. When you come with a question or a new idea, you might raise eyebrows.

There is little discussion on how success looks like. We tend to invest little time on strategy and vision. Good work is not much discussed.

Watch who you talk to. Heads tend to talk to heads, and staff tends to talk to staff. Vertical communication is discouraged. If you want to have a conversation with other departments, make sure to follow proper communication channels.

Inter-departmental data collaboration is cumbersome. Data sharing between bureaus requires data agreements and involvement of heads. Shared contracts are cumbersome too, specially when bureaus manage their own money. 

Meetings oh meetings. There are plenty of them and they can feel unproductive.

No intrapreneurs. As far as I have been at Public health, I haven’t heard the word intrapreneur being mentioned. That is, there is little room for high risk high reward projects led by an internal visionary. Intrapreneurs are necessary for organizations that want to innovate.

Closing remarks: the good.

Public health is honorable. The staff is clearly driven by a spirit of sociability. Members want to do public good, a great force that provides plenty of energy.

Public health must reduce burnout. It's killing us. It is up to us to find the incentives that will reduce our burnout. And implement them. I recognize we will become more flexible as we implement burnout-reducing strategies happens.

I say we start by addressing the lingering issues I mention. Having honest, open discussions about our organizational practices. Identifying practices that are hurtful, and setting behavior expectations. At the same time, develop a better understanding of what good work means, empower the right staff, discourage bureaucratic behaviors, and request more out of the workforce.