Requirements and Process Review – Critical vs. Non Critical

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.

3 thoughts on “Requirements and Process Review – Critical vs. Non Critical”

  1. Great one, Vjekoslav.

    I am currently undergoing one such blunder committed, in spite of myself constantly insisting on a “Realistic Business Study & Product Mapping”.

    This article would hopefully open several “intentionally blind” eyes.

    Vaidy

  2. Hi,
    I think you looking at the problem from “Programmer” point of view… From “Business/Implementation” point of view both this issues can be Critical or Non-Critical.
    Essentially you are saying – “The second issue is critical because my programmer can mess up the code…”. What for many people will mean – I do not have good programmers and I do not have proper testing in place.
    I think you need Metrics that will be more aligned with the business value of the task. We have created metrics for Agile System implementation that allows minimizes time to go live and minimize negative cash flow. I do not want go into specific example but based on our metrics First Issue will be identified as critical and second will not even placed into initial implementation (assuming inventory records pretty good – as you said they do cycle counting…). Second issue will be implemented as part of continues improvement process…

    1. Hi Valentin, and thanks for the comment!

      Actually, I am not looking at this from “programmer” point of view, I am actually looking at it from long term business value perspective. If you consider the effect customizations have on the system customizing the system is risky. I agree that true agile approaches have certain benefits, but Sure Step itself addresses the agile pretty well itself. The thing is that at this stage in Diagnostic phase, you don’t have an idea whether you are going to deploy the solution with Agile, Standard, Enterprise or even Rapid. My reasoning behid the explanation is not to offer the programmer’s perspective, but to illustrate why the logic is somewhat inverse to what people might expect. This is also not to say that this is The One True Way of conducting this type of analysis, but this is the right way if you are following the Sure Step methodology. If you are applying your Agile System methodology and it works for you, then you are totally right with what you say here.

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.