My Speech on Using Technology to Solve a Business Problem

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.


About dandouglas
Dan Douglas is based in Toronto, Ontario, Canada and is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 15 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results. | For inquiries about Dan's software consulting practice, please see the contact page.  Dan has also built up a network of highly successful and professional Software Developers and Architects who are highly respected and can be called upon and used in conjunction with his own consulting practice to handle the largest of consulting projects.

3 Responses to My Speech on Using Technology to Solve a Business Problem

  1. This was a great article Dan.

  2. Pingback: Intelligence Among Us

  3. Pingback: My Speech on Important Points in Considering Software Architecture « IT is Possible – Dan Douglas is blogging

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s