Process Improvement in Public and Social Housing: Define the Problem

Define the problem seems like an easy enough idea right?  Something is not happening or working the way we want so we just define exactly what that problem is and then we can solve it.  Wrong!  From my experience in public housing and other jobs, we often jump to the solution without ever trying to define what the issue is to start with.  This is a dangerous mistake that can often lead us to implementing changes that do not produce the impact desired.  Let me ask you this. How many times have you started a project or gotten assigned a project where the solution has already been determined and you need to just make it happen?  Probably a lot.

Define:  In most process improvement methodologies, you are trained to not jump to conclusions about how to solve a problem without taking a deeper dive and examining it.  You should take the time to understand the problem and how bad it is.  You should be working hand in hand with the staff directly in the process to see where the pain points are within the process or program and how severe it is.  You should also ensure that you have the right players involved and that there is enough capacity to undertake a project to improve the situation.  If you jump into a project without the available team members there is a high likelihood it will fail.   Once you have a better hold on the cause of the problem, you should work to agree on a goal statement.  For example, if 40% of your annual reviews need to be mailed back out because they are missing signatures, you could simply state, “Our goal is to reduce the number of annual reviews coming back without signatures to 5%.”  Again a goal is an important part of the project.  So what do you do now after you verify is indeed a problem and that the staff needed are available to help work on a solution and you have a goal?  This is where several tools might help you drill down and get to the root cause and ensure a clear problem definition.

Tools:  SIPOC Diagram:  The SIPOC diagram gives you and the team a good high level look at the process.  That will include the suppliers, input into the process, the actual process, outputs and the customer.  Sometimes it helps to think about who the customer is in many of these process improvement projects.  It may not be who you think.  The customer might be the section 8 specialist who needs to finish the annual review.  It could be the compliance specialist who needs to receive a file in order to audit it.  Yes it could be the client who you are housing or even HUD.  Do not limit your thinking to regulators and tenants.  Here is a simplified SIPOC as an example:

Process Map: Once you have a high level SIPOC, you can drill down a little deeper to better understand the part of the process that is causing you problems.  For our example of the annual review packet that has to be re-mailed 40% of the time, maybe we focus on the part of the process from the time the packet is put together to the time it comes back. You can use a swimlane chart to really break it down.  Show every role involved in the process and see where all of the touch points are.  This might allow you to discover that certain roles involved are not qualified to be doing the mailings or creating forms.  Mapping this out might show you that it is not the form but the person creating the form.  A lot of good ideas can come out of putting the process on paper and dissecting it with a team of people who understand the process. Go to my earlier posts about how to write a process map.

Voice of the Customer: This is one of the most important parts of defining the problem but often overlooked.  Make sure you understand who the customer is in the process and what they are looking for.  That could be a range of people.  If it is the section 8 specialist who needs to get annual reviews done on time, sit down with this person and get a full understanding of what that person needs.  If it is the Section 8 manager who is upset about the postage costs going up, sit down and get a full set of specifications/requirements from this person.  This is not brain surgery but it is important.  Capture this information and store it so it is took into account in later phases of the project.  You can do interviews, focus groups, observation or any other technique you need to do but make sure you get the voice of the customer as you are defining your problem.

Project Charter: A project charter should allow you to clearly define what the problem is after doing some of the initial work outlined above.  You can clearly state what the problem is, what your goal is to fix it and the pre-work done ahead of time that serves as discovery for the rest of the project moving forward.  Putting down on paper what is going to happen allows the whole team to agree on the issue to be attacked and gives framework to a project.  Even more, the project sponsor should sign off on this document before the project moves forward. This helps ensure that everyone from the project manager to the project sponsor are focused and agrees about what problem is going to be attacked.

Conclusion: The act of defining a problem does not need to be complicated.  I am purely advocating for a more focused approach.  Think through the issue before jumping to a solution.  There are several more phases to come before you have your solution but at least now you are hunting with a purpose!  I will talk more about the next step which is Measure in my next blog.  Below you can see an example of a project charter.  Message me if you would like a template.

Example below.