Tag: best practices

  • The Value Of A Technology Agnostic Provider

    The Value Of A Technology Agnostic Provider

    There is a concept among technology professionals known as being technology agnostic. This is a valuable trait of providers but is not commonly discussed. It is often avoided because not many providers have this trait. They do not want to highlight a weakness. That prompts a couple of questions right away.

    • What does technology agnostic mean?
    • Why is it a valuable trait?

    I am glad you asked. Let’s set the table with a definition and then look at its value.

    Technology Agnostic Is Broad Vs. Deep

    One of the significant differences between a provider (company or individual) that is technology-specific or agnostic is that the former focuses on one technology. At the same time, the latter has a broad-based approach. For example, a provider might be a Microsoft .NET shop (focused) or an agnostic solution provider. Before we focus on the broad approach, it is worth mentioning that specialists can also be valuable. These are people or teams that live and breathe a specific technology, platform, or application. Sometimes you know exactly what you want, and you want the best. It is not uncommon for a project to get to that point as it is refined and evolves.

    Why A Broad Approach?

    When you start on a project, there are very few constraints. You want to be able to leverage that and get a good understanding of your options. Think of building your dream house. You want to be the one that limits price, material, or location, not your real estate agent. That is the same when solving a problem. Thus, you want to be able to examine all the ways it can be solved without someone arbitrarily making that decision. It is not often highlighted. However, the various technology languages, platforms, and applications have strengths and weaknesses. Therefore, when your provider or consultant is narrowly focused, your options will also be limited. That may be a desire to avoid losing business, or it is often just ignorance. They don’t know what they don’t know.

    An Open Mind Brings Better Solutions

    We all have heard about thinking outside of the box. The best solutions often come when we get out of a box or set of constraints and look at the bigger picture. Technology can be powerful in providing solutions. On the other hand, it can handcuff us and constrain how we approach the problem. Rather than go deep into the weeds, let’s consider standard tools. I will even name names and refer to Microsoft Word and Excel. These are two world-class applications that are used every day. However, they have very different features, strengths, and weaknesses.

    It is entirely possible to write a research paper in Excel. Yet, that is not the best approach. Likewise, one can build a budget solution in Word, but Excel is better. These are almost extreme examples. However, I see such obvious forcing of a solution into a technology daily. It is valuable and possibly critical to start crafting a solution without first selecting a technology, whether an application or a stack.

    Finding The Right Provider

    You might now be asking how you would know what your provider fits into. Are they technology agnostic or a specialist? Fortunately, this is easily solved. You can ask them about their focus, background, and experience in previous projects. A provider constantly referring to one approach or technology will be a specialist. One that lists a large number of technologies is likely agnostic. You can then select them based on whether you know your solution needs their specific talents or you need someone that can guide you to the best technology fit.

  • Do You Have Resources To Support The Solution

    Do You Have Resources To Support The Solution

    Our question checklist focuses on getting our problem solved and crafting that solution. However, we also need to support the solution. We want to avoid many pitfalls; the most difficult one to recover from is a lack of foresight. This challenge comes from keeping our focus on the initial solution without considering its downstream and long-term impact. 

    Impact Of The Solution

    When we answer the other questions in our checklist, we examine how we might need to create or change processes. Likewise, we incorporate the immediate impact. We often will project the value of those changes beyond the product launch. However, customers often overlook the need to support and maintain a system. That burden can rest entirely on the vendor, but often there is no way to avoid some of it falling on the end users or the customer. These burdens include everyday tasks like support and training that are easy to highlight and discuss. Nevertheless, they are often overlooked. Likewise, systems costs such as hosting, storage, backup, updates, and security are frequently missed. 

    Items Needed To Support The Solution

    Everyone loves a list in an article like this. So here are some questions we want to address to support the solution properly.

    • How is the source code hosted or version controlled?
    • Who owns the rights to the source code?
    • Where will the solution be hosted? What are the estimated costs for it?
    • How will backups and disaster recovery be handled?
    • What user support is provided/expected? What SLA is expected?
    • How will user data be administered?
    • What sort of staffing is expected of the customer? (or available)
    • How will future updates and maintenance be supported?

    Now And Future Resource Needs

    We need to address implementation resources before we go too far into discussing post-deployment questions. The decision of build vs. buy and initial configuration can be limited or at least weighted by current resources. For example, there is a significant difference in a company deciding to build their solution when they have an IT department instead of when they do not. Be warned this can apply to purchased solutions as well.

    Modern software is often complex and touches other systems. Integrating current or legacy systems can require advanced coding skills or a matter of drag and drop in a graphical user interface. The expectations and available resources must be identified early in the problem definition process. Those times might need some lead time or significantly impact costs and timelines.

    Determine Ownership Of The Solution

    The questions above help us define who will own the solution once it is deployed. That includes support and maintenance as well as future enhancements. While some of that can be deferred to later (e.g., version 2.0), it is essential to know who will be involved post-production. There are many reasons to want to own the support of a project. On the other hand, there are also many reasons to desire support to be outsourced. The vision for the system can be as crucial to your plans after deployment as it is running up to that deployment.

    Source code and related questions, including artifacts like technical documentation and build scripts, are commonly overlooked. However, I find most customers only do that once. It can be a harsh lesson to learn. That applies to whether you are handed the keys to the solutions and do not want them or when you want them and have to pay extra for that privilege. These details are critical to your decisions about how to support the solution once it is in production.

    Training, Documentation, and Building The System

    A final area it is worth highlighting is the above deliverables. It is not as common that the delivery of the artifacts is unclear as it is the expectations. There is a broad range of ways one can deliver documentation, train users, and build the final product. Be clear about what is expected and discuss it early in the project. I have seen many projects get to the end on time, and then training and documentation sink the project. Do not allow these to be pushed to the end of the project. Demand that there is work done towards these goals and time to review the materials well before the end of the schedule. Avoid these artifacts being delivered in a rushed fashion after the implementation group thinks they are done.

    Improve Software Success

    We have an e-book that can help you explore all the steps in building software, including a few templates. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here. We are happy to help you in your journey if you would like to invest a little more time into planning for your project. We offer free consulting to avoid seeing avoidable mistakes. Please take advantage of it and avoid being the next cautionary tale.

  • Know Your Customers – Who Will Use The Solution

    Know Your Customers – Who Will Use The Solution

    One of the most common oversights in a failed product is a failure to know your customers. That may seem an obvious requirement. However, they tend to be misunderstood. We often build a solution without spending time understanding how the users will see it and their needs. It is not the same as building a solution that looks for a problem. This misstep is far more subtle. We have our customers in mind, as we should. Our failure is a lack of understanding.

    Know Your Customers And Their Pain Points

    Almost any problem can be stated in a way that leaves room for interpretation. It is challenging to avoid this. That leaves us an opportunity to solve the wrong problem or solve it in the wrong way. Think of a simple example involving transportation. A child needs to get to and from school each day. The solution could be to acquire the use of a car so they can drive back and forth. However, a child that is too young to drive will not be able to use that solution. We need requirements, constraints, and context. That requires that you know your customers and how they work. They are more than this one pain point and have multiple needs that provide context around our solution.

    Solve The Right Problem

    Another example of misunderstanding the customer is automation. We love to see automation for its strengths. It allows us to do things faster, with less room for error and less worry. However, it also can rob us of opportunities to customize a solution or learn by doing. There was a customer that had several manual processes that were done overnight. These seemed like a perfect target for automation. However, the cost to do these was low, and it provided a way to train new employees. Automation would have stolen opportunities for growth and possibly cost more than the current approach. We must look at the big picture to craft the best solution.

    Identify The Correct Customer

    One of the significant challenges in how to know your customers is identifying them in the first place. This situation is far more common in internal projects than commercial ones. Nevertheless, it can arise for any problem and solution. First, it is essential to recognize that the person signing the checks is not always the user that needs to be satisfied. That is challenging when the signer thinks they know better than the users. Yet, it must be addressed. Pleasing the wrong person or group may be the best short-term solution. However, it can be a reason for failure or lack of use over time.

    Next, the representative is not the customer. Do not be afraid to push back and hold the representative to verify statements and positions with the users. It would be best if you were confident they fully represent the users. This situation can come from miscommunication or lack of understanding. Your best way to avoid it is to ensure the team understands the goals and requirements rather than allowing assumptions to persist.

    Finally, ensure you are solving the problem for the right user. There can be competing views of a problem. An example is when workers want a job done, but owners need to afford the solution. We sometimes need to find a middle ground, but in others, we have one group to serve at the cost of another. That can be challenging to navigate and require political acumen, but failure to do so can lead to a solution that is not usable.

    How Do I Get To Know Them?

    There are many ways for us to do customer research up front and avoid misunderstandings.

    • Ask them to explain the problem and desired solution in their own words.
    • Watch them do their work and include more than just the problem to be solved.
    • Plan for regular feedback from the customer (or a representative) as the solution is built.
    • Discuss how often the task is done and why that timing is necessary.
    • Be open to workarounds and think outside of the box. The solution may be different from what is planned.
    • Be a partner with the users instead of just responding to requests.

    Signing Off On This Question

    The users are another facet of the product requirements. There should be a way to contact or communicate with them, and roles should be identified. While this often gets accomplished during a design phase, it is vital to have it from the start. That allows conversations to get started before any solution pieces get “set in stone” and can be highly useful during many early steps of software creation.

    Improve Software Success

    We have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.