Category: Building Software

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

  • Is This An Improvement In Your Current Solution? – Defining ROI

    Is This An Improvement In Your Current Solution? – Defining ROI

    When defining ROI for a project, we must ensure that the changes we make are a step in the right direction. In some situations, adding a feature or even a new solution is a step backward. We can run into this when there is shiny new technology or some buzzword we hear and decide to embrace. These projects are more about “keeping up with the Joneses” than improving our bottom line. That may seem simple to avoid. However, it is common for a business to dive into a project without fully understanding the costs and rewards.

    Defining ROI By Assessing Our Current Situation

    We often return to a “why” and the details around the problem we are solving. This question is another one that requires us to examine our current situation. Our efforts at defining ROI must be based on an accurate baseline. That can only be done by assessing where we are and its costs. Once again, we struggle to create a solution when we have not adequately defined the current process. In this case, we go one step further and assess the related costs. The costs and benefits of the current situation can fall into several categories.

    • Monetary
    • Time
    • Morale, Frustration
    • Quality
    • Training/Side Effects

    The Monetary Cost

    This cost is a common facet of defining ROI. We can see hard numbers from license fees or other line items tied to one-time or recurring payments. It is an area with a lot of black and white, so we are comfortable using it as part of our return on investment calculations. However, there can be hidden or tangential costs to software. We might need to pay for maintenance, adjust for overages, or purchase other items as part of this cost. For example, a solution might require that we have a laptop for each employee. While that may seem a part of doing business, it might not be correct. A different solution might allow employees to have a lower-cost device without losing productivity.

    Time – The Master Thief

    Time is the hardest part of defining ROI. We can quickly lose a lot of time in small amounts throughout the day. A good example is the time spent checking e-mails. This task can seem like a short and inconsequential part of our day, but it adds up. That same challenge in assessing time spent on tasks occurs throughout the business. Even worse, there are side effects that can eat into our productivity. For example, a report that takes five minutes to execute may be an excuse for the employee to run and grab a cup of coffee. While that is not an issue, the time spent is. That short run to grab coffee may average ten minutes away from work. That turns the five-minute report into a ten-minute actual cost. While this example is a micro-managing of time issue, it is not irrelevant. We often spend more time around a task than we realize when you include pre and post-time that are directly linked to the job.

    Morale and Frustration – The Silent Killers

    Time and money can be relatively easy to assess as costs for a task. On the other hand, frustration and an impact on morale are hard to define. These vary from employee to employee in many cases. They also are intangibles that are hard to quantify while still being critical components of productivity. The best way to measure these areas is to talk to the users most impacted by the problem and solution. You can try open-ended and theoretical questions like, “What would you do if this took half as much time or if it was not part of your day?” This assessment is complex. However, the pay-off can be substantial as it helps you get a sense of the real problem within the problem. Do not underestimate the need to incorporate satisfaction and frustration into your ROI for a solution. You can even float trial balloon solutions to see if you are genuinely improving the current situation.

    Quality

    There are some enhancements we make that are pure quality plays. For example, we can reduce data entry errors and add new checks, validations, or other features that make our organization produce a better product or service. However, these cost factors can oppose satisfaction as it sometimes slows production speed in the short run, even while improving overall productivity through fewer support calls or returns. In some cases, this factor may also be considered a cost of doing business. For example, there might be a compliance need to work in a way that impacts quality or security. We may prefer not to do things this way, yet we are forced to. That falls into that category of being a cost of doing business.

    Quality is another area that is not always easy to measure. It can be subjective and evasive in tying it to the bottom line. However, there are not many customers that search for low-quality or shoddy products. Therefore, we need to make it a factor in everything we do and every solution we assess.

    Training And Side Effects

    A little-known or considered area of defining ROI is how a solution can impact employee training and understanding. In the same way, there can be positive and negative side effects of a process or solution that we need to consider. For example, automation is often seen as a positive step for any problem. It has benefits that include speed and reducing potential errors. However, it can sometimes hide implementation details and other specifics that are good for employees to know.

    One of the best examples I have come across is the idea of customer interaction. In many situations, we can use technology to streamline common customer touchpoints, including support, orders, and even complaints. These can be areas that save a lot of time and reduce costs. However, the lack of a “personal touch” can also be off-putting. We all have those times when we want to speak to a human being. No amount of voice menu intelligence can replace the ability of a human to provide context, empathy, or even sympathy when that is what the customer truly wants. There are also outlier situations that never seem adequately handled by a process or automation. These unique situations can be a make-or-break moment with a customer. These are the times we want to take that extra time and provide a custom solution rather than the best automation we can come up with.

    Signing Off On This Question

    This question can be simplified down to a pros and cons list or something similar. First, we must be clear on the benefits of the solution we are looking for or proposing. Likewise, we want to be clear on the potential downsides of our new approach. The knowledge of the pros and cons and clearly communicating them can be instrumental in building the best solution for our situation.

    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.