You’ll easily find statistics online about failure rates of IT projects that can make you dizzy: Some sources even claim failure rates of up to 50%. As a matter of fact, if you compare large construction projects with large IT projects, IT projects get out of hand twice (sic!) as fast – according to a study by the consultancy McKinsey (“Black Swans in IT Projects”). This either affects the budget or the time frame. In the light of such risk, it is worth paying extra attention to the management of software development projects with external IT engineers. Here’s 8 best practices that will help you to make your software projects a success (in scope, in time, in budget).
Well-considered decision: Tailor-made software vs standard software
Native Digital Companies such as Amazon or Zalando use software that is tailor-made for their business model, their workflows. It enables these companies to establish a sustainable USP over competitors by implementing streamlined workflows and ensuring a high level of automation. You may also achieve streamlined workflows and a certain level of automation with off-the-shelf-software, however, tailor-made software allows companies to adapt with agility to (changing) customer expectations to an extent that is not feasible with off-the-shelf-software. But this doesn’t mean companies should generally target for tailor-made software.
While it is true that developers are increasingly working with building blocks or prefabricated modular components, which means that individual software can be created more quickly and cost-effectively. Nevertheless, the use of a standard software should always have priority, a tailor-made software development should only be pursued if the standard software cannot meet the requirements or if needs can only be met with disproportionately high customizing efforts. Why? – Tailor-made software development sometimes appears to be the more convenient way, as it is always assumed that 100% of the requirements can be met in this way; however, this would grossly underestimate the various challenges that come with tailor-made software: Time investment, monetary costs, long-term maintenance requirement, etcetera.
Therefore, before considering a software development project you should thoroughly evaluate standard software, invite promising software vendors for workshops and to make the decision pro / contra individual software on a broad information basis.
Creation of a requirement specification document
You have to start out from the assumption that most people dislike documentation. It is rather an exception that software developers can start out their work with a nicely structured requirement specification document; it is more likely that a Kick-Off workshop starts with a collection of inconsistent requirements and a few sketchy ideas. It is left to the software architects and designers to turn these ideas into a fully automated IT solution.
Just to avoid any misunderstandings: The era of Waterfall projects with detailed specifications has ended (there is exceptions, though), today it’s all about Agile Project Management. But it’s a misconception to assume that a (rough) requirements specification is not necessary anymore. Even if one may agree to use an agile project management method, a (rough) specification sheet remains crucial. A well-structured requirements specification serves several purposes: First, such a document is the most efficient way to inform several IT providers and to provide them a basis for an effort estimate / proposal. Secondly, it forces the client organization to align requirements from different departments and stakeholders towards a consistent requirement specification; a well-structured specification makes inconsistencies visible and brings about the process of cross-departmental agreement. Thirdly, agile project management methods such as SCRUM also know elements such as release planning, for example for the indispensable time and budget management.
For these reasons a (rough) requirement specification document remains indispensable. The more specific (and unusual) your business processes are, the more detailed the document must be. As a thumb rule the document should be as lean as possible and thus leave enough room for solution approaches. However, it is imperative that quantity structures are specified (for the purpose of an adequate software architecture and choice of technology). And: What scalability characteristics may be required within a 10-year horizon?
It is common practice that the client organization “outsources” the editing of the requirement specification document to a third party IT service company. The typical reasons for such approach is time pressure, bottlenecks or lack of technical qualification. However, I do strongly recommend to generate such document with inhouse resources: Digital products, Software Applications and Data have become strategic assets, a company (of any size) should strive to develop, grow and maintain as much inhouse digital knowhow as possible. If such competencies are not yet available, they must be developed (possibly with the help of a coach, who – unlike the consultant – does not moderate the process himself, but only acts as a mentor / guide).
Contract design: Fair distribution of risks
Here’s the best case scenario: Detailed specification and low technical risks. Contract negotiations in this scenario will prove very simple: Both sides can easily agree on a fixed price, and it is easy to compare proposals of different IT providers. The payment schedule is aligned with milestones in the development schedule. Important: With the acceptance of the product increments at the end of each milestone, the client organization must have sufficient resources available for testing.
Contract negotiations turn out more challenging, if there is only a generic target, whereas the outcome of prototype development in the first one or two sprints (SCRUM-based Software Development Process) will allow more detailed software design and definition of the technology stack. On the one hand, no IT Service Provider will take the risk involved with a fixed price proposal, on the other hand, the client organization wants to avoid a time&material contract that may end up a cash burning exercise, comparable to injecting money into bottomless pits.
How to tackle this challenge? Generally, there’s no limit to the ingenuity of Contracts design. The two parties can apply different payment terms and risk sharing agreement to each phase of the software development project; and while uncertainty is high in the initial phases of the project, effort estimates can be calculated more reliably in later phases of the project. For the given scenario it may be advisable to start with a “fixed price per sprint” (plus a success fee for a specific deliverable) and shift gradually in later phases of the project to a fixed price for software components once the prototyping stage is successfully completed and the technology stack is determined. The contract must certainly contain a clear provision on how to define requirements and provide effort estimates at the beginning of each iteration in the agile development process.
One thing is particularly important to ensure that the client’s negotiating position does not become too weak once the project has started. Typically, once a development project has been started, the costs of switching the Software Development company soars massively and the client’s willingness to switch decreases. Project developers know this. The client can effectively counteract this with the following measures: code and architecture must be documented from the beginning (ideally in English), the source code is handed over to the client upon completion of each milestone.
Request the developer profiles
Most IT Service Providers submit a proposal by default with the information on the dedicated team for the project. If such information is missing, the client organization should ask for it. The CV’s allow you to determine whether the IT professionals in the dedicated team have sufficient expertise in the domain of the project and in the target technology stack.
Set up a project organization to enable quick decision-making
Make sure, you can take necessary decisions fast. For that purpose an efficient project organization is required. It is common to create a Steering Group, that comprises representatives (e.g. line managers) of those departments that should have a say in the software project. It is wise to have a project sponsor (often: the managing director / board of directors), who receives status reports at regular intervals and can be called in at short notice for decision making / escalation.
The project manager‘s task is to keep this steering group up-to-date on progress and challenges of the software development project, moderate discussions and ensure timely decision-taking. If the software development project is working with the agile project management method SCRUM, it is advisable to involve the representatives of the different functional areas in the so-called sprint reviews, where product increments are evaluated and the next requirements are defined/prioritized.
Take technological decisions on your own
In many medium-sized companies, where IT (supposedly) has no strategic relevance yet, IT departments (if existing) struggle with staffing bottlenecks. In some cases IT departments consist solely of a few IT administrators; requests for the evaluation of technology stacks for software applications remain unanswered. In such situations it is tempting to give in to the obvious impulse to hand over such technological decisions to the “experts from the Outsourcing Company”. However, this is wrong.
The availability of technologies has exploded, web projects can be developed in Java, PHP, C#, etc., databases range from Oracle, MS SQL Server, mySQL to dozens of NoSQL databases. Every technology has strengths and weaknesses, trade-offs have to be made that cannot or should not be made by an external software developer alone. External software developers as well as the project manager of the client organization should therefore work out the relevant decision criteria for each technology decision (low development costs, easy maintenance, scalability, …), weight them and then evaluate the technologies in question. It is a no-brainer that these decisions must be well documented.
Early prototypes
It was already pointed out in connection with the drafting of the contract that I strongly recommend a milestone-oriented development. The results of each milestone must be software products that are fully executable (even if still limited in their functional scope).
This recommendation has such a high relevance that I have dedicated a separate point to it. Agile project management methods in particular are characterized by the fact that development results are available at an early stage, so that erroneous developments can be immediately counteracted or corrections can be made immediately in the next development cycle.
Sufficient Documentation of decisions and the like
This point is also a no-brainer, but it’s often neglected: Sufficient documentation of decisions, of user acceptance test and the like. This is the only way to identify inconsistencies in requirements, to enable the project steering group to comment on them and – worst case – to provide a basis for discussion with the external software developer in the event that requirements are not met.
Important in connection with documentation: In today’s multi-channel communication, documentation snippets are often found on various channels: email, recorded video calls with ScreenRecording, WhatsApp or team chat. Documentation becomes usable in practice when it takes place in a uniform format in a consolidated document (or at least: folder). Only then can one speak of usable documentation. A common data space (for example, on NETFILES or similar secure platforms, NOT: DropBox) is usually a prerequisite for this.
