Leon has worked with multiple IT systems from ERP to BI and PLM. His experience ranges all the way from programming to business consulting, project management and business development. Leon started his career in IT development and has further earned a diploma in IT and Economics at Copenhagen Business School and an Executive MBA at Henley Management College.
Companies are still not good at defining requirements for their technology solution – and that is why their investments fail!
One of the biggest reasons why technology projects fail is because companies are poor at defining requirements for their solutions.
This is not the first time I am talking about this topic. Over the years, I have complained to colleagues, friends, and family about it. I have even written a series of articles on the matter.
This chart fueled me up to yet again talking about this topic. In general, many organizations are unable to reach the desired state for their technology solution. Most are not able to complete the project on time or budget, usually because of last-minute additions or changes to the solution.
What happens next is that top management perceives that as a problem and concludes that the project is a failure. But instead of looking for people to blame, top management should start looking at their own ability to define:
- A: What the organization really need in a solution
- B: How they have communicated their requirements to the chosen solution
Requirements definitions today are too broad and general
Maybe I have been in the technology industry for too long. But for so many years, and still, to this day, I receive RFP’s (Requests for Proposals) from companies searching for a technology solution where the requirements definitions are so vague and general.
Need inspiration to define your requirements? Check out this blog post: 7 company-wide strategies you must not neglect in PLM
Let me give you two real-life examples:
- Requirement 1: The solution must be easy to use
- Requirement 2: The solution must be able to perform Engineering Change Management
These requirements are – to be honest – not requirements at all. They are so basic that they are useless. And you would be surprised if you knew how often I receive requirements like this. The problem is that organizations define requirements so vaguely to fit with every available solution on the market.
And during the solution evaluation phase, the requirements definitions become more solution-specific and ends up matching exactly to the chosen system.
Instead of looking at their own business and carefully consider how a solution could offer real business value, they hand off the responsibility for their own implementation success to the technology provider.
You need to flip it around
Why is it that organizations do not spend enough time building real requirements definitions? I mean, if you were building a new house you would not just tell the developer to build four walls with a roof on top of it, would you?
Organizations usually have a solid understanding of their own business drivers. But oftentimes they fail in translating these business drivers into capabilities and features. The result is that they do not know which requirements are a must for their success and where to compromise.
If you do not understand what you want and need, how can you know if you have chosen the right solution?
Listen to experts
Now, I am not naïve. Of course, you should not and cannot know all details in your requirements from the beginning, but you must understand what it is that makes your company unique, what your business drivers are and where to compromise and not to compromise in a solution.
It is a mystery to me why organizations are incapable of improving their ability to define requirements. What is the excuse this time?
- Not enough time?
- Does not want to start a war between departments who presents conflicting requirements?
- Just want a solution that fixes the problem right now?
No matter what the excuse is this time, it is a stupid excuse. Remember, if you want change, you need to start changing your own behavior.
3 tips that will help you improve your ability to define solution requirements:
- Understand your own business, what drives the business forward and where a technology solution can help you improve that area and provide you with real value. Maybe your engineers are spending too much time on documentation and less time on innovating? How can a solution solve that?
- Seek out experts. Have them look at your business and give you advice on must-have requirements and where you can compromise.
- Get your priorities straight! Ensure that there is support throughout the organization from top management to the individual departments. With clear priorities, clear objectives and clear requirements, your are closer to reaching the goal.
Enjoyed reading this blog post? You might also like this:
Did you know that the number one reason why technology implementation phases fail is because of the lack of organizational change management? Read more here