Tag: software development

  • 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.

  • Why Go Through A Request For Proposals

    Why Go Through A Request For Proposals

    We have looked at various topics over the years and consulted on many more. However, it is worth revisiting the idea of a Request For Proposals (RFP) and what you should look for in this process. It is not a small or simple thing in most cases. Therefore, it should be entered in with the respect and expectations it deserves. The steps may seem tedious, but they are worth the investment. We will explore the pros and cons and convince you of the value of this daunting task.

    Request For Proposals – More Than A Document

    First and foremost, an RFP is more than a document. It is sometimes misunderstood as little more than a document one sends out, and they get similar documents in return. Thus, it may be seen as a form of job posting. That reduces it to a set of requirements and applicants line up. However, even that analogy tends to fall apart as job applicants go through an interview process. That process often includes multiple interviews and time spent getting to know the applicant while teaching them about the organization. Hmmm, maybe that analogy is a good one for us to use.

    The RFP As A Job Posting

    We have all seen job posts that follow several formats. They differ from the size available on the platform (website, newspaper, etc.) and the specifics of the role. There is also a range from casual to formal in how jobs are listed. That being said, we all can recognize a good job posting includes key attributes.

    • Who is the job for? (The Company)
    • What kind of job is it? (Salary, Hourly, etc.)
    • What is the applicant expected to do? (How to apply)
    • What does the job entail? (A typical day or similar list of job activities)
    • What are the expectations? (Degree, experience, and other requirements)
    • How does the job get fulfilled? (Timeframe and locale. Is it remote?)

    Likewise, each of the above items can be brief or highly detailed. Most of us prefer more detail for a job posting to help us decide if we are a good fit. We also can craft our best arguments for winning the position when we have a lot of details about what an ideal candidate looks like to them.

    Posting And Resumes

    While a request for proposals can be seen as a form of job posting, the responses can be seen somewhat as resumes (or CV). The vendors (prospects/applicants) provide a background and reason to select them for the job. Likewise, the resume or response is not the end of the selection process. One must go through due diligence and check references and an interview process. A list of skills on paper or a nice cover letter is not (or at least should not) be enough to make a decision. Yes, we can read the packaging to help select a product. However, we will be more likely to make the best decision after a trial or test drive.

    Avoid An Expensive Mistake

    That brings us to the primary reason for going through an RFP process, avoid a mistake. Buyer’s remorse is common and an RFP might not avoid that. However, the time and effort invested in an RFP process will go a long ways in avoiding buying a lemon or ineffective solution. Your position might be that your organization has such a common problem to solve that anyone in that space will be sufficient. That is a position that often leads to regret. Even common problems can have very different solutions. The one chosen by a vendor might be incompatible with your organization.

    A simple example is target platform. Your company might be only Macs and the solution is only available for Windows machines. While a simple thing to check and avoid, there are many other ways a solution can be incompatible with your business or budget. The RFP process will help the buyer and vendor get on the same page for requirements and lead to much higher odds for a successful solution.

    Do The Research

    Finally, it must be pointed out that an RFP process in any form is research into solutions. You likely will research factors involved in buying a house or car due to the costs involved. Why then would you not do the same for an expensive software or solution purchase? Whether it is your time and money or company resources, there is a lot at stake for most IT projects and solutions. Avoid regrets (and career damage 😉 ) by using the request for proposals process to educate yourself and your vendors.

    Improve Software Success

    We have a couple of classes specific to RFPs and include templates and examples to help you. Check these out (paid and free courses) at https://school.develpreneur.com/p/rfp_courses

    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.

  • 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.