Tag: software development

  • Making Fixed Bid Projects A Success

    Making Fixed Bid Projects A Success

    I am not a fan of fixed bid projects in general. That distaste is such that I have turned some down in the past. However, sometimes we need to step into one of these arrangements. It is worth considering the actions we need to take to keep such projects fair to all parties. Here are some lessons I have learned from personal experience and from others that have entered into these agreements. The successes and failures are excellent teachers for this billing strategy.

    Fixed Bid Struggles

    I want to start the discussion by highlighting some of the weaknesses of this process that we want to overcome. The first is that it pits parties against each other. It is in the best interest of the customer to get as much into the project as they can while the provider will want the least in it. Ideally, there will be a “just right” amount of work in the project, so the work that is done matches the compensation. This goal highlights another weakness. The vendor will want to “pad” the price to cover overages while the customer will focus on the lowest cost. Thus, any time the work is not highly defined, the two sides are hedging their risk for the work-compensation ratio. Finally, changes are difficult for these projects. Every little change will potentially require the vendor to be paid more, and the customer will want to argue against that. This situation often triggers conversations about what is a “bug” and features that were implied or assumed.

    Reduce The Competition

    The first and foremost issue we want to remove is pitting the parties against each other. The best way to resolve this is to get the pieces defined and set in place from the start. We want to set expectations for everyone involved. Our challenge lies in reducing (or at least identifying) the risks involved in a project. Thus, it is best to “chop up” the project into smaller pieces that can be easily defined and assessed. That leads to milestones. I think these are the key to successful fixed bid projects. Likewise, the are others that agree with me.

    Milestones are an excellent way to reduce a complex project into smaller, more manageable pieces. Likewise, each milestone has reduced overall risk and allows the parties to make adjustments as the project proceeds. Each step along the way will have a set of deliverables, a time frame, and a related cost. This process can still work within a greater fixed bid budget for time and cost. However, it will highlight issues sooner in the process so the parties can open discussions before one or both are in an untenable situation.

    The Sum Of The Parts

    The “just right” amount of work balanced against the requirements can be challenging to assess with a large project. When the work is simplified into a series of milestones, it becomes easier to find that balance. The focus for both functions and meeting them becomes smaller and more likely to comprehend. For example, think about your favorite application that has multiple top-level menus. Most Word Processing and Spreadsheet applications fall into this category. If you were to assess how that application meets a set of requirements, it is far easier to do so a menu item at a time than trying to look for features across all items. This thought process is not rocket science; we need to consider that adding items adds complexity and expands focus. This challenge is no different than discussing a single decision as opposed to a series of them. There are flow and side effects that come into play far more often in an extensive system than those milestones. These can make it harder for all parties to do their respective jobs.

    Managing Changes

    Change requests are always a challenge as the project progresses. There are bugs, requirements changes, and scope changes that can fall into this category. Typically, bugs are part of the fixed amount while the other two may require a fixed addition. I have found it helps to start with a bid and expectations that includes some minor changes. When you take this approach you get to avoid “nickel and dime” issues where large amounts of time are spent haggling through each item. When this happens, a project can slow to a crawl. There is always the option of pushing changes off until a project completes. However, there are times when that is not realistic. Of course, adding in some “buffer” for changes can make it hard to do an apple to apple comparison of project bids.

    Changes are more of a challenge when they are done in a granular matter. The better your ability (on both sides) to group these tasks into a bundle, the less the headache. When you avoid minute details of tasks, you avoid long conversations with little benefit. This also allows for “buffer” required per job to be rolled into a total buffer amount that will often be far less than the sum of the individual items. There is a form of averaging of risk that can be applied. Think of it as being able to make fewer estimations and risk assessments. It is not much different than an insurance company assessing risk across a large number of customers rather than having to spend time on each individual.

    The Bottom Line

    When you think about an hourly rate or time and materials, it is similar to milestones of an hour (or the time block paid). However, there are not always going to be a deliverable for those milestones other than time spent. Ideally, we have two goals. The first is to complete the overall project. The second is to complete the steps required to reach the primary objective. We can use milestones to bundle together hours of work into a deliverable and reduce risk on both sides. Each party just needs to stay open to the idea of adjustments along the way.

  • The Agile Manifesto – A Practical Look

    The Agile Manifesto – A Practical Look

    The Agile manifesto started an entire industry. It has even been the focus of numerous “religious” debates and arguments. However, it has a lot of wisdom within it that is often overlooked. The main ideas are as relevant today as they were when it was first crafted. Therefore, it is worth our time to review some of these wise nuggets and consider applying them throughout our software development efforts.

    The Manifesto Is Not The Agile Methodology

    We need to start by clarifying that the Agile Manifesto is not the same as the Agile Methodology for building software. The manifesto was used to create the methodology. However, they are not one and the same. Think of the methodology as an attempt to turn the manifesto ideas into reality. It is easy to see where many agile or extreme programming techniques got their start in the manifesto. Nevertheless, your opinion (and experience) of one may be noticeably different from the other.

    The manifesto came out of a desire to create better software. The first point drives that concept home. The highest priority is to satisfy the customer. This statement should be the “why” of any application and cannot be turned into a process. The Agile methodology provides a lot of ways to assist in this goal but does not guarantee it. Looking at it that way, we can easily see where a team could use Agile methodology precisely as described and still fail to deliver a successful project.

    Work As A Realist, Focused on Delivery

    There are twelve points the Agile Manifesto lays out.  These emphasize producing a solution the customer wants while acknowledging the realities of software development.  The most important of these practicalities, to me, is delivering results along the way to the final solution.  This process recognizes that customers often change their minds, communication problems exist, and showing is better than explaining.

    We all know there is often a disconnect between business representatives and technical resources.  The language does not always translate and skilled liaisons are in short supply.  Thus, we can lower the bar by deciding to be flexible from the start.  This approach is not a way to ignore requirements gathering, design, or other due diligence.  Instead, it assumes we will need to revisit those steps.

    The Manifesto Points

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    Business people and developers must work together daily throughout the project.

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    Working software is the primary measure of progress.

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    Continuous attention to technical excellence and good design enhances agility.

    Simplicity–the art of maximizing the amount of work not done–is essential.

    The best architectures, requirements, and designs emerge from self-organizing teams.

    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    The Agile Manifesto

    Work Together For A Common Goal

     There are numerous rules of software development built into this manifesto that are needed for a successful product.  We already stated a focus on making the customer happy.  This statement is not arguable.  A product that does not please the customer is a failure by definition.  Another important concept that is woven throughout the manifesto is the Pareto Principle.  This rule says that 80% of our effort is spent in the last 20% of the product.  That means we can get “mostly there” relatively quickly. This focus on getting most of the way to the solution is highly valuable.  

    Let’s think about that a bit.  When you are almost done, you likely have a lot of the core functionality covered.  The “happy path” is complete and functional.  That is an essential factor in getting feedback.  You have a use for the product the customer can see and experience.  They have something concrete to assess and a solid basis for requesting changes.  

    Gaps In Knowledge

    It is not very different from taking a vehicle for a test drive.  You can get a feel for it and might even see some weaknesses.  This last factor is critical to the success of a product.  Customers should not be required to know edge cases and outliers in building a solution.  That is up to the developers.  However, these are issues that often fall into the “you do not know what you do not know” category.  When you provide a demo or partially complete solution, you give the customer a straw man to work with.  That is far more concrete and relatable than describing functionality or showing them a flow chart.

    Keep It Simple Somehow

    The focus on delivering regularly and the underlying Pareto principle ideas lead us to opportunities for the KISS approach.  It is amazing how often customers will scope out requirements to get working software in their hands sooner.  This carrot is dangled in front of them during regular demos and releases.  Yes, there are gaps.  However, a good relationship with a customer can lead to a shorter path to something they want and consider “done.”  Who would argue against that?

    Remain Flexible

    The last central theme I want to point out is the focus on change. When we create software, it is crucial to think about flexibility. We are not building a system to solve a specific problem and situation. Instead, we are trying to provide a solution that is useful in a broad range of configurations. The world is also constantly changing. Therefore, even though we can be assured of a need for new versions of our software, we need to be smart about it. A sound system is built with growth and change assumed. That means we need to prepare for it from the architecture through to each step of implementation.

    The Agile Manifesto has been around for many years. Nevertheless, it still is needed to remind software developers and teams of what is important. When we embrace these core concepts it reduces risk and improves our chances for success.

  • User Experience Should Always Be High Priority

    User Experience Should Always Be High Priority

    The User Experience aspect of applications is often on my mind. I am not a designer, but even the most simple solutions can be rendered unusable when one ignores UX.  A recent experience with a front-end to a web app. Reminded me of how bad it can be for a user.  My frustration ran high, and I would have walked away never to view the application again if I had the chance.  Likewise, I will complain to anyone who will listen about the experience and may sour others on it.  That is the last thing anyone wants for any application.

    The Intro – How I Got There

    Allow me to set the stage for this little drama.  I recently took a certification exam from the comfort of my home.  It has its annoyances but does save me a drive back and forth to a testing center.  There is a validation step to prep and ensure your environment meets the requirements as well as checks to avoid cheating.  Once you are validated, a proctor connects via text, does a few last-minute checks, and then your machine is sent the test.

    Overall, this is a good system, I think, and probably does a good job stopping people from cheating.  This solution is a good one in this case.  However, the experience I had leads me to think I will never try that again.

    A Bad User Experience

    The steps before the exam are where I had all my frustration. The exam process and experience was exactly what I expected.  We will start with the preparation step.  When you start into the prep process, you are given a nine-digit id to link uploads to the system.  You are sent a link on your phone, so you can take pictures and send them to the site.  The photos include the front and back of your picture ID (driver’s license) and then four to cover the front, back, left, and right view of your work area.  So far, so good.
    The upload process tells you what picture to take, flips to your camera app, then you click a button to submit.  The user experience gets bad quickly at this point.  There is no explanation about the pictures other than what I listed above.  I have no idea if you have to take a specific layout or from a certain distance.  It gets worse.  If there is a problem with the photo upload, you are taken back to the screen to enter the nine-digit ID and forced to walk through the screens again.  There is no error message or indication of what went wrong.  It does save pictures previously loaded, so at least once you get a successful upload, you do not have to re-enter that picture.

    A Painful Design

    The preparation process I listed above gets repeated precisely the same way when you log in to take a test.  You have to send an ID again and all of the pictures of the environment.  A bad UX is doubled down on.  This becomes more frustrating when the proctor has access to your machine camera and will likely ask you to pan it around your work area.  Thus, confirming a third time that you have a valid environment (no notes on the desk or anything like that).
    The same message-free process is used again, so in my case, I spent around forty-five minutes retaking those twelve pictures.  I lost count of how many times I took each, but I think I attempted each one at least three times.  It is more frustrating because it was not an Internet connection on my end.  I had stable and reliable high-speed connections throughout that time.

    A Moral To The Story

    I mentioned that this solution as a whole is awesome.  It is also one that was critically needed in a time of social distancing and stay-at-home orders.  It allowed me to get a certification test done much sooner than I would have otherwise.  I appreciate that.  However, a user experience that has a user in limbo for over a half-hour is far from good.  I think all of us would be happy to walk away from that experience.
    In this case, that validation process was a small part of the overall solution.  You may have seen features like this that are a registration, login, or even close account solution.  These are small parts of the overall solution and often seen as not integral to it.  For example, I often work on MVP solutions that ignore some of these “minor” features and even downplay the overall UX.  That is a dangerous approach to take.  Consider how much damage this bad experience for me will translate into bad feedback spread to others.  That should make you think twice before lowering the priority of the UX for your solution.