Tell me a story -- Requirements gathering Part 1

[britta]

Here you are--you have purchased ServiceNow, you have identified your team, and everyone has been trained.  Enthusiasm is running high, and everyone is itching to get hands on the keyboard to start doing great things in ServiceNow.  Gathering requirements seems like a distraction.  I mean, everybody knows what they want, right?  We don't need to review current state, because that is all going away.  That will just slow everything down. 

These are some common misconceptions that I have encountered when I ran projects with customers.  I am going to show why requirements gathering is so critical, and why taking time to do it right from the start will save time in the long run. 

Forming, storming and norming

Bringing the team together to document requirements usually kicks off the  process of forming, storming, and norming  which is one of the reasons why companies try to limit the amount of time spent by only collecting requirements for the new process, or restrict the number of people involved or avoid this stage entirely.  Requirements gathering can be a painful process that surfaces unresolved issues, and it does take time.  The problem is, if the team doesn't get to "norming" now, issues will fester continuously and slow down the project.

Limiting the time for requirements gathering gets the project gets going quickly.  However, it will start to bog down, when you have to go to another team to clarify a question, and that discussion opens up a whole can of worms you didn't know existed.  Then you try to put band aid solutions on the problems that need a tourniquet because you don't have time to really fix them.  This can multiply over several groups.  And the belief that you will go back and clean up things after go live is a fallacy. 

When you straggle into UAT, you will find gaps, issues, etc.. because requirements gathering wasn't ever really completed. Or worse yet, you decided to skip UAT entirely because you don't think you have time for that either, and on go live day it’s a disaster-- you're missing steps, functionality, and more.

Other people will just slow things down!

Another common strategy to "accelerate" the process is by having a very small team do requirements gathering.  How many times have I heard -- "Other people will just slow things down."  I don't disagree that there is a "sweet spot" for the size of the team depending on the scope and size of the project.  But you need to choose team members thoughtfully to represent all the areas of the process adequately. 

Proper representation is critical because it is rare that one person knows everything about a particular process.  Also, what is an improvement for one person, could create a blocker for someone else because they don't have the full context.   While the book, The Goal, is centered on a manufacturing company and outdated from an HR perspective, the concept of removing one bottleneck only to create another can apply to any industry.  It is aptly illustrated as they play bottleneck whac-a-mole before they understand all the interactions in their system and create the optimal flow.

So, it is better to have a complete team moving slower than to find out two weeks before go live that you are missing key capabilities, missed an integration, or worse.  Because by not having enough representation or the right representation, you may build what you think is best in class only to find out the consumers of the platform think you've gone backwards instead of forward.  

Don't include the difficult people

I have also seen people be excluded from teams because they are difficult or detractors of ServiceNow. However, if you take time to listen to them, they often have a point; it’s usually their delivery that puts you on the defensive immediately.  Turning noisy detractors into champions is challenging but worthwhile to have them to advocate for you. Also, in Move fast and fix things, the authors stress the need to work with people who think differently than you do.  Otherwise, you keep creating the same solutions.

We don't need to document

The next way companies often try to save time is by NOT documenting the current process at all.  "We just need to move on."  "There is no value to documenting current process."  Yes, the current state will be going away, but pieces of it will come into the new platform.  Also, by not examining and challenging the existing system, how are you going to find the gaps or improve it?

Two things normally happen when current process isn't documented.  Your team has a hard time articulating the new process without understanding the current one.  You will keep referencing it, and then that can spin out into a debate about how the existing process works.  Then the current state gets documented in an ad hoc and disorganized way after all.   

Another reason to review and document the existing process is because at least one person on the team is making assumptions that may or may not be true.  Recently in an internal project I was working on, the decision was made to skip documenting the current state <sigh>.  Sure enough, later in the project, one person stated an assumption that was not correct, and it actually was the catalyst for a complete shift in the direction of the project for the better.  If only we had had that insight six weeks earlier!!! 

I hope you can understand now that it is better to work through strong emotions, many opinions, and the myriad of demands at the beginning of the project.  Also, if you find unanticipated blockers or realize the scope of discovery is much larger than expected, you can signal a delay immediately, request more budget, etc...  Typically, teams procrastinate as long as they can before telling management about issues, but delaying projects closer to go live generally creates some panic, and it does not reflect well on the project team.  

I also cannot stress enough that organizational change management (OCM) starts RIGHT NOW...people need to know what won't be changing as well as what will, what's in it for them (WIFM).  But more on that in another post...

That's it for my overview of what not to do when gathering requirements.  In the next installment, I'll talk more about the actual requirements gathering process. 

[Cire]

Really interesting article !! Thank you for sharing

[PaulSylo]

Awesome @britta  very nice article. 

[KrinaP]

Yeah, I agree with you; writing skills are very good, which i like the most .