If 2008 was the year of the economic crash…. it would seem fit to believe that 2009 will be the start of a recovery.

This is the perfect opportunity for us to refresh our focus and begin the discussion of how Requirements and BA empowerment is a cornerstone to helping our respective companies maximize the value they see out of IT software projects.

Why “Value?”

With the focus on cost-cutting, and the cancellation of “extraneous efforts and projects” dominating meeting rooms in many of the Fortune 500, the idea of “optimizing” of existing investments is now the topic of modern times.

When we speak with BA’s in the Internet community, we hear how clear, precise, and validated requirements efforts help drive efficiencies that cut waste.  By cutting waste, BA’s are in fact the hinge to driving value for modern projects.

But this discussion is more than just about cutting waste… it is also about ensuring that the actual IT software/system actually adds … here’s that word again … value.    If you think about it, software projects are not a supporting actor in business operations, they are (in most cases), the competitive advantage that organizations use to run their business.

One of our reader emails nicely summarizes this point of view:

“The customer facing applications my team develop have a huge impact on how well we do as a company.    When our offshore development teams make mistakes and incorrectly understand our requirements, we end up introducing a difficult to use system to our customers.   This impacts everything:    Customer Retention. Satisfaction. and at the end of the day, Revenue.

“95% of  these mistakes come from the fact that we do not spend enough time reviewing our requirements before coding begins.” - Mark Thomson.

Big “V” vs. little “v”.

If software systems are our competitive advantage, and as Mark indicates, impacts everything down to the revenue of the company, then the value of successful projects ensures that our companies can compete in this economic climate.   This is a much larger discussion than simply cutting costs, its about ensuring viability for our business initiatives in this climate.    Let’s call this big V.

A great example of successful software transforming a business is Apple’s iTunes and the new Apple Appstore for iPhone.   This entire business is a self-service software application, that sits in the cloud, and processes millions of transactions a minute.      According to Apple’s recent quarter end results, this combination of software and hardware (iPod/iPhone)  was the catalyst to the top-line growth that enabled the company to break through the $10B per quarter barrier in today’s economic climate. 

This application is all about the ease of use, instant availability, how well it works with other systems (PCs, Macs), and the library of assets offered.    Clearly, Apple is enjoying success due to the value of this complex project.

Could you imagine the requirement’s JAD session for this project?   I seriously doubt the requirement definition session was cut-short, or the analysis time-line was trimmed, or they didn’t validate the requirements specs completely…  this is a classic example of software designed specifically for end-user delight.

From our perspective, Business Analyst’s hold to key to big V Value as they have the subject-matter-expertise and business context that organizations must infuse in design, development, testing, and project management functions of IT.    As such,  BA’s bring the “why”, “what”, “who”. and “how” to the table, and IT development facilitates these requirements with innovative systems.

As far as little v value, well, our point-of-view is that “little v” is the very-imporant efficiency component of IT projects.  If you have a $3M budget, you better not turn in a $5M bill.    Many analysts have written facts about the impact of “poor requirements” and the mess that rework has created on project timelines and budgets.

A great quote from one of our reader comments summarizes this nicely:

“Our last customer service application budget was for 3.27M over 12 months, for two major versions We ended up only completing only one version, as the initial project crept forward after UAT. My company revamped the project plan to accommodate this learning cycle as the PMO called it.

The problem was that this wasn’t a learning cycle. It was a failed cycle. We spend hourly with our team of outsourced development, and all of this roles to the project budget.” - Richard.

So, little v is important too.    If a company has to spend an extra million here… or there… to fill in the gaps from poor requirements, thats a million less it can spend marketing and selling it’s products.  In today’s economy, there are less “millions” available for overun such as this.

Enough… lets start the series.

So, we start a new series focusing on Value from the BA (both little v and big V).   We look forward to working with the community and bringing forward spirited comments, debate, and interviews as we discuss BA empowerment as a weapon against the economic downturn.