What is software consulting? Software consulting can mean many different things to different people. For some it may be writing code to a specification. For others it may be architecting a system to fulfill a set of requirements. This article will show the what and more importantly the why of my focus as a software consultant. At each turn I will explain why I choose to focus on a particular subject, this way you can decide if it is important for you when looking at software consultancy. 

Broader Picture

My number one goal is to deliver solutions that solve the problem space in the best and quickest possible manner. In order to do this I am always stepping back and trying to look at the overall picture. This picture is more than the current problem, it includes the:

• Technology platforms
• People creating, managing, and testing those platforms
• Problem space
• People having problems
• People developing solutions

This list is weighted towards the people for a very important reason. If I can’t sympathize, or better yet empathize, with everyone involved I feel like an outsider dictating solutions that the team members and end users may not embrace.

Integrating with the Team

The first goal is to get as integrated with the team as possible and at all levels that are appropriate. This is not something to limit to a given period of time, but will happen over the course of the entire project. Showing care for everyone involved will help create that broad picture and allow for tighter bonds between the work and the people. Depending on the team size and with which parts of the business are affected, it can be a very daunting task. Taking notes on everyone’s names and what they care about is a good way to keep everything straight. I also do all of my meetings virtually, so taking screenshots of those involved to match faces and names helps as well.

Keeping people's cares at the top of my mind (instead of only tracking what they do) will help build a picture of the broader team. Following the cares and concerns of each teammate will also mean staying consistent with everyone, from “C” level executives to the development team to the affected users. While satisfying everyone's concerns will be impossible, the acknowledgement and explanation of why their cares are or aren’t being met is invaluable. Helping others understand goes a very long way in gaining acceptance for any solution.

This approach means the software consultant is not the knight in shining armor who saves the day. A software consultant is the expert who helps the team become the savior.

A software consultant is the expert who helps the team become the savior.

Depending on the team, work styles may need to be adjusted. Some teams are head strong and have natural leaders. In these cases, support those natural leaders and feed them information they need to get to a great solution. Other teams may not have a leader, and stepping in to fill that role is the only way forward. These are just a couple of examples of team dynamics, but the overall idea is to figure out what role the software consultant should be and then become that person.

While having a high level of team integration is the first goal the most important piece is to understand the problem or problems they are trying to solve.

Understanding the Problem

For anyone trying to solve a problem, the problem must be understood. While the software consultants job is to solve problems with technology, it is usually not a technical problem. Looking at the problem only from a technological standpoint the most important pieces may be lost. There is almost always a person or group of people who are being affected by the problem.

This starts by being empathetic to the people having the problem. True understanding begins with how the problem is affecting those involved. These people can be more than an end user. It can include the development team, the stakeholders, or anyone in between. The problem can be much more than was presented originally.

Let’s say you are brought in to develop a widget within a given period of time. Knowing what that widget is solving is more important than the building of it. Only focusing on the what instead of the why will give the whole project tunnel vision of two things. What the widget is and when it needs delivered. The problem with this is if either of those assumptions are incorrect, the project will be filled with minefields waiting in the dark unexplored corners. This is why team integration is so important.

Part of the problem that needs solving could be the team itself. While the software consultant may not have been hired to help solve team dynamics, it may be in everyone’s best interests. This doesn’t mean coming in and blasting new processes or dictating anything. Merely pointing out possible issues and then letting the team members decide if there are issues and how to solve them. Stepping back and self-empowering the team can breath new life into problems that were not seen or known. Being deep inside these issues day-to-day makes them difficult to see for existing team members. Having an outside perspective can make it easier to see and call attention to these issues. Always remember to be empathetic to the team member’s position as coming across too strong can have the opposite effect. Gathering information on the project/problem at hand is the perfect vehicle for helping the team become stronger.

Stepping back and self-empowering the team can breath new life into problems that were not seen or known.

The more information that is gathered the clearer the problem becomes. This means taking input from many people even if the user of the solution is one person. Gathering information from the end users, stakeholders, developers, testers, 3rd party integrators, and anyone else that may have a different perspective can shine a light on something a smaller subset would not. Some of these informers may help easily and freely, others may need more prompting. Asking questions, walking through the problem, and posing potential solutions are quick ways to help extra the data needed.

Having gathered information from many team members means that the solution is based on everyone involved. Being able to say why a certain decision was made can be traced back to an individual’s needs or wants. Making it a whole team solution is another great way to gain acceptance.

Once all the data has been collected, digesting all of the disparate thoughts and ideas into one collective picture can help with finding a path to a solution. If the solution was already given, having this understanding will help in implementing the solution. 

Solving the Problem

Instead of having been told what the solution is, having an understanding of the problem can open paths not previously thought of. Having an outside perspective can add a fresh new view.

The initial problem solving work can be and probably should be done in isolation. During the data gathering process, solutions may have been presented. While these are valuable for understanding, they may be clouded by a more narrow vision of the problem space. Focus on delivering what is needed vs what is wanted. This can possibly simplify the solution by focusing on the largest issues of the problem. 

Finding more than one approach to a problem can shine a light on a path forward. Logically thinking through the problem, and attacking it from different perspectives is a great way to troubleshoot. If the whole problem space is too large, break it up into smaller pieces that can be tackled one at a time. While working through these different ideas, watch for ones that strike a vein.

Determine the most viable solution depending on the requirements and other data that was gathered. Validate the solution for viability. This is where bringing the solution back to the team is the best answer.

Instead of relying on a large group to come up with a solution, having a proposed solution that can be dissected offers a shortcut. With this proposed solution it is good to have visuals and supporting data to help get the idea across in a short amount of time. Having fallback options and tangent ideas are another good way to drive the conversation. However, spending too much time on this proposal can be counterproductive.

The team may throw the idea out and come up with something completely different. The proposed solution is only there to start the conversation, not to end it. Being too attached to it can be detrimental to determining the best solution. When presenting, new information that was forgotten or missed can come to the surface. Make sure to capture this in order to make any modifications needed.

Giving the presentation in two groups can help manage the meeting from going too far off the rails. Presenting to stakeholders first allows any changes to occur based on business requirements. Then presenting to the development team allows any changes to be made based on technical requirements. This process may take a couple of iterations in order to solidify the overall solution.

Enabling the Solution

Once a solution has been agreed upon by the greater team it is time to implement it. Whether the software consultant is directly involved in developing the solution or not, the solution should just not be thrown over a wall for the development team to figure out in isolation. They will need to not only know the what but the why of what they are implementing.

Break the solution down into small bite sized pieces, or stories, that deliver some kind of business value. Being able to relate it back to some business value will mean that someone will be able to test what is being delivered. Each story should be complete with three main pieces of information. Who needs it, what they need, and most importantly why they need it. The “why” is what can help the team figure out the “how”. The story should not dictate the implementation (the how), only who, what, and why.

When these stories are finished, they should implement the determined solution. However the development team will probably have questions along the way. The software consultant should be able to either answer the questions or find the person that can. The stories should also be arranged in order of importance. That way the work can validate the stakeholders as the solution is implemented.

Conclusion

Software consulting can mean many different things, but for me it always comes back to working together with great teams to find the needed solutions for any problem they may be facing. Putting an emphasis on the people involved makes my job and my life very rewarding.