Requirements

Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time.

While designing a custom functionality for a customer, there was an issue with posting groups: the way the custom functionality was designed would result in value entries being always posted to a single posting group, resulting in inventory balances always going to the same inventory account.

Sometimes the Degree of Fit might seem like comparing apples and oranges. With 90 extremely detailed fits, and 10 high-level gaps, the degree of fit seems high, but it isn’t. 90 extremely detailed gaps, and 10 high-level fits, make the degree of fit seem low.

If your Degree of Fit is just not there, or the balance between it and the budgetary estimate is not favorable, the risk that project will exceed the budget or not meet the requirements is high, but you might still decide to go on. In fact, most consultants often do, choosing to fight the odds.

Requirements and process review is one of the decision accelerators in the Diagnostic phase of the Sure Step, aimed at gaining deeper understanding of customer’s business processes, and documenting high level requirements, as well as possible implementation issues.

– “We need a report which groups our sales by product components.” – “And we need it broken down by cost centers.” – “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.” – “And it must let you choose if it is by posting date or by document date.

In my previous post I’ve (what, again?) shared some statistics about success and failure rates of software projects in general and ERP projects specifically. It seems that ERP projects fare somewhat worse than generic software projects, which I stated might have a lot to do with how requirements are handled.

Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.

The degree of fit is an important indicator of your project’s alignment with the standard functionality. After you determine the degree of fit, and understand what it means for the project, do you just passively accept the findings, or do you do something to make them more favorable?

I’d like to have a BMW X6 . A fantastic car. Only, I’d like it to be convertible, because I love the feel of wind in my hair while driving into summer sunset. I could use a glass roof as well, it makes the interior feel much more spacious.