ArgonDigital - enterprise automation experts

Share This Post

The single most important failure with requirements

A lot of our clients bring us in to fix their requirements issues. Based on the literature a lot of what you see about requirements is geared towards making sure that you write a requirement in the correct way – measurable, testable, traceable and atomic.  Our experience with many Fortune 500 companies leads to a different issue being the most important issue, one that seems easy to solve, but is actually incredibly difficult to solve.

Ultimately software projects get chartered because an executive decided that it was worth spending the money. This should be related to a corporate strategy in some way, but usually is not.  The breakdown and the ensuing issues almost always occur at this level.

The single most important failure with requirements occurs when executives charter a project without a measurable business outcome.

This sounds like an absurdly simple problem to solve, but I assure you it is not. For a variety of reasons, executives chartering software projects are adept at avoiding any sort of accountability for results. What makes the problem extraordinarily hard to solve is that it requires the leaders in the company, the CXOs, to demand that business results be identified from every program. Surprisingly this doesn’t happen very often.

The lack of clarity around measureable business objectives drives a lack of clarity to the entire rest of the project. This doesn’t mean that all projects will fail – often times project teams deliver a reasonable quality product that does generally the right things. These cases are when the issues are so completely obvious that it is virtually impossible for anyone to get it wrong. But more often people on the project invent many different reasons for why a project exists.

This single issue can result in a myriad of project problems. The issue manifests in many different ways including:

1) Projects go massively over budget because of scope creep

Scope creep is extremely easy to solve if you know what you are trying to achieve. Typically scope creep is introduced for areas that have nothing to do with the core purpose of the project. The ideas will always be good ideas, just not key to the measurable value of the project. On one project we worked on, the value was a $20M one time gain with a $20M yearly gain. The project cost was $2-3M. The stakeholder team (developers, project managers and business users) consistently wanted to add features that made the business users’ jobs more streamlined. The software would already increase their productivity, but not as much as they wanted. Because of a focus on the return (unrelated to productivity), we were able to keep the scope creep out of the release and deploy much sooner.

However on another project, the executives refuse to assign business objectives to the project and the business users keep asking for additional features that are “critical”. When we evaluated the return on the features, the return is literally almost zero and the cost is in the high 6 figures. This project is extraordinarily late and has no clear direction.

2) Projects are constantly short of resources because too many projects are being worked on

One organization we work with consistently charters too many projects. The money is there, but the resources simply are not. This means that many projects get started but then stall or are poorly deployed because key resources, including developers who know the ecosystem are simply overworked. We started on a project once that had a $4M yearly return. This was not bad, except that there was another project that had a $100M yearly return. We recommended to our stakeholders that they cancel our project and move the entire team over to the more valuable project. They chose not to and neither project has significantly deployed (6 months late).  Under resourcing all projects by a little (or a lot) results in no projects being deployed well. A better strategy would be to identify the top projects by business objectives and resource them adequately. The I want it all strategy is doomed to fail.

3) Projects get canceled due to lack of interest

Projects often get chartered due to the charisma of a single stakeholder, but because there isn’t any business value they often eventually run out of steam. This actually is a better result than a project that keeps trying to deploy because canceling the project saves a lot of money. This could be avoided in the first place by proper portfolio management based on measurable business objectives.

4) Projects deliver but don’t get used by the users

This is a difficult one. We see this happen quite often and depending on the environment it may or may not be a problem. In one of the examples above, the users didn’t want to use the software because it wasn’t as easy to use as they would have liked. Yet the company could immediately get a lot of value from it. In this case it was worth it to deploy the software because the value was there and when it was explained to the users they were willing to take a usability hit to get the value. I feel bad for the users because they are the ones to suffer from these types of decisions. However I do believe that the organization is committed to successive releases that will improve usability and the cost of those is incorporated into the overall ROI . In cases where the business does not support the value the software simply does not get used. I have seen sales VPs tell the CEO that if their teams are forced to use a particular release of software that they can’t hit their very public revenue targets. This game of chicken can be avoided by making sure there is agreement at the executive level of the value of the software.

If your organization has a culture of accountability then you might already be doing these things. Our experience is that most companies have a lack of accountability for measurable business results when it comes to deploying software. As a lowly BA or IT product manager you aren’t going to be able to change the business objectives or corporate strategy, but in our experience you can make sure you understand them and even rewrite them for your team in a measurable way. This requires you to step up and choose to be held accountable. If you are able to do this and can achieve results, I assure you this is the best way to get on the career fast track.  Are you up to the challenge?

The single most important failure with requirements

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage