Tag: requirements

  • Investing In Requirements

    Investing In Requirements

    Custom software can be very expensive and scary, but investing in requirements can help you improve the likelihood of success. However, we often want to see things being built rather than simply think about them. That creates two things that fight against each other (get it done or think it through) in many projects. Thus, we must consider early work on requirements and design as an investment. We pay for it in patience, but it saves us in almost every way down the road.

    Investing In Requirements Is An Easy Choice

    There is so much value in thorough requirements gathering that it seems impossible for anyone to pass over this crucial step. Unfortunately, it is a common problem and one of the reasons many software projects fail. Yes, we want to see “work getting done,” but the only reason that is a problem is because we are not yet seeing the end product. I like to use the analogy of going on a road trip. You are not getting closer to the destination until you start driving. However, if you do not know where you are going or the obstacles on the way, it can be extremely costly. Those that use modern GPS maps or apps like Wayz often are redirected around problem areas and potentially save hours of drive time. That is the same with software development. We are not writing code but investing in requirements, so we have a better idea of the path ahead. That allows for proper estimates and planning.

    We Can Adjust As We go

    One argument we fall prey to is that we can start building the software and easily adjust as we go. While there is truth in that, and we do not need to know the whole journey in detail, we do need to plan for each stretch. That is what the Agile approach embraces. It takes a bit from both worlds and gets us on the road faster while still ensuring we are planning enough to avoid major issues. When we use the road trip analogy, it is like planning the trip but then being open to adjusting due to construction or traffic delays. However, the key is that we need to know at least some of our path before we start. In a software project, this can be done via high-level requirements and core feature definition. Be warned that is a possible approach, but it can still suffer from wrong turns and proceeding down dead ends.

    Back On The Main Road

    The discussion of Agile and its strengths and weaknesses is for another article. Let us return to a focus on requirements that applies to any software project. Modern software systems are highly complex. There are tools that can help us to create or generate thousands of lines of code quickly. However, that speed can be just a faster way to create a big mess. I have seen many projects stumble and fall due to this issue. The problem may seem simple, but the details are highly complex.

    For example, let’s consider the simplest of problems to solve: keeping contact information for your customers so you can serve them. How hard can it be? There is a name and address and maybe a phone number or email. Oh wait, what if the customer needs a title, or is a company with multiple contacts? What if the billing contact is different from the key decision maker? Do we care if they have bought from us before, or do we track leads? Should we keep notes each time we talk to them? The list goes on and on. A simple problem can quickly become a complex maze of decisions. These can be very costly to make if we have already made a lot of progress on our software journey. Changes can require updates to code the database, the user interface, and even the partners or libraries utilized. Backing up is far more than that BEEP, BEEP, BEEP a large vehicle makes.

    How Do We Get The Requirements We Need?

    Custom software development is just a way to solve problems on a big scale. Thus, we can use basic problem-solving techniques to guide us in creating a list of requirements that we can be confident in. Here is a short list of questions that you can use to take your requirements definition up to another level.

    • What does this need to do?
    • What does success look like?
    • Who needs to know about task completion?
    • Where can it fail?
    • Who needs to know about a failure, or how do they need to be told?
    • Is there anything else it needs to do?
    • Can any user do it?
    • Does every user experience it the same way?
    • What did we forget?
    • No, really, what else did we forget is a part of this process. Walk through each step as thoroughly as possible.

    The above question may not seem like much. However, they are easy to overlook. I have worked on dozens (probably hundreds) of software projects and still need to step back and review these questions each time. We can easily get lost down a rabbit trail and skip a step. A thorough review before building out requirements is a huge step in the right direction.

    Play It Back To Me

    A good way to ensure clear communication is to have someone repeat back to you what you said in their words. Do the same thing with your requirements. Walk through your problem and the proposed solution using only what is listed in the requirements. This action often brings up more requirements and details than even the last two questions listed above.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. We are happy to help you with investing in requirements and improving the overall success rate of software projects. Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, 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 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.

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

  • Creating an Effective RFP

    Creating an Effective RFP

    Sooner or later we all need to solicit proposals that provide solutions to a problem.  This might be a request for an application, a service, or products.  It should come as no surprise that an effective RFP process accurately defines the problem.  However, there is more detail that makes up an effective RFP.

    What is a Well Defined Problem?

    The challenge of a technical RFP is often the language required to create one.  The technical staff provide input (or possibly the entire response) to an RFP, so it is essential to communicate to them directly.  Miscommunication can make responses invalid or worse.  However, the writers of the RFP are usually on the business side of the equation.  This is not an insurmountable issue.  It just requires attention to the details that matter to an IT solution.

    The key is in the details.  A problem definition needs to include these pieces to provide the context required for a solution rather than just an answer to a question.  For example, an RFP that defines the problem as a need for a website with a “contact us” form is overly simple.  There is no context for a useful solution.  Think about how the details below can help respondents craft a more meaningful response.

    • Who are the primary users?
    • When will it be used? (business hours, 24/7, etc.)
    • What is the expected response time for the pages/functions?
    • Are there constraints or limits to the technology of the solution?
    • Will it have to scale? To what level?
    • How soon is the solution needed?
    • What sort of budget do you have?
    • What kind of company are you?  (line of business, employees, sales)

    These details may seem like providing too much information.  Nevertheless, these provide context for the solution.  These details will help the providers craft a solution that meets your needs.

    Know The Respondents

    As part of your RFP, you want to make sure you have the right people for the job.  A good RFP document provides a lot of detail about your company so it is only fair to request details about the respondents as well.  In a similar sense to the problem details, a good RFP requests several facts from the respondents.

    • How long have you been in business?
    • What does your typical customer look like? (size, business, focus, etc.)
    • Have any major changes to the company structure occurred recently? (merger, acquisition, etc.)
    • What sort of support staff do they have?
    • What certifications, audits, and assessments have been done on the company?
    • Can you provide some good references?  For example, customers that were provided a similar solution?
    • Describe the processes you use to ensure quality.

    An Effective RFP Takes Time

    Do not underestimate the value of your problem.  If you have a strong enough desire for a solution to search for proposals, then make it worthwhile.  Spend the time to properly detail your problem and allow for respondents to take their time in crafting a response.  I hope these items have helped you create an RFP process that works for you and finds a perfect response.