The success of custom software development projects comes down to one thing: how well they were planned. This isn’t a bold claim; It’s merely a reality. We all know that a business can fail or thrive based on many factors. But, software is a different beast. The longevity, overall effectiveness, and long-term success of a software project are largely determined before a single line of code are written, or the first user interface is designed.
So – when planning – what matters and what doesn’t? Frequently, we see potential clients focus on the wrong factors and ignore what is essential when it comes to their project. With that said, it’s about time we laid out some critical and irrelevant factors that you’ll be judging during the planning and procurement phase of your project.
Things That Don’t Matter
Trendy Software Options: This one always kind of bugs me the most. So many times, clients come with a preconceived notion of what would work best for them and their project. How often does someone go to the doctor or the dentist and dictate how to perform the work? Rarely… But it happens in the technical space all the time. Honestly, that isn’t a major problem. Some clients have actual preferences that they must adhere to. The problem exists when clients are interested in fringe technologies because someone mentioned it to them, sometimes even in passing. I’ll make an observation here that for the most part rings true… New or inexperienced technology professionals are often more apt to recommend trendy technical solutions when there are more stable and reliable options available. Maybe it’s a self-esteem thing – it’s faster to appear like an expert when you can highlight that you have new ideas and someone else has older ones. Either way, I’ve seen more projects fail than succeed when they have been built with trendy technology options that either become out of style quickly or aren’t as functionally extensive as other solutions available. Trust me on this point: it’s better to find a solid technology partner versus building with the newest and greatest software packages. Trendy software introduces risk – and experienced practitioners should be focused on avoiding risk at all costs. On this note, I have an entire blog dedicated to this topic – read it if you can.
The Sales or Biz Dev Guy: In this business, you have two types of sales interfaces. One is the quintessential biz-dev or salesperson. The other is more of a practitioner-based approach. Biz dev professionals are there to gather requirements, talk to their team, and then relay possible options. Practitioners are going to make the sales process much more consultative, talking through options, and walking through solutions. I’m not here to judge either method. Our business is based on the latter, on a practitioner-based approach. But, I know many excellent agencies that utilize business development people. However, I will say, that the person selling your services doesn’t matter – unless they are the practitioner to an extent, you probably won’t spend much time with them as the project progresses. So, don’t be hung up on hiring one group over another simply because the salesperson is slick – that’s what they are supposed to do.
Your Procurement Process: I hate to say this, but clients who come into a software project with a preconceived notion of what the procurement process will look like are often going to be unhappy with the end result. Primarily this is true when archaic methods like RFPs are employed – you can read an older post I have written on this topic as well. The fact is, when you come in open-minded to process, you’ll have better results.
This is especially true with custom software. With any given project, there are multiple methods that can be employed. And within those different approaches, there are hundreds of subtleties. To develop a plan to build these solutions for the sole purposes of an RFP is a non-starter for most developers. There is only one way to do it – and that is to make it all up while leaving tons of gaps behind. This is the primary reason why software projects blow up. Failure to properly architect and plan before proposing pricing and timeframes will never result in a good thing unless either the agency or the client plan on taking a bath on the project.
Hourly Rates: So many clients are addicted to comparing hourly rates as if it is something that can be compared. Fact is, it’s such an arbitrary figure that utilizes secondary measures more than primary criteria (including skill) to determine the value. As I’ve written in this post, hourly rates vary greatly based on more than just practitioner experience but also other economic factors. Therefore, using hours as a comparative metric is a waste of time.
I would encourage clients to focus more on time to complete a project, the specification, and a total predicted cost to evaluate a proposal. With custom software, that can be a difficult thing to compare. But, it’s a better measure of ability versus cost than just an hourly rate. Would you hire someone for $25 per hour which takes a day to do what another can do in an hour at 5x the rate? It doesn’t make sense to think this way.
What Does Matter
Architecture: By “architecture,” I mean careful planning. It’s imperative that you carefully and thoughtfully build a specification and project plan. Either with an agency or on your own. I’m always amazed at how many customers come to us with an idea but no real plan of attack to build their vision. And, I’m equally surprised at how many other agencies bid on that type of documentation. Creating a proper specification and architecture matters greatly and reduces the overall risk to both clients and agencies to a dramatic fashion. This should be your number one focus in planning and procurement – developing a specification.
Key Project Components: Every software project requires third-party components. Sometimes its software libraries that can be open source, other times it could be outside services that need to be integrated. Clients OFTEN overlook this eventuality, and in some cases, make bad decisions about what tools to use. If your project requires third-party tools, and chances are high they will; then you need to consider which to utilize carefully. You want to make sure they are scalable, reliable, and will stand the test of time. Also, you need to be careful about just how essential they are to your project. You don’t want to build something out that is 100% reliant on a third-party, such that changes to their platform or business structure can risk-taking you offline. Make sure ample attention is paid to this issue, as early as you can in developing your specification.
Key Team Members: While the sales guy doesn’t matter, the rest of the team does. When you are planning your project, get acquainted with the key project team. Design leads, project managers, account managers and any other oversight or team members that will be working with you day-to-day. As I mentioned earlier, you’ll lose touch with the sales guy relatively quickly. But, the day-to-day people will be your extended family for the duration of the project. So, it’s essential that you get a chance to meet them, appraise their level of skill, and build a relationship. These relationships are part of the service you are buying, and if there isn’t a level of rapport across the team, it will affect the project negatively.
Project Process: While previously I had said your process doesn’t matter – well – each agency will have a process and it should be considered carefully as a determining factor for whether or not the project can succeed with that team. Ask if there is a specific process that they employ for each of their projects. Then you can evaluate a few things. First, if they have a well-honed process, then you can tell they have been at this for a while. That’s positive. Secondly, if you see the process laid out, you can determine if your team can work within that system. In some cases, it may not be a fit, which is fine. But at least you know in advance.
In wrapping up, I want to reiterate that with software development projects, the risk of project failure is much more significant than almost any other construction or development undertaking. You must, at all stages, work to avoid any risk of collapse of the project. I believe that the majority of avoidance tactics should occur during the initial procurement and planning, and, during that phase, it’s best to make sure you are focusing on the right variables and throwing out those that are for the most part irrelevant.