EBG What Clients Say Before Working with Us

Trouble Delivering ROI

We waste millions of dollars a year not knowing what to build or doing rework because we didn't explore our requirements sufficiently to begin with.

The entire team and organization loses time and money when we deliver poor-quality software products.

We spend countless hours in meeting after meeting discussing and reviewing requirements issues. It wastes a lot of time, and is frustrating. We keep rehashing the same questions and issues. It takes a loooong time to get issues clarified enough for some software before it gets implemented!

We spend time and money defining and documenting good requirements practices, templates and procedures for our analysts to use. Then, nobody uses them because these procedures "get in the way" of getting the job done.

Agile development methods has opened the eyes of both IT and business management regarding the importance of collaboration and upfront definition in iterations. But they don't have the skills and tools to figure out what to build in those iterations, or how to make the decisions about what to build.

Struggles with Business Analysis and Requirements Exploration

Both IT and the business are desperate to stop the treadmill of not delivering the right software solution in a reasonable time (spending a lot of time and resources), having strained IT-business relationships (people dread being assigned to certain projects when there is a poor history among the business-IT groups), and losing in the marketplace because our software isn't giving us the competitive advantage we need.

It's really hard to "extract" or "gather" requirements when users and customers don't really know what they want or need in the first place. Because of habit, we fall back on interviews and unproductive meetings to review textual requirements. Then later we realize there are a lot of missing things. Sometimes, we test and find missing requirements late in the game.

We are trying to use agile methods, and are losing time and money refactoring our technical architecture because we didn't explore product requirements sufficiently to begin with.

Our customers don't really know what they want in a software product just vague ideas. Then, when we document some of these ideas, they keep changing their minds, causing a lot of rework and confusion. So, we put controls in place to stop or avoid the continual changes so we can build something. Then, they complain that we aren't being "flexible" or "business-focused".

Strained Business-IT Relationships

IT and business partners get frustrated and angry when they cannot clearly define what features and functionality should be built. Subsequently, they become overly rigorous in documentation or take the other extreme, and are too loose with defining needs.

Getting business people to show up for requirements work is a real challenge. Sometimes it seems like we are expected to know what they need by "mind meld" or osmosis. We have trouble getting real subject matter experts to work on defining requirements. It seems like they keep changing their minds!

The business people speak a different language. Well, okay it's their business-speak, but they expect us to understand what they mean and they roll up all kinds of meanings in a single word, or phrase!

Projects take too long to start up, or get mired in miscommunication issues. IT doesn't involve the business enough early on in a project or ask the right questions to avoid misunderstanding about what the product is.

IT people speak their geek language and expect us to know about IT stuff when we're telling them what we want. They sometimes show us funny diagrams and expect us to approve them. Or they write long boring sentences that are supposedly formalizing our requirements and these are hard to follow. Or they shove these other documents (e.g. use cases) at us, and we're expected to just sign off. Huh? This is their stuff, not mine!

It takes up far too much time of our most critical people asking questions again and again, making poor use of those people's time, and showing us long, boring documents and expecting them to agree that the content of the documents are what we need them to do.

**What our clients say after working with us**

Our clients share their outcomes with you. Read more