Your software project is going to fail and I can tell you why.
I’ve been developing software solutions and involved in the technology space for nearly 20 years now. I’ve been responsible for designing and implementing some incredibly complex business platforms and I’ve seen over and over what works and what doesn’t. I’ve seen everything from huge successes to spectacular failures and just recently watched a huge belly flop of a platform rollout (I had nothing to do with it!) that got me thinking about how this keeps happening to so many companies trying to solve their technology challenges.
I’m a member of Provisors. They are a great business development networking group that a few months ago had a decent member portal that let you find and connect with other members, see an event calendar, RSVP to events and basic features along those lines. Nothing groundbreaking but it did the job. For months they were teasing the launch of the new and improved member portal. We got an email saying the site would be down for the weekend and on Monday to use the new URL and login info to access the new portal. That’s when all hell broke loose.
The rollout was botched, data wasn’t migrated from the old site to the new, features didn’t work properly and worse yet, after a 5-6 weeks of it kind of half-working, the new site isn’t actually an improvement in any way that I can find over the old one! So… what the hell happened?
I wish I knew. BUT, what I saw aligns with what I’d argue are the top 3 reasons a software project goes sideways.
- Requirements
- Assumptions
- Rollout
Requirements
This is #1 for me. I’ve seen more botched projects due to fuzzy requirements than any other reason. First, as a client, you need to be incredibly clear and proactive about the features and functionality of the system. Rely on your development team for the technical bits but providing a list of features is not a set of requirements.
It’s far from enough to have a feature list that includes; User management, email alerts, billing & payments… and call it a day. A statement of work that looks like this should be run from, quickly. Developing requirements is an art and, like I said, the most critical factor in the success of a solution. Requirements should be iterated upon, should draw out difficult questions, and should answer not just the what (user management, email alerts, etc) but the why and the how. Requirements NEED to be both literal AND visual for maximum clarity. That means written specifications and clickable prototypes in most cases and especially for complex solutions.
So what are software requirements? Simply put, requirements are the description of the system to be developed and includes use cases, wireframes, functional and technical specifications. They are both the blueprints and vision for the solution.
Where I see requirements gone wrong in so many cases is a client abdicating responsibility for them, assuming their dev team has done this before. While I’m sure they have, as a client, it’s your responsibility to communicate your vision for the solution to your dev team and not leave it to them to interpret your needs.
A good development team will require a solid understanding of WHY a feature is necessary to provide a viable solution. They will also need to define the HOW of the solution in prototypes, wireframes and specifications… which brings me to my next point. Assumptions.
Assumptions
Ever been involved in a project where, at the finish line, the teams had distinctly differing ideas of what was to be delivered? Of course you have.
Faulty assumptions in combination with unclear and poorly documented requirements are a good bet as to how teams’ expectations diverge.
Software development is complex stuff where even simple solutions can have hundreds or thousands of permutations. Programming good software is the easy part. Our job as software developers is more about communication than 1s and 0s. We need to communicate in as many ways as necessary for our clients to understand the implications and behavior of the tools we develop. That means functional and technical specifications that describe what’s happening from a technical perspective. That means use cases or user stories that outline a solution from the users’ perspective. And that also means prototypes and wireframes that visually demonstrate the solution. Our job is to leave no stone unturned, and no corner dark where faulty assumptions can lurk and cause often costly damage.
The best advice I can give you is, as a client, don’t assume anything that isn’t explicitly spelled out in the requirements is going to be in the solution. And my advice to development teams is to set these expectations early on and develop systems and processes for finding and eradicating assumptions.
Rollout
This is the test that 99% of development teams fail. They may be incredible programmers, killer designers, epic systems integrators… but can they bring the project home?
A good friend and colleague once told me “You got people? Then you got people problems.”. What that means to me here is that software is just 1’s and 0’s until a living breathing person does something with it. It has to be introduced to employees, it has to be used by teams, it has to make things easier, faster or better than before. Any way you slice it, people will be involved in the rollout and/or adoption of the software. So by extension, the success or failure of a platform can be measured by the rollout. The final inch.
The best technology solution your company can buy is worth exactly nothing if your people aren’t using it.
Rollout is about planning the logistics of how a solution is to be introduced, users trained and adoption encouraged as well as the transition of data from old systems to new. Software solutions can be complex, making a transition to a new platform a big project in its own right. That doesn’t relieve the development team of the responsibility of planning for the changeover. That said it amazes me how infrequently I see a rollout planned for and even less so, planned well.
A few points to consider:
- Migration – moving data from old system to new systems. Who will do this? How will this be done?
- Training – How are teams going to be introduced and trained on the new systems? Is documentation going to provided? Is training going to be provided?
- Logistics – What is the timeline of the introduction of the new system? Deadlines? Are there variables in the timeline out of the dev team’s control?
- Implications – Who will be affected by the new platform? Have they all been made aware of the change? Have they been given adequate resources to adjust for the change?
Wrapping it up
I can 100% guarantee you that if the Provisors development team had created clear requirements, looked for and eradicated assumptions and had a bulletproof rollout plan – you wouldn’t be reading this today.
A few questions to ask your development team?
- What is your approach to gathering project requirements? Do you often develop prototypes and specifications for your projects?
- How do you ensure that both teams are communicating clearly and on the same page regarding expectations of deliverables?
- How do you typically ensure the successful rollout of your solutions in an organization and what support do you provide in that area?
