Blog: Rick Barton Subscribe to this blog's RSS feed!

Rick Barton

Hello and welcome to my blog. I am delighted to blog for the BeyeNETWORK, and I'm really looking forward to sharing some of my thoughts with you. My main focus will be data integration, although I don't plan to restrict myself just to this topic. Data integration is a very exciting space at the moment, and there is a lot to blog about. But there is also a big, wide IT and business world out there that I'd like to delve into when it seems relevant. I hope this blog will stimulate, occasionally educate and, who knows, possibly even entertain. In turn, I wish to expand my own knowledge and hope to achieve this through feedback from you, the community, so if you can spare the time please do get involved. Rick

About the author >

Rick is the director (and founder) at edexe. He has more than 20 years of IT delivery experience, ranging from complex technical development through to strategic DI consultancy for FTSE 100 companies. With more than 10 years of DI experience from hands-on development to architecture and consulting and everything in between, Rick’s particular passion is how to successfully adopt and leverage DI tools within an enterprise setting. Rick can be contacted directly at

An interesting statistic in a recent survey is that:

"A third of businesses in this country said that keeping project requirements as constant as possible, without allowing too many changes, was key to cutting costs."

I absolutely agree with this statement, however it is quite difficult to achieve.  How many of us 100% understand what we want from a delivery months before go live.  How many of us in the technical world can produce a design that absolutely reflects the business requirements 100%?  How many people within the business can sign off a technical requirements in the certain knowledge that it delivers 100% to their requirement.

I can tell you the answer to these questions, none of us.  Certainty is not a word that is often used in the development lifecycle, especially around translation between business requirements and technical specification. 

So is there a way that project requirements can be kept as constant as possible?  I think there are approaches that can help mitigate against change, or others that allow for change, but none that can eliminate it altogether.

Technology can help but needs to be more business friendly.  It is widely accepted that the more that the business can do in a project, the more successful that project will be, so the easier a technology is to use and understand, the more likely it is that they will use it proactively. 

Agile can help in that it is an approach that allows for change, however adopting Agile can be difficult and does require a step change in thought processes.

Ultimately the answer rests with communication.  IT and business need to find ways of communicating requirements and potential solutions in a manner that breeds mutual understanding. 

My personal view is that effective prototyping is the key.  It is standard to produce "mock ups" in many design functions in many industries, so perhaps we in the data world should take a leaf out of their book and find ways to share technical ideas in a much more "tactile" fashion.


Posted December 11, 2009 4:31 PM
Permalink | No Comments |

Leave a comment