Getting business requirements right: the essence of project success

There are a number of reasons for project failure, but requirements issues are near the top of the list.

Those "issues" may include the business seeking to include all possible requirements that customers may ever need, thus increasing complexity, cost and impacting upon time to market. At the other extreme, there may have been too little effort put into defining the business requirements, which can lead to scope-creep, where there's pressure to expand functionality after the project is underway and budgets and deadline have been signed-off.

What's the answer to requirements issues? You need a robust requirements analysis and modelling framework; you need to prioritise business requirements, assessing which functionality is "must have now" versus "may be developed later"; and a highly skilled Business Analyst.

>> View: "4LOOP's Business Requirements Analysis fact sheet."

The need for a "better way" to run IT projects.

Much has been written recently about dissatisfaction in corporate Australia with the performance of IT projects. Headlines have included, "Another fine mess" (Kath Walters, BRW Jan 12-18, 2006) and "Dodging disaster" (Eric Wilson, The Australian Dec13, 2005).

The BRW article quoted a 7 year Standish study published in 2004 which found that only 29% of IT projects were deemed successful (that is, on-time, on-budget with required features and functions). While a KPMG study (Sept 2005), reported in the same BRW article, found that half of its 600 respondents worldwide had experienced at least one IT failure in the previous year, and 86% reported losses of up to 25% of their project's targeted benefits.

Against this backdrop, some common key factors have been acknowledged to help ensure project success:

- Smaller projects are more likely to succeed, so break larger projects into smaller ones.

- Creeping or changing scope needs to be managed and controlled

- Reduce project complexity - simplify wherever possible.

These key success factors are perfectly aligned with 4LOOP's "better way" of developing IT projects.

Best practice in project performance management: Earned Value (EV)

EV management was developed by the US Department of Defense, and is recognised as best practice in project performance management. EV is concerned not just with time elapsed and the cost of a project, but importantly, what has been achieved or "earned" at a given point in time. It helps ensure that there are no unpleasant surprises at the end of a project.

EV management and tools are central components of our approach to project management. (Contact us to receive an Earned Value Primer)

Is 4LOOP's proof-of-concept approach an agile or RAD methodology?

While 4LOOP's proof-of-concept or staged development approach sees an initial commercial release developed quickly, and provides organisations with the "agility" and flexibility to adapt to changing customer and market needs, it's not strictly an "agile" methodology nor a "rapid application development" (or RAD) process.

Our approach shares some of the best elements of these other methodologies (with "agile" - iterative development, and with RAD - visual development and re-useable components) but has more formality and greater project management rigor, which generally provides organisations with greater peace-of-mind.

From a technical perspective, solutions we develop provide a solid and extensible architectural foundation, using highly re-useable components. While from a business perspective, we focus on understanding and delivering business outcomes rather than just building something that appears to work.

"Create a sense of urgency and work collaboratively"

A response to a CIO article by Michael Hugos, Move it or lose it (5/4/2006), about the agile and innovative use of IT.

>> View: "Move it or lose it"