Blog

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.

According to delivery guide for Requirements and Process Review decision accelerator, any requirement (functional, non-functional or integration), any business process that maps directly to the standard solution, doesn’t need to be listed as an issue. Whenever there is something that doesn’t map to the standard solution, that’s an issue. So far so good.

The catchy part comes when you further classify issues into critical and non-critical. Sure Step is very clear about this – when you have a requirement or a process that doesn’t map at all to the standard functionality or process flow in a standard solution, then this is a non-critical issue. However, if you have something that maps, but only partially, then this is a critical issue. I’ve seen people go huh? at this point.

If you are not among them, just skip the rest, it’ll be boring 😉

So why is critical critical, and non-critical non-critical. First reaction is often that if you need something, but can achieve it partially, it should be marked as non-critical, and if there is something that you can’t achieve at all, this should be critical. Right? Er, not quite.

Imagine that you have a house. A standard solution. Now you have two requirements: 1) you need two computers, one in your living room and one in your study; and 2) you need the two computers to be connected with a wired Ethernet connection.

If the house doesn’t come with either two computers or Ethernet wiring throughout, obviously there are some issues here. How critical are these two issues then?

The issue with not having two computers in the house is non-critical: you go, purchase two computers, plug them to the wall outlet, and you’re good to go.

The issue with connecting them through Ethernet wiring might be pretty critical – to fulfill it you might need to drill some holes in the walls, or even carve some electrical tubing through several rooms and walls.

With simply installing the two computers, you are not really affecting the standard solution, you enhance with something that it didn’t have before, but you don’t generally change the function or the structure of your house.

With installing the Ethernet wiring, you are actually modifying the pre-existing structure of the house and it might get real bad: if you are not careful, you might easily damage the existing functionality of the house – the electrical installations, heating installations, or even the statics; if you are extra non-careful, you can tear down whole walls (hopefully not the whole house).

Now apply this to the requirements and the standard solution. If a requirement cannot at all be met with the standard solution (which means there are no touching points, or there may be some touching points, such as tapping into the existing functionality, but not really disrupting its structure, then this is non-critical – you keep the standard as it was, you just extend it with something brand new.

If a requirement can be partially met by the standard solution, but for the part which cannot be met you’ll need to jackhammer the standard functionality away to make room for something new and improved, you have a critical issue.

Okay, enough philosophy and abstraction, let’s nail it down now.

Imagine you have two requirements: on the sales order you need a lookup text box with indication of the warehouse person responsible of handling the picking of the goods in the order; and you need to ensure that during the posting of the sales shipment if an item does not exist in the bin specified in the sales line, but exists in another bin in the same location, that the posting procedure first posts an item movement from the bin where it exists into the original bin, and at the same time notifies the warehouse manager to schedule an extra inventory counting activity.

Obviously, the first requirement is non-critical – there is no lookup text box with an indication of the warehouse person responsible of handling the picking; so all you’ll need to do is go to the table, add a field, then go to the form/page and add the control, set some properties, and make a not in object documentation about the change you did. Nothing critical here.

The second one is a monster. If you are not careful, you can easily mess up the posting procedure, break standard functionality and cause total mess in the data and nightmare in the warehouse. Now this is pretty critical, even though 90% of this requirement is just standard posting functions, and 10% is some extra if thens and a bunch of simple function calls.

That’s why critical is critical, and non-critical is not.