Our question checklist focuses on getting our problem solved and crafting that solution. However, we also need to support the solution. We want to avoid many pitfalls; the most difficult one to recover from is a lack of foresight. This challenge comes from keeping our focus on the initial solution without considering its downstream and long-term impact. 

Impact Of The Solution

When we answer the other questions in our checklist, we examine how we might need to create or change processes. Likewise, we incorporate the immediate impact. We often will project the value of those changes beyond the product launch. However, customers often overlook the need to support and maintain a system. That burden can rest entirely on the vendor, but often there is no way to avoid some of it falling on the end users or the customer. These burdens include everyday tasks like support and training that are easy to highlight and discuss. Nevertheless, they are often overlooked. Likewise, systems costs such as hosting, storage, backup, updates, and security are frequently missed. 

Items Needed To Support The Solution

Everyone loves a list in an article like this. So here are some questions we want to address to support the solution properly.

• How is the source code hosted or version controlled?
• Who owns the rights to the source code?
• Where will the solution be hosted? What are the estimated costs for it?
• How will backups and disaster recovery be handled?
• What user support is provided/expected? What SLA is expected?
• How will user data be administered?
• What sort of staffing is expected of the customer? (or available)
• How will future updates and maintenance be supported?

Now And Future Resource Needs

We need to address implementation resources before we go too far into discussing post-deployment questions. The decision of build vs. buy and initial configuration can be limited or at least weighted by current resources. For example, there is a significant difference in a company deciding to build their solution when they have an IT department instead of when they do not. Be warned this can apply to purchased solutions as well.

Modern software is often complex and touches other systems. Integrating current or legacy systems can require advanced coding skills or a matter of drag and drop in a graphical user interface. The expectations and available resources must be identified early in the problem definition process. Those times might need some lead time or significantly impact costs and timelines.

Determine Ownership Of The Solution

The questions above help us define who will own the solution once it is deployed. That includes support and maintenance as well as future enhancements. While some of that can be deferred to later (e.g., version 2.0), it is essential to know who will be involved post-production. There are many reasons to want to own the support of a project. On the other hand, there are also many reasons to desire support to be outsourced. The vision for the system can be as crucial to your plans after deployment as it is running up to that deployment.

Source code and related questions, including artifacts like technical documentation and build scripts, are commonly overlooked. However, I find most customers only do that once. It can be a harsh lesson to learn. That applies to whether you are handed the keys to the solutions and do not want them or when you want them and have to pay extra for that privilege. These details are critical to your decisions about how to support the solution once it is in production.

Training, Documentation, and Building The System

A final area it is worth highlighting is the above deliverables. It is not as common that the delivery of the artifacts is unclear as it is the expectations. There is a broad range of ways one can deliver documentation, train users, and build the final product. Be clear about what is expected and discuss it early in the project. I have seen many projects get to the end on time, and then training and documentation sink the project. Do not allow these to be pushed to the end of the project. Demand that there is work done towards these goals and time to review the materials well before the end of the schedule. Avoid these artifacts being delivered in a rushed fashion after the implementation group thinks they are done.

Improve Software Success

We have an e-book that can help you explore all the steps in building software, including a few templates. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here. We are happy to help you in your journey if you would like to invest a little more time into planning for your project. We offer free consulting to avoid seeing avoidable mistakes. Please take advantage of it and avoid being the next cautionary tale.