Agent of Change

Identify the business owners of the current state and schedule a kickoff meeting to have them walk you through every step in the process. Ask them why they do what they do, what does each step do for them exactly and you will naturally begin translating these things (“business requirements”) into salesforce.com solutions (“functional requirements”).

(P) = Personas: all users/teams impacted (the Team Charter);

(B) = Bombs: the major business problems and pain points (where are we losing data / reporting abilities, the things that are unknown but shouldn’t be); and

(J)  = Jams: the bottlenecks/delays; often jams are the low hanging fruit that you can solve for easily just because salesforce.com is awesome. Get great at identifying jams and people will think you are magic! Jams come disguised like this: “lots of emails back and forth” (solved w/ validation rules on forms or approval flows!); “we don’t know what the stage is” (solved w/ a status field!); “we are never notified when it is complete” (solved w/ workflow email alerts).

Document the proposed ideal future state. Don’t just take what the business tells you they want and recreate it exactly. Take what you have learned and apply salesforce.com to make everything better! They don’t know what they don’t know about salesforce.com, but you now know what you didn’t know about their process so use that to your advantage and design something even better than they could have asked you for. Make sure you create the current and future state in a flow diagram and visualize the PB&Js so they understand exactly how the new process will impact them (and how it will make their life easier!) — this step is especially important if you are trying to get approval to move forward with a large initiative.

Translate the future state into actual business requirements (BR) (i.e. what the business is asking you to solution in order to consider the project a success) and add your own salesforce.com functional requirements (FR) for each (i.e. what is the technical requirement you will build to “manage opportunity stages for pipeline visibility”). Send this document to all stakeholders for approval to ensure you did not misunderstand or miss any requirements.

If you are designing a car the MVP might be a working bike but it absolutely can’t be a state-of-the-art engine without a place for a person to sit (the point of a car is to get a person from one place to another after all!). Design your app in a sandbox and give your stakeholders a demo. Take their feedback and keep iterating until you are at a place to start testing.

Quality assurance testing should be done by the SME/Super users. Give them training documentation (and live training if possible) and watch as they test to make sure you didn’t miss anything critical. Be with them during testing as much as possible to ensure you capture their clicks and issues/pain points as they happen so you can quickly iterate.

Document the features to be included in the enhancement project and define a schedule. Sometimes on larger projects you want to go live with one team and then a second team later (Sales first and then marketing; or sales opportunities and then RFPs as phase II, etc.).

Document the release notes and end user training (SF knowledge articles work great for this!) and create a Chatter Group where users can give feedback, ask questions and collaborate with you and each other in real time! Provide live training whenever possible.