Tag: projects

  • 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 Danger Of Almost Complete Software

    The Danger Of Almost Complete Software

    It is hard to keep up with the number of times I have worked into a phase of “almost complete software.” We often see this as a marker or milestone that tells us a little push is all that is left. However, that is rarely the case. It seems like the end of the implementation phase is a trigger for this lofty status. We all fall for it. Our product implementation is approaching a final milestone and extend that to being almost done. We overlook so many details that are yet to be done. In listing out some of these details, I am hoping that we can all be a little more realistic in our expectations and setting the same.

    Testing Almost Complete Software

    Testing cycles can be very short and almost ignored. However, that often ends in low-quality software and unhappy customers. A proper testing cycle can be time-consuming and will often churn on a couple of bugs or features. It is rare for e a project to sail through testing without time spent clarifying issues, how to reproduce bugs and requirement reviews. This phase alone can make the almost complete software claim seem laughable.

    Deployment Challenges

    Things are getting better with modern CI/CD processes and tools like Docker. These tools and processes help us start working on deployment issues sooner in the SDLC process. However, there is no replacement for the final deployment. It is amazing how often simple things like a point release difference in software, a seemingly negligible configuration value, or changing an address or network can bring down software. Even worse, the errors that appear in production and can not be seen in development often take a while to be identified. That also means these can take a lot of time to track down and correct.

    Understandably, one would feel close to the end at this point. The gotcha is that putting something on a production server is when the rubber truly hits the road. User Experience becomes a much more critical factor, and you often see load impact for the first time when you hit production. While many of these issues are addressed in future releases, I have also seen products languish amid deployment issues.

    Edge Cases

    A good set of requirements that are used to measure progress can help with this issue. Nevertheless, it is not uncommon to run into edge cases and unusual situations that only become visible when you get near the end of a project. These can be attributed to going after “low-hanging fruit” early on in testing and implementation. On the other hand, when we consider the 80-20 rule, this makes all kinds of sense. The two ideas are likely closely related. That last fifth of your journey in building software is going to be beyond the bugs that are easy to identify and fix. You are now in the area where significant challenges like “randomly” appearing bugs and race conditions need to be tackled. These alone can convert almost complete software to early steps in a death march.

    I apologize, but I have been on a kick thinking about anti-patterns. They are fascinating to me and an essential part of planning for success. If you want to learn more, then you can find more about anti-patterns all over the web. There are some patterns out there as well, but if you at least avoid some of these project planning, estimation, and execution anti-patterns, your odds of success will increase significantly.

  • Sticking To The Plan – Completing A Project

    Sticking To The Plan – Completing A Project

    One of the most frustrating situations in software development is when one side decides to “change the rules.” There have been examples on both sides of the equation that I have seen ultimately derail a project right before completing a project. We even do it to ourselves at times. I hope that listing a few common mistakes will help you identify and avoid them in the future. It may bring world peace a step closer.

    The Nickel And Dime

    There is nothing I can think of that destroys trust between customers and vendors than either side chipping away at the other. A vendor does this with a steady stream of little change request charges. Instead of working together with clear deliverables and a plan, they get stuck in the weeds. A client does this by trying to get tasks turned into “non-billable” and drags the team into unnecessary detail. The thing about software development is that it is complicated in most situations. There is enough to worry about without nitpicking the details late in the game. Do not read this as the “details” being unimportant. They are critical in completing a project successfully. It is just that those need to be hashed out early on and not when the end is nigh. When you do this, you will avoid a feeling of death by a thousand cuts.

    Just A Little More

    This particular anti-pattern may be the one I relate to most. There are two conflicting traits many of us see as we approach the end of a project. However, they can combine to spin us off into oblivion. The first trait is what I call the “90% high”. This situation occurs when we “know” we are almost through with a project and have a burst of energy to get across that finish line. Think of it as a runner sprinting that last one hundred yards of a marathon.

    The other trait is one we will call “just a little more.” This situation arises when we feel we are close to the end and can squeeze in a few more features or finishing touches. When we have that extra energy to drive to the end and a desire to keep adding a little scope, we can rapidly go off course. It is almost like we do not want to get across that finish line and instead want to stay “in the zone” as long as possible.

    Perfection Over Reality

    Sometimes completing a project is hindered by quality assurance and testing results. The application is almost complete except there are some bugs to fix. While some bugs must be addressed to provide a useful product, some others do not. For example, I have seen projects wallow in testing cycles as minor things like pixel-perfect displays, wording for labels, and fonts or sizes are “fixed.” These might be issues that impact the usability and correctness of a product. However, that is rarely the case.

    These sort of nit-picking details can drag out the testing cycle beyond reason. Keep an option for “known bugs” that can be addressed in a future version. Users may not wait forever while you perfect that current release. Even worse, I have seen situations where wording (copy) is minutely engineered only to find out that it ends up negatively impacting users. Yes, even copy can be over-engineered.

    Agile To Infinity

    One of the strengths of an Agile approach is that releases should be common and regular. However, that does not stop some groups from dragging out a production release. This situation is similar to the “just a lttle more” pattern. However, in this case, production releases are pushed off for “just one more sprint” instead of tightening things up and pushing it to users. Instead of a litttle item here or there, this pattern becomes a few more features, bug fixes, or performance improvements. Sometimes there has to be a person the team that can make the “fish or cut bait” call and drag the project across the finish line.

    These are just a few of the ways to avoid completing a project. You can find anti-patterns all over the web. Nevertheless, I find these to be highly common and often easy to avoid. Of course, it all starts with a plan, and then the team needs to keep working towards that plan. Changing mid-course can turn you right into an anti-pattern.