Let's imagine the following situation: a company needs large-scale custom software to get to the competitive edge. It succeeded in finding a reliable vendor, a software company that works with cutting-edge technologies and had previously created solutions of the same type. The vendor's project team understands the basics and processes of the customer's business and it is led by a talented project manager. The project costs seem to be acceptable, too. So can the customer company give a go-ahead and wait for the project deliverables? Certainly, no; if it does need a solution to effectively support its business, it should get ready to be involved in several months of literally co-working with the vendor team, which demands a significant amount of time and engagement from the start.
Below, we examine the aspects of the customer’s participation more closely.
Provide enough requirements
Despite this task may seem obvious, its complexity lies in achieving the common understanding of ‘enough’ by the customer and the software development company. The main challenge is to agree on how detailed the requirements will be and then to make sure all the project participants keep to it.
In this aspect, there are the following customer engagement options:
Option 1: Unstructured business requirements
In this case, information is gathered at interviews with the customer’s project stakeholders or at requirements workshops. This process is normally led by the vendor’s business analysts who further complete and submit a detailed software requirements specification for the customer’s approval.
The customer’s passiveness in this case may result in a badly outlined project scope and deviations in determining functions’ priorities. In its turn, these mistakes at the early stage mean further change requests le
ading to increases in the project timeline and costs or even to the project failure.
Option 2: Structured business requirements
The customer may provide the vendor with the solution-related business documentation, as well as a Product Vision outlining the business needs and reasons for software implementation. The Product Vision can include the following short sections (every section is no more than 20 lines long):
- A product statement giving answers to questions, such as ‘Who is the customer?’, ‘What does the customer want?’, ‘What is the market offering now?’, ‘What is wrong with existing solutions?’, ‘How should the software fix it?’
- Stakeholders (both positive and negative ones) and their needs.
- Product actors and features. Every actor has 3-6 features; each feature is described in 2-3 lines.
- Up to 6 key quality requirements. All of these should be measurable. For example, "Any webpage must open in less than 300 ms" instead of "The website must be fast."
The customer’s IT department should bear in mind that writing a concise Product Vision can take quite a lot of time. However, this exercise is of great importance as it enables to align your software-related ideas with your business needs.
Option 3: Structured business requirements, supplemented with detailed ones
In this case, the customer adds more details to structured business requirements. Business requirements reflect the organization’s goals, while details are all about software end users’ preferences. To compile them, the customer needs to involve not only its management and the internal IT department but also all types of end users (for example, by interviewing some employees or carrying out focus groups meetings).
This type of the customer’s engagement is the most time-consuming one, yet it enables getting the most precious customer’s input.
Answer clarifying questions
No matter how detailed the customer’s requirements are, it is normal when the software development company asks additional questions at all project stages. The ball shouldn’t be kept in your court for a long time; it is important to give clear answers promptly so that not to hinder or delay the development process.
In case the customer’s IT manager is not able to give the answers on his/her own, s/he has to contact relevant stakeholders, for example, other departments’ managers or end users.
At different project stages, the vendor will provide both user-related deliverables (such as UI mockups, vertical prototypes, intermediate software versions) and technical deliverables (such as the software architecture, the source code, test documentation). All of these elements, as well as further corrections made by the vendor in response to the provided feedback, should be checked and approved by the customer.
To ensure a quality review of technical deliverables, the customer may consider the option of hiring one-time independent reviewers.
The point is that the customer’s involvement and feedback motivate the project team (even if the latter proves that some bugs found by the external reviewer are not bugs as such). And, most importantly, if the customer accepts inappropriate or low-quality deliverables, it misleads the vendor and is likely to impact the contractual terms and conditions. It isn’t rare that software needs to be reworked at additional costs after the intermediate deliverables have already been accepted.
Monitor the progress and budget
Software projects often go awry, which results either in delay, additional expenses or even project termination. Here are several examples from the American financial, food, retail, healthcare, telecommunications, computer/IT and manufacturing industries, respectively:
- In 1993, Allstate Insurance Co.'s office automation system was abandoned after the deployment worth $130 million.
- In 1999, Hershey Foods Corporation lost $151 million due to problems with its ERP system.
- In 2001, Kmart's SCM system was cancelled after $130 million had been spent.
- In 2002, problems with a CRM system contributed to a $445-million loss for CIGNA Corp.
- In 2003-2004, AT&T Wireless faced CRM upgrade problems, which led to the revenue loss of $100 million.
- In 2004, Hewlett-Packard's problems with ERP system resulted in $160 million loss.
- The same year, Ford Motor Co.'s purchasing system was abandoned after its deployment costing approximately $400 million.
Although the monitoring function is normally assumed by the vendor’s project manager, the customer should check the progress and control the budget regularly, too, especially when paying for the software based on the times-and-materials (T&M) model suggesting there can be changes made to the software requirements and scope in the course of the project.
Along with the vendor’s project manager, the customer should deal with risk identification and management. This type of activity seems to be even more important than reviewing project progress and budget as software developers tend to be too optimistic and underestimate project risks. In addition, risks can arise on the customer’s side. For example, local industry regulations may change or key managers required as project consultants may become unavailable. It is customers who have to resolve the above difficulties.
Having a professional vendor and sufficient investments are not enough to ensure successful implementation of a custom software solution. The project outcome significantly depends on the customer’s constant involvement, which includes providing business and technical requirements (such as contained in the Product Vision), answering the vendor’s questions, reviewing interim user-related and technical deliverables, checking the project progress and budget (especially for T&M projects), as well as anticipating and addressing risks. The more engaged the customer is in the above-mentioned project activities, the more chances are that the solution will finally fit its business needs.