My Speech on Using Technology to Solve a Business Problem
April 21, 2009 3 Comments
In search for content for this new blog, I started to think about past work projects, past experience, and past content that I could use to help in the writing process. I thought about two speeches I did over a year ago. They were career orientated speeches in the area of Software Development. They were my third and fourth speeches I did for an organization called Toastmasters. My intent is to transcribe the main content and focus of the first speech into a blog posting. It’s funny, because I’ve started to go through my old notes for the speech, and I remember all of the practicing and reciting I did. I can almost hear myself reciting it as I am going through the notes.
My previous blog posting, titled, Making the Business Case for Technology, II: Demonstrating Value After the Fact focused on responsibility, ownership, and accountability – after the fact. The ideas mentioned in that blog posting would come into play once the solution, as discussed here, was put into place.
This speech was designed for an audience with little technical knowledge and who were not in the IT field. Due to time constraints in the speech (about 7 minutes), it was meant to be a basic overview for the audience as to what they could expect the process to be in the design of a technological solution to solve a business problem. The example I used in the speech was a real scenario I ran into at work a couple of years ago.
So here it goes….
How do you become effective in your job? If your job was in the field of Information Technology, what would your process be to ensure you were using your resources as effectively as possible? Many IT solutions are successful, and many are not. As a person making decisions on technology solutions for business problems it is important to ensure you are using your resources effectively.
Many business users, or customers, are very interested in using technology to solve their problems. Technology is a great way to help solve business problems, but many projects fail because throwing technology at a problem alone, rather than solutions, rarely gives satisfying results. It is critical that proper business processes be defined before throwing a technical solution at the problem. As an example, the Quality Assurance department may be having difficulty getting accurate numbers from their weld testing machines into the weld destruct result tracking system, so they make a request to have the results of the weld destruct tests moved automatically from the weld testing machine (push-out tester) to the weld result tracking system. At first glance, this may seem like a great idea because seemingly it will limit human error because everything will be done electronically and automatically. However, upon further discussion with key individuals, further investigation, and further analysis you discover that the process for testing the welds is poorly defined or is not followed correctly. The operators are not using the push-out testers properly or consistently and therefore the numbers they are reading from the weld testing machines are not accurate. However, if the analysis of the problem showed that the operators were using the weld testing machines properly and that a technical approach would save them time, and therefore money, we would move on to the requirements gathering and analysis phase.
One part of gathering requirements involves discussing potential solutions with the customer. Potential solutions can vary between custom developed software and third party applications. The solution could automate the entire process or only part of the process. This analysis may take some time to develop, but it is a critical step in order to identify potential problems that could arise in the future and also to discover potential roadblocks (including significantly large costs and limits of technology). In the example mentioned earlier, the analysis showed that there was no third party software that would help in this scenario, but potential solutions could include: 1) Custom software written to have the weld result tracking system automatically pull the information about the weld tests from the weld tester. 2) Have the weld tester push the information to the result tracking system via custom software. With any solution we need to identify any potential problems that could be created along with it. As an example, what if the operator did the weld test wrong and the wrong results were sent to the weld tracking system? We need to make sure these types of factors are looked at and resolved before moving forward. After the analysis, there may be factors that make a technological solution unfeasible, which in this case, you would sit down with the business users and explain why the project in itself is unfeasible and will cause problems on its own on an attempt to implement it.
As we begin to move forward with the development and implementation, it is important to establish a good working relationship with the stakeholders involved. “Buy In” from all of the stakeholders involved is critical, and it is important that costs, timelines, technical specifications, and design are approved and signed off by the stakeholders. The stakeholders need to be made aware of the responsibilities of the individuals developing and implementing the solution and also need to be aware of their responsibilities to the ultimate success of the project. Stakeholders must provide feedback throughout the duration of the project and ensure at each milestone that the solution is tested to meet their business requirements. Stakeholders must also help identify problems in the solution that could disrupt their business processes.
Although we have just scratched the surface of the process behind building a successful technology solution to solve a business problem, it is important to remember that a solution is designed to help solve a business problem that has a defined business process. For a technology solution to be successful, we need to ensure that the solution will solve the problem, that there is “buy in” from the project stakeholders, and that the requirements have been satisfied.