1. Good Fit
Any successful project must begin with finding a client with a need that your software can actually solve. The right fit doesn’t always mean that the implementation will be simple. In fact, the right fit can involve over-coming technical hurdles or pushing the software in directions it has never gone before. These hurdles, however, should be part of the product road map or make sense from a product development point of view.
“Fit” as a concept can come in many flavors. The obvious one is a good technical fit – does the software already solve the client’s problem as it is, or are there necessary changes to make it fit? Other projects may fit well because of previous experience in delivering similar solutions for similar clients. The advantage to this is that there is existing domain knowledge from the outset. If the problem and the solution are both well understood, it is easier to determine how to best shape the product to meet that challenge.
Where the fit is wrong, it is important to analyze the gap between what is required and what can be achieved. A decision then needs to be taken as to whether there is merit in expending energy to close the gap for future opportunities or if this is simply not a viable direction for the product or the business.
2. Enthusiastic Stakeholders / Sponsor Buy-in
The enthusiasm and involvement of the right stakeholders is critical to the success of any project. Clients can often have real business problems that can be solved with a bit of up front pain and effort, but without the buy-in of the right sponsor (and “right” equals the required level of seniority in many cases) the project is doomed to fail.
Unfortunately, it is often very difficult for the vendor to know who the right stakeholders or sponsor should be, and it is even more difficult for a vendor to influence the selection of such people. It is, however, immediately clear when the wrong people are involved and this realization can often be the beginning of a long, uphill battle to gain the respect and engagement of the participating parties. It will also almost inevitably lead to a more difficult and demanding implementation.
3. Discovery Phase
The key to delivering a successful project to the client is to understand exactly what they want. Unfortunately this is far trickier than it sounds. What the client tells you they want is a good place to start, but this is rarely the whole truth (and sometimes very far from the truth). A good business analyst must separate the “want” from the “need” and dig deep below the surface to extract details of the business problem that people who are involved with it on a day-to-day basis may miss out or, worse, not even be aware they are performing.
In order to mitigate the risk of failing to understand the problem, it is always recommended (if not essential) for a full and thorough discovery phase to be undertaken by an experienced business analyst. During the discovery phase, the analysts must really integrate themselves in the client’s organization. Only through personal, hands-on experience of the business can the true nature of the problem be understood and solutions found. The discovery phase should be split in to two distinct phases – the “Problem” and “Solution” phases. During the Problem Phase the analyst must use any and all necessary techniques to garner as much information about the current process or system as possible. When moving onto the Solution Phase the analyst will begin to build up a picture of how to provide a solution that will improve the day-to-day working lives of the people who are going to be using it. Only from this deep and detailed analysis of the problem can a suitable and viable solution be determined.
4. User Engagement
One thing that project participants should never lose sight of is that the purpose of all projects is to deliver something useful and usable to the users. Business analysts, project managers and developers cannot operate in a vacuum; for all their collective experience of delivering (sometimes very similar) solutions it is vital to engage with the end-users at every stage of the project. Without user engagement a project is doomed to fail in a number of ways. The first, and most obvious risk is that the final solution will not meet the need that the users had in the first place. Engagement with users during the discovery phase and then during the implementation of the development phase will ensure that the final outcome delivers to the user's satisfaction.
Failing to engage with users can also lead to another, more difficult problem to remedy – user adoption. The worst-case scenario for users is to be given a system that they didn’t help to shape and that they subsequently resent. It is rarely the fault of the actual system when it doesn’t deliver to the end user’s satisfaction, but it will be the system that the user gets frustrated with and fails to adopt.
Users who have been involved in the definition and direction of a project will want to ensure that the final solution is a success. They will act as champions of the system to their peers and advocate its use through relating it to the real world context of the original problem. It is highly unlikely that all end users will be involved, so it’s vital that there are user champions who feel a sense of ownership and help the change management transition process.
5. The Right Approach
The right approach will depend on numerous factors such as the size and complexity of the project, the flexibility of the client and level of understanding of requirements.
Adopting the wrong approach can have a negative impact on the project’s success. Clients who are tied to tight budgetary restrictions will often lean towards a “waterfall approach,” where all requirements and functionality are clearly defined and agreed upfront and a fixed cost allocated to the project.
However if the problem is not well understood or the structure of the business changes between contract signature and solution launch (sometimes there is a span of many months) then the cost of remedial development may far exceed the costs of an “agile approach.” An agile approach is an iterative process involving a core stakeholder team who collaborate to identify and evolve requirements and solutions. It’s a pragmatic approach that encourages rapid and flexible response to change and aims to deliver a tighter fitting solution for less cost. Obviously the reverse can also be true, an agile project without clear direction, decisive leadership and a strong project team can lead to a project stumbling along clocking up costs without delivering on the needs of the users.
It’s vital that the chosen approach is right for the clients’ business and that the whole project team (clients and vendor) are empowered to make tough decisions or push back on unrealistic expectations when they arise. Collaborative projects are the most successful
6. Early User Visibility
Regardless of the approach taken on a project, it’s essential to ensure that users are given visibility of the system as early as possible, and that they are given regular updates on progress through demos or access to the development system. As the graph below illustrates, the earlier a problem is detected during a project the less costly it is to fix. If the solution is kept under wraps until a grand unveiling many months from the initial specification, there is likely to be a great deal of expensive corrective work required before the system can be released. Capturing user feedback early and feeding it into the development cycle can drastically reduce the cost of the project and increase user adoption rates.
7. The Right Team
Ensuring the correct team balance for a given project is essential. It’s important to take time to ensure that the right balance is struck for each project team to maximize project success as well as allow each team member the opportunity to learn something from the process.
8. Testing, Testing, Testing
Having followed all of the proceeding seven steps, even the best structured and executed project can be undone by the failure to plan and carryout a sufficient amount of testing. Testing is key to the success of any project, as it will dictate the users’ impressions of the system post launch. A poorly tested solution will leave even the most enthusiastic champions feeling frustrated which can sometimes irreversibly damage their adoption of the system. Too often testing is seen as an optional extra and is the first thing on the plan to be cut when budgets or timelines are tight. However, this is a short-sighted approach as remedial development after inadequate testing is likely to cost more and take longer.
Testing should never be viewed as one dimensional, it shouldn’t be a single block of time bolted onto the end of the project plan in the hope of resolving any bugs or usability issues. Testing must be tackled from multiple angles and throughout the implementation phase of the project in order for it to be effective. During development time should be allocated for peer testing of components by the developers themselves, this kind of testing often uncovers inefficiencies in the code or areas where code can be bundled together into components that can be reused around the system. Cross browser testing should also be carried out during development as fixing all browser issues at the end of the development can be an incredibly onerous and time-consuming undertaking.
As each component, module or phase (depending on the structure of the project) is complete there must be a formal period of system testing, ideally by an external test team but at the very least by a different team of developers. System testing will be carried out against pre-determined test scripts or test cases and will ensure that the tested system conforms to the documented system requirements and functional specification produced during the discovery phase. Finally, prior to release, a user acceptance phase should be conducted with the project team to ensure that the functionality developed and delivered meets the needs and expectations of its intended users. Assuming the levels of user engagement discussed above have been adopted, the UAT phase of a project shouldn’t throw up any nasty surprises from a feature, functionality or usability point of view.
Russ Barr has been with North Plains for more than 6 years and has been running the professional services team in London for the last 4 years. Barr has a background in development, project management and business analysis. He has run projects with major international organizations for more than 10 years.