What Do We Do?

As referenced in the recent post from my colleague on the Seilevel sales team, our ongoing challenge is to articulate why anyone should hire us to help them with better requirements. If nearly 20 years of selling have taught me anything it is that if you can help a prospective customer see your solution in light of their own problems, you are one step closer to winning their business. This post is an attempt to help our prospective customers understand exactly what we do – and perhaps picture themselves in the scenario.

A couple of months ago we had recently launched a new look and feel for the Seilevel website. In the first version we purposely kept the content simple and to the point, with an underlying rule that there would be “no scrolling”. Keeping everything above the 600 pixel line helped with the billboard effect we were striving for, but the site was very text intensive and we needed more graphic elements to illustrate our services. Constrained by our small company marketing budget, but looking for the kind of visual diagram made famous by Xplane, we were forced to get creative.

Our talented local design partners were more than happy to take on this challenge – but numerous brainstorming and whiteboard sessions were not getting us any closer to what we thought would showcase our offering. Then, on a sales call one day a prospective customer described exactly the scenario we needed in our diagrams. We knew it was time to stop making it up, and just listen to what our customers were telling us.

Here’s the commonly occurring scenario we heard that day: The business users in an organization determine their objectives and describe what they are looking for to IT. The IT team spends time building the application based on what they heard and deliver back a product that doesn’t meet the business users’ expectations.

It’s a story as old as the software business itself. As we all know, even after the first CHAOS report in 1994 revealed that the top three causes of project failure are requirements related; things in 2006 aren’t all that much better. Even now, only 29% of software projects are successful.

At Seilevel, we know it doesn’t have to be that way. We determine what the stakeholders and application users really need, get business and IT on the same page and ensure that the requirements are defined clearly so the development team can build a product that truly meets the needs of the organization. That’s our definition of project success.

Unfortunately, Seilevel is not yet of a size and reputation that we get involved early enough or often enough. Often, by the time we get involved, our role is to try to get the train wreck back on the rails. When it comes to software projects, the attitude of many organizations seems to be analogous to our medical system – no funding is available for preventative care, but there are millions of dollars available to put the patient on life support when they slip into a coma.

An up front investment in requirements will pay off in software project success. And more time on requirements doesn’t add time to the overall project, as better requirements mean less time on development and less time on test. Less time equals less money.

So, please check out our new diagrams. And if you can picture yourself in the first scenario, maybe it’s time to give Seilevel a call and see if we can help you define success for your next software project.