Requirements

10 reasons that make design absolutely necessary

  • Reading time:12 mins read

Unfinished buildings, by net_efekt (on Flickr)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. And so on and so forth.

As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.

Here I list the ten most important reasons that I believe make design absolutely indispensable.

Continue Reading10 reasons that make design absolutely necessary

Setup-dependent requirements

  • Reading time:3 mins read

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.

When I brought this issue to my customer’s attention, they said: “but we only have one single inventory account, and we only use one single posting group, so we don’t need this functionality to be smart about this”.

This was an example of what I like to call setup-dependent requirements.

Continue ReadingSetup-dependent requirements

Sure Step in action: a blurry Degree of Fit?

  • Reading time:4 mins read

image 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. In either case the degree of fit is unreliable and it doesn’t tell you anything at all.

For a degree of fit to be reliable, all the requirements should be specified roughly on the same level of detailedness. If they aren’t, you might have an extremely risky project before you, and you just don’t see it. Or you might have a slam dunk, and you stand scared to death by the non-existent risks you see all over.

In situations such as these you have to level the requirements to get a more meaningful figure, otherwise your Fit Gap Analysis doesn’t serve its purpose.

But how exactly do you tell apples from oranges in a requirements list?

Continue ReadingSure Step in action: a blurry Degree of Fit?

4 strategies for a favorable Degree of Fit

  • Reading time:8 mins read

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. According to field reports, this approach often fails.

There are four things you can do to ensure the customer satisfaction while keeping the project in budget and still reducing the risks by increasing the degree of fit.

Let’s see what they are.

Continue Reading4 strategies for a favorable Degree of Fit

Requirements and Process Review – Critical vs. Non Critical

  • Reading time:5 mins read

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. As such, it is an indispensable input into further decision accelerators and the implementation project itself.

One of the activities done in scope of this decision accelerator is identifying high-level implementation issues which are then classified into critical and non-critical. I’ve done some requirements and process reviews and had a chance to discuss it with consultants and project managers, and I’ve often found people to be somewhat confused with the logic behind this classification, because at the first glance it seems totally reverse: what you could call critical shooting from the hip, is in fact non-critical, and what you could say is non-critical, turns in fact to be critical. And it requires some general shift in the point of view of what consultants are generally used to in scope of typical gap analysis activities.

Continue ReadingRequirements and Process Review – Critical vs. Non Critical

3rd rule of agile ERP: focus on value

  • Reading time:5 mins read

image – “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. Or by shipment date. Maybe some other date as well.”

– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”

And it must be a disaster if you agree to half of these.

Continue Reading3rd rule of agile ERP: focus on value

5 steps to implement ERP the Agile way

  • Reading time:4 mins read

Roadside waterfall by digitaldust 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 is an unpopular word in ERP world. We, the ERP people, love the glory and the thunder of The Waterfall. It has worked for us since forever, after all. Yes, we’ve all seen it fail every so often, but we’ve learned to learn from failure, and we know there is no better approach. Don’t we?

Frankly, I am not completely sure we do.

Continue Reading5 steps to implement ERP the Agile way

Is agile ERP implementation possible?

  • Reading time:3 mins read

image 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.

At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.

With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.

Continue ReadingIs agile ERP implementation possible?

Sure Step in action: Degree of Fit

  • Reading time:5 mins read

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. And of course, it can’t have that automatic transmission—I don’t care if it’s not a hybrid car, it simply must have the continuously variable transmission, no matter the cost.

I’ll never have a car like this.

Continue ReadingSure Step in action: Degree of Fit