Recently I received the ‘mantle’ of the owning our Account + Contact data in our CRM dogfood system. It had been a while since we made significant changes to the use of these entities, so I needed a strategy before I commenced customization. I won’t bore you with what we use the system for (it’s probably only exciting for me). The approach I took to collect the requirements and implement the changes might be of interest.
Stakeholders
CRM systems typically have lots of stakeholders. Rarely do these stakeholders agree. My approach is to usually keep them separate during requirements gathering. Placing them in the same room and on the same email threads will normally lead to confusion.
Data Points
Understanding who is using what pieces of data is critical to combining the requirements for the disparate stakeholders. I created a spreadsheet listing each Account/Contact attribute and flagged which stakeholders were using each one. I was then able to send out filtered versions of that sheet to each stakeholder so they could ensure the right data points will exist for their process.
User Interface
Now that we understand what attributes will be unique to each business process we can begin to design the forms. Here are some general ‘rules of thumb’ to remember:
· Place Business Required attributes on the first tab.
· You don’t want these hidden in one of the background tabs.
· Place as many shared attributes in the first 1-2 tabs.Create unique tabs for each business process and place attributes unique to those processes there.
· When naming sections – don’t be afraid of using sentences.
Acceptance
Achieving user acceptance is never easy. A minor change requested by one stakeholder may be considered a major revision for another. Most stakeholders will want to see/feel the user interface before accepting your design. My first step is to send out static screenshots of the forms. However I restrict these to only the tabs used by each stakeholder. Email is usually the best way to handle acceptance. Meetings can be dangerous here: as they open you up to late breaking feedback. There is always v2 where you can improve things. What is important is forward velocity: make the change, ensure it isn’t crazy, get feedback from actual users then improve.
Implementation and Feedback
When changing the entities I didn’t delete any attributes. This is super important with this approach – since we don’t labor over each change. It’s also important to commit to doing a second version (about 2-4 weeks) after these changes. By restricting the initial acceptance/feedback of stakeholders it’s inevitable that some may feel ‘unfulfilled’. It’s important that you strike a balance between making changes in a timely fashion (ie. Not taking months & years to implement business processes) and giving too much ‘discussional freedom’ to your stakeholders. We have all seen IT projects wallow in eons of requirements gathering and feedback. Having a good understanding of the ‘cultural DNA’ of your organization is very useful in this regard.