A quick note on project failures and requirements.
As you have probably already read in many places (and, by the way, there are excellent reasons why this subject is recurrently discussed), analyses of causes for project failures are conducted almost continually, and you have seen various rankings as to which the most important factor is (in terms of frequency or impact). You can check this article, or this one, or yet even this. The idea is: this will necessarily be discussed till the end of time (approximate date).
This is so because, no matter how developed the methodologies and approaches are for IT project planning, design, building, deployment and implementation, failures are still very frequent.
I will just point (and will subsequently try to explain why) that
– Requirements are by their own right in all the lists of popular reasons for failure, and frequently make it to the top two or three (others are availability and cost of resources, lack of proper coordination and coordination across stakeholders, poor estimates and risks management – but the list is long, and your experience may include these here and/or additional ones)
– There are a number of reasons that explain the issues we typically see with requirements in IT programs & projects (I may either point to examples or include in later posts practical examples and/or articles by specialists)
– This is not specific of IT-related initiatives. In my view, this also happens in other fields (such as engineering at large, architecture, social media management, etc.), and the foundations, discipline and sound practices that will help you avoid these issues are applicable in all of them (by the way, you are more than welcome to comment on those in this blog)
Then I will summarize a number of ideas, practices, etc. that I have found to be useful in practice.
The key reason why requirements are usually the most critical issue in project planning, scoping, design and implementation (and also in acceptance) is simple: they are the “what” (and often the “how”) of what your system will do (and by ‘system’ I do not only mean the applications, but also the business & ancillary processes that they support and the various users). There can be no project without requirements: in extremely immature organizations they might, like contracts, be verbal, or implicit, but when developers set to work they certainly have some intention in mind as to what the system will do.
Naturally, requirements are the most important cost (and price) factor in any project (then, of course, you may have some restrictions that increase delivery costs, some specialists are more expensive than others, some packages require more work than others to tailor, etc.) If you ever participated in a project where money was left out of the question, please comment your experience. I am extremely interested because in mine, budget was always in the center of the stage.
Furthermore, adding new requirements, or changing them, usually has a very significant impact on project costs and schedule (and often, also in quality): scope creep is quite a familiar phenomenon in the project development domain. By the way, the further down the road modifications appear, the bigger the impact (basically, because rework impacts more tasks: pretty much, everything you did to the point when the requirement changed).
Consequently, methodologies have traditionally emphasized the need to systematically manage requirements from beginning to end. The V-model is one example.
Secondly, requirements are usually a moving target, for several reasons:
1) It is not easy to get all requirements right from the start (and you will usually feel pressure to achieve that because, guess what, the client wants to have a closed, final budget for their program). Many factors, such as lack of time, difficulties to figure out all the necessary contacts, availability of the required specialists, schedule conflicts (to name a few) frequently make it impossible (by the way, these are some of the reasons to resort to iterative approaches such as Agile project management).
2) For companies spanning over different countries or markets (NB: you may have different markets in the same country: for instance, in the US the Latin market may have to be dealt with differently) you may have different and frequently conflicting requirements. Sometimes you may have strong governance in place and a central task force in charge of signing requirements off, and empowered to do so, on behalf of all business units and geographical areas, but even in those cases there may be technical challenges and cost increases. E. g., you may use logic branching based on parameters in order to accommodate the different needs, but you must test all the ramifications anyway.
3) There may be implicit or hidden requirements. E. g.:
- Users will normally assume that everything that current systems and operations do satisfactorily will be done at least just as well by the new one. And it is unnatural to consciously reflect on things you do ‘naturally’ (unless, of course, they want to change some specific feature). New requirements, however, are (relatively) easy to capture.
- There are many ‘technical’ requirements about which business users may not be aware (those related with the engineering sturdiness, etc. For instance: those related with maintainability, coding standards, modularity, etc., or even others somewhat closer to the user such as availability, monitoring, data integrity)
- Some requirements, such as legal & regulatory are often not obvious to implement and cascade down through processes and systems. However, users will usually assume that “everything complies with all applicable regulations” (after all: “you should always comply with the law without me having to tell you!”)
- We all have implicit assumptions as to (what we consider to be) the logical implications or any given decision, but our assumptions may not be the same than those of other people. Therefore, the derived requirements may not be implemented if we failed to communicate our assumptions properly.
4) There may be legitimate changes in business environment, organizational needs, regulation… (E. g., need to react to new product launches by competitors, permission received to enter new markets or sectors, obligation to apply new tax rates or deliver official reports on a given date, etc.)
Then, many different areas and individuals in the company may have a saying in formulating them and, as you probably already imagined, their opinions vary & often conflict. Note that even if you were so lucky as to finalize and have requirements signed off before you started design, you may find out much later that… ops!: you did not get the approval of some important guy in a far apart area, totally off your radar…
Note also that changes in the leadership of a stakeholder area can have a very significant impact on your requirements, so you better monitor the environment – especially if the new head comes from another area, for instance.
Additionally, if you want to get requirements right, then you have to manage their lifecycle. Requirements have an interesting life, mind you: they are formulated and re-formulated, validated, verified, challenged, updated, ignored, discarded, reborn, implemented (to varying degrees…) Of course, you want to have someone with authority to sign them off just like that, but often you will be lucky if you can have a reliable, predictable process whereby, by following all the necessary (and maybe clumsy) steps, you can make sure that ‘everything is under control’.
A huge area of risk, of course, is requirement validation: say you happily got with your (hopefully) complete list of well-formulated requirements. Then, you have to analyze them in order to gain an in-depth understanding of the implications (of course you can do a lot of validation while you gather the requirements, but this is irrelevant for the purpose of what I want to highlight here). What if your star requirement requires a change in the core of the package, which the vendor does not support/approve?
There are also ‘soft’ issues as well: because requirements are so important, people can become extremely sensible about them. For instance, you may want to make sure (even before starting creating your requirements), that users are aware of the need to adapt to the limitations of budget, schedule and technology, so you evangelize about that in order to avoid misunderstandings down the road. Well, chances are, users may suspect that you are questioning their authority or credibility, that you are trying to have it your way, or that you have your own agenda.
Organization culture is also critical – you must know your client. Some organizations are more structured, focus on contracts and formal agreements, whereas others tend to be more flexible (but will also expect flexibility on your side). For practical reasons you will want to adapt your methods and ways to it. The best approach is not alway the same: if you prefer to be rigorous, clarify everything up-front, etc., but the organization culture is not aligned with your preferences, you will get frustrated and irritate people by insisting in having everybody follow a disciplined approach.
In any case, in general, for the reasons mentioned above, you have to use all your weapons to identify your requirements, get the best understanding of them by all stakeholders, manage their lifecycle and track their implementation. Some suggestions:
– Keep an eye on those requirements which were most discussed or questioned, especially at transition points and hand-offs (e. g., before starting the technical design, or building the application).
– Make sure your architecture and technical decisions overall are able to accommodate potential changes (e. g., you may choose to introduce configuration parameters wherever you suspect there may be a change… or if there is uncertainty). Be aware of the associated impacts on cost & schedule, though.
– Make sure to use a tracking mechanism (can be a spreadsheet) for requirements, and make sure that all along the life of the project they are implemented, communicated and verified (i. e., they are included in the design, they are built, unit tested, etc.)
– Keep a check-list of potential issues that surface in requirements analyses, and update it based on your experience (you will get even more benefits the next time you do a project)
– Try to unearth all possible requirements. There are a number of things you can do, e. g.:
- Review current systems, INCLUDING manual procedures. You will get a good grasp of things that you have to include (‘hygienic stuff’, if you want: you do not get the customer any more satisfied by implementing them, but you surely will frustrate them if you don’t), or improvements (e. g., by removing manual steps)
- Use as a reference functionality included in commercial packages (or configurable), including those not selected by your client. You will get some ideas as well.
- Review lists of requirements in other similar projects. Do list also those requirements that will NOT be implemented, and make sure that stakeholders are aware of this.
- Do not forget help systems and tutorials, FAQs, support forums… The scope and extent of the help provided is a very important factor. Are you providing it at the process level, at procedure levels? Are you explaining the different steps in the application, the various ways to fulfill a given operation? Are you providing information as to the meaning of the different pieces of data, their dependencies & life cycle? Are you creating a training environment?
- Conduct a separate review of technical aspects of the architecture involving operations (monitoring, backups & recovery, administration, security, etc.) It is not only about how business users will operate, also your data center folks have to be considered as users. For instance, note the importance of establishing the conditions under which the targets for technical requirements such as throughput, response times, etc. will be achieved (number of concurrent users, number of transactions at peak hour, etc.)
- Bear in mind dependencies and de facto standards. For instance: if you create applications for Apple devices, you must be aware of the standards you will be required to comply with. Make sure to review them at least at each single handover point (e. g., starting the construction phase), since they can change any time.
- Take a look at what consumers say online, in forums or elsewhere, about your client and competitors – not just the bad things, but also the good ones: they are either things that you don’t want to break (if it is your customer, whom they are praising), or things you will want to replicate. In any case, you will often find out some hidden requirements for your client to implement. Often, it will not be a pure matter of applications (also practices, communication approach, community management features and so on), but surely they will be involved. Increasingly organizations use opinion analyzers to conduct sentiment analysis, so many will be able to help you with this task.
- A document can be read in many different ways (especially regarding what each of us reads between the lines, or the implicit assumptions & consequences we draw from the written text). In many cases it may be helpful to prototype parts of the system in order to clarify how it is going to operate, when events are going to be triggered, what workflow will be used, how errors will be communicated, etc. (proprietary methodologies typically include some guidelines as to when prototyping is indicated – based on novelty, complexity, etc.) Of course, common sense is necessary in order not to build the full system!
In summary, you can quite confidently ruin a project by
– Failing to capture and communicate them. Remember that the requirement set is an iceberg: you only ‘see’ a part of it – and not necessarily the biggest.
– Failing to manage their lifecycle: requirements have an interesting biography!
– Not realizing what the universe of the problem is: business units, geographical areas, legal & regulatory aspects, etc.
– Failing to get the proper sign-offs. Know who is authorized to sign them off, be aware of changes in the organization, do get formal approvals. Do have a process in place governing them.
– Not drawing the right consequences/implications of changes (in terms of cost and schedule impact)
Gathering, refining and managing requirements is an inexhaustible theme. I will be more than happy to see your comments, hints, recommendations, etc. here.