Lately, there has been a great deal of negative press covering the false start of healthcare.gov. Even President Obama publicly expressed his frustration with the software bugs that remain outstanding. Control Group also has a history of being called in at the 11th hour to fix a project on the verge of catastrophe. Although there have been many great advances in technology over the last four decades, it is still the case that many well funded, high profile projects are late, disastrous, or simply canceled altogether. How can such problems be avoided?
Some have cited that government software teams continue to use the old waterfall model of development when they should be using an Agile model. But even companies that effectively develop products using Agile methods can run into nasty problems. Furthermore, Agile methods are easy to justify for a company that is making its own software products or internal software. It can be much more difficult to get the buy-in necessary from a client when software services are rendered. Especially when companies would prefer to buy software from a consultant in the same way they would buy an iPhone app. It is still too impractical for some companies to pay for technology services without having a list of predetermined “features” and a deadline on paper. For companies that provide technology services, iterative methods alone are not a magic bullet. If one wants to assure the success of a software project, then nothing short of a commitment to success is required.
A true commitment to anything must motivate one to act. Establishing such a commitment starts before the project is in writing. Potential clients must be made aware that they will eventually own the technology they’re paying for. Before any project is done, the consultant must recognize and present all the responsibilities of ownership for a custom solution. Sometimes clients would prefer to engage with no involvement on their end. In situations like these, buyers might not know what they want or what they’re asking for. If a client isn’t involved in this process of discovery and ownership, then success will be determined by happenstance.
Hold Internal and External Stakeholders Accountable
Business development teams at service companies can face intense pressure to win projects. However, if a business developer makes unethical claims or is unaware of the nature of a project, he only stands to jeopardize its success; making promises that cannot be kept will ultimately lead to client disappointment (or worse) down the road. Additionally, clients usually want a scope of specific functionality, which can damage the Agile process if too detailed. Instead of getting “down in the weeds” before the project begins, the sales cycle should focus on building trust and transparency between the consultant and client teams. During the development process, it is imperative to document clearly all agreements so that every contributor and stakeholder knows what’s expected of others and from him or herself in return. These same agreements must also cover all aspects of the project. Any roles or responsibilities that go unaccounted for may imperil the process especially when multiple companies are involved.
Understand and Communicate Technical Risk and Technical Debt
Minimizing risk is key to success. One should rate technical risk according to the experience and core competencies of the organization. Being detail-oriented and up-to-date is a very important part of this. Minimizing technical debt should be a key goal for all engineers working toward a successful release. If reducing technical debt is not possible during a sprint, the team must create a plan for debt repayment. Furthermore, all matters of technical debt and risk must be transparently communicated to the client. Technical risk and debt can be cooperatively managed when out in the open. If its hidden instead then it will eventually become an unwelcome surprise.
Understand the Cost and Value of Technology
If a company commits to a price that’s lower than the cost of a project, that project will not be successful without the consultant or client incurring intolerable risk. It’s impossible to estimate the price without understanding the relevant technology and the associated costs of development, testing, integration, and support. If the client can’t commit to a reasonable price, don’t force a commitment that is out of reach. One way of avoiding this situation is to focus on obtaining projects that provide a high ROI for a business. The tolerance for imperfection on the final deliverable is directly proportional to the business value the software delivers.
Do the Right Thing
One of the core tenets of Agile is managing change using sprints and the backlog. This is critical because client needs always change during a project. Their needs should be accounted for with a focus on a successful delivery at all times. Naturally, every business wants to make money, so the temptation to overcommit is very high. But if one submits to this temptation, all bets are off when it comes to the success of the project.
Sometimes stakeholders try to micromanage the development process. This type of interaction must be limited. Teams that commit to the overall success of a project will likely find themselves at odds with individuals or individual changes. The consultant can either manage counterproductive requests or deliver them. Managing them produces a win-win situation. Delivering them produces a lose-lose situation. Technology consultants have a responsibility to provide good service. In this case, the best service is pushing back.
Gravely Consider the Costs of Failure
No two clients are ever the same, and neither are any two projects. Regardless of the software or relationship details, the most important constant of software development is to keep aiming at a successful delivery (or launch). Consider the end goals during every step of the process; if a software project fails, even after launch, there will be plenty of unhappy people asking questions. Just as a successful business venture between two companies can be a net gain for both, a failed venture can be a net loss for both. Consider some of the consequences:
- Loss in revenue
- Loss of trust
- A damaged reputation
- Workforce attrition
- Legal disputes
A large software failure can even threaten the business itself. In the case of healthcare.gov, the costs are still unfolding. Bottom line: Never commit to a project unless you can also commit to its success.