Skip to Content

From time to time I think all of us fall into the trap. We think to ourselves “this is just a small service request (SR) or slight enhancement.” We sell ourselves as being able to design, build, test, train and implement a new or enhanced business process without vocally speaking with our customers. Yes, they sent an email or posted an SR with their requirements, but did the customer understand the systems available functionality? I’m sure we replied with an email asking a couple of questions about a handful of details they may have missed in their original request.

 

Do we really need to talk directly to our customers? The answer is yes. We should look at implementing a simple service request in the same manner we implement a complete application or better yet a system. Even though I’m positive we all have examples, a small enhancement would not take as long as delivering a complete system. However the same process steps are relevant and critical for success: the process is just faster than a large scale project.

 

Much like a quality improvement project with brainstorming, cause and effects matrices (C&E), and failure modes and effects analysis (FMEA), the define phase of any software change is important for understanding the customers requirements. With a good success rate, I have used a Design for Six Sigma (DFSS) approach even when just performing simple system maintenance. By following this approach, I Define the goals and customer requirements, Measure and determine customer specifications, Analyze the functionality options, Design the process, and Verify the design through functional, performance and user acceptance testing. Much like the Six Sigma DMAIC methodology (Define, Measure, Analyze, Improve, Control), DFSS takes a focus towards designing new (or redesigning) products and services.

 

By using a QFD (Quality Function Deployment) tool I can quickly capture customer requirements, system capabilities and time estimates and measure through weighting. The higher the score for each requirement may be important to the customer, but may also be very costly to implement. From there I can move the QFD top hitters to an FMEA.

 

Getting off on the right foot with a define phase will save time during testing, redesigning, and testing again. In theory, you will be able to deliver the enhancement to the customer much sooner as you will deliver the product right the first time…meeting your customers expectations.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo
    We don’t have large blue printing sessions for everything.  Complete integration testing?  Again no.

    But not consulting our internal customers???!!!!  That’s a big never.  They are the owners of our system.  And sign off on everything.  If the enhancement touches any area they are involved to some degree.

    If not – well disaster comes to mind.

    Michelle

    (0) 
    1. Robert Pierce Post author
      I certainly see your perspective Michelle. One point I keep in mind that a blueprinting exercise does not need to be large to be successful and can be coined as a business requirement document.

      Cheers!

      (0) 
      1. Michelle Crapo
        In that case – I totally agree.   We always do business requirement documents.  It just makes sense.  After all we don’t change the system for fun.  There is really a business need driving the change. 
        (0) 
  2. Chris Paine
    I think the Agile development movement has shown recently that you do not need to define, specify every last change in order to have successful and cost effective implementations. However, as you mentioned, you do need to bring your users into the conversation.

    And by doing this you can save your company an awful lot of money that would be wasted in soon to be obsolete documentation.

    Define – nope, collaborate – absolutely.

    (0) 
    1. Robert Pierce Post author
      Great point Chris.  I did specifically focus on waterfall as not all SAP minded have adopted agile as a methodology. I agree there are many instances where Agile is a better “project” approach.
      (0) 
  3. Kumud Singh
    Hi Robert,

    Very well agreed with your customer interaction part. But I think this approach is not feasible for all the project scenarios. I think you could have given some practical examples wherein this approach should be followed and some wherein it cannot be followed.

    Thanks,

    Kumud

    (0) 

Leave a Reply