Creating Programming Projects Based on Customers’ Needs

Behind almost every IT project is a business requirement – but how do you ensure that the end product truly meets that business need? It’s easy for system integrators, computer programmers or software programmers to sit in a meeting and listen to what their clients say they need a system to do. But often, what they ask for and what you think they mean are two different things. And when your solution misses the mark, there’s no one to blame but you, leaving you wide open to an errors and omissions lawsuit. With any project involving programming or system integration, E&O lawsuits are always a risk. There are many opportunities for professional liability when designing, programming and implementing these projects. For example, if there’s a lapse in network reach, mission-critical applications, uptime, systems integration, scalability or network performance, there’s an opportunity for your client to claim that you didn’t do what they asked of you. If that claim escalates to a lawsuit, you may be in for a lot of hassle and expense, especially if you don’t have the right professional liability insurance for system integrators and programmers. And even if you’re not sued, you want to get the job done right the first time to avoid costly re-work and change orders. Good Project Management Is Good Risk Management So how does a system integrator or computer/software programmer translate a customer’s business need into a solution that solves the customer’s problem? It all comes down to project management. Companies with poor project management are far more likely to have professional liability claims than those with formal project management processes in place. In other words, good project management equals good risk management. According to project management expert Karl Wiegers, defining a project’s vision and scope is a critical early step in project management. For each project, you should clearly define: • Business requirements. These provide the foundation and reference for all detailed requirements development. System integrators and computer/software programmers can gather business requirements from the customer or development organization’s senior management, an executive sponsor, a project visionary, product management, the marketing department, or others who have a clear sense of why the project is being undertaken and the value it will provide to the business and customers. • Vision of the solution. Establish a long-term vision for the system that will be built to address the business objectives. This vision will provide the context for making decisions throughout the course of the product development lifecycle, and should not include detailed functional requirements or project planning information. • Scope and limitations. Define the concept and range of the proposed solution, as well as what will not be included in the product. Clarifying the scope and limitations helps to establish realistic expectations of the many stakeholders. It also provides a reference frame against which proposed features and requirements changes can be evaluated. • Business context. Summarize some of the business issues around the project, including profiles of major customer categories, assumptions that went into the project concept, and the management priorities for the project. 10 Requirements Traps to Avoid Wiegers also points out that successful software projects are built on a foundation of well-understood requirements. However, many system integrators and software/computer programmers get caught in traps that prevent them from effectively collecting, documenting or managing their requirements. Several symptoms indicate that you might be getting caught in a "requirement trap": • Confusion about what a requirement is • Inadequate customer involvement • Vague and ambiguous requirements • Un-prioritized requirements • Building functionality no one uses • Analysis paralysis • Scope creep • Inadequate requirements change process • Insufficient change impact analysis • Inadequate requirements version control Speak Your Customer’s Language As you develop your vision and scope document, it’s important to ensure that you and your client are speaking the same language. To reduce professional liability, system integrators, software programmers and computer programmers should keep in mind that they know the technology inside-out – but their customers usually don’t. If your project documents are too technical, your client might be left to assume that they will meet its business need, when in fact you may be missing the mark. When that happens, you may be several months into the project before the problem becomes clear, and that’s when you’ll see “scope creep.” Suddenly, meeting the client’s need is going to take longer and cost more than agreed. That’s a recipe for disaster, because at this point, some customers stop paying and hire a lawyer. By clearly defining a project's vision and scope, and paying close attention to project requirements, you can create a project proposal that will fulfill the business need, keep costs contained, and reduce the risk that you’ll end up facing an E&O lawsuit down the line. Remember: for software and computer programmers as well as system integrators, professional liability and risk management go hand-in-hand with good project management.