We all have expectations. Some are little and some are not. In the world of software development expectations can result in you being a hero or a failure. So how can you make sure everyone is on the same page as the requested enhancement is developed and deployed and how can Salesforce support this process?
How to Manage Expectations
Do Not Make Assumptions
Each person is coming from a different set of skills and life experiences than your own. Do not assume that they see things as you do. Meet with the business and tech team separately and together and make sure what is expected, how it might be accomplished, and most importantly… how success will be measured are discussed and agreed upon by all parties.
Communicate, Communicate, Communicate… and oh… Communicate
Communicate with the team frequently using different methods and formats.
Pushing Out the Information
One set of methods are of a category called “Push” where information is pushed to the stakeholders and team.
Meetings
We all love meetings, right? (eye roll) Sometimes they can be useful if we keep them focused (e.g. have an agenda) and short (e.g. Use a parking lot to stay on point).
- Daily Status Meeting – primarily useful with the development side of the team. Check in with everyone daily to see how things are progressing and to identify any issue that is stopping or hindering progress. Try to keep these meetings short and sweet.
- Weekly Stakeholder Status Meeting – primarily useful with the business side of the team. Provide updates to stakeholders on the progress of the work and discuss any identified issues or risks.
Reports
- Status Report – weekly report that covers (1) what was done last week; (2) what is being done this week and next week; (3) open action items; (4) Timeline; (5) Budget; (6) current risks, constraints, assumptions
- Executive Summary Report – similar to status report but at a much higher level of information and may only be needed every other week or so
Pulling Information from a Source
Another set of methods are of a category called “Pull” where stakeholders and team members go to a source and pull the information as needed.
Shared Enhancement lists
A list of enhancement requests (projects) which can be viewed by business users and technology team members provides all with clear understanding of the pipeline.
Shared To Do or Task List
A list of assigned tasks for an enhancement request or project provides everyone with a clearer view of how resources are aligned to the work and the level of effort needed to complete it.
Shared Issues, Assumptions, Risks, Constraints List
Every change comes with some assumptions, risks, constraints and capturing them in a shared list will help everyone have a clearer picture of the change. Issues also can arise as the work progresses so having a shared list to capture these helps to provide transparency to all interested parties.
Push Back As Needed
Part of managing expectations is helping everyone understand what can be realistically achievable given the scope of the work, the timeframe to deliver and the available resources. If the business wants more or wants to radically change the original request, have an honest discussion about what that would mean to the work already done and the expected completion time.
Using Salesforce to Manage Expectations
Capturing the Information
Capture Enhancement Requests
First thing you need is a way to capture change / enhancement requests. I have found the easiest method is to use CASE and either provide users with a web page (web to case) or email address (email to case) for them to submit requests.
<
>
Make sure your CASE includes fields to capture the following:
- What problem are you trying to solve?
- Why do you need to solve this problem?
- Who is impacted by this problem?
- How are they impacted by this problem?
- When do you need this problem to be resolved?
- Who from the business need to be involved in solving this problem?
- What systems are affected by this problem?
This is not an exhaustive list of questions and you may have more that you normally use. The idea is to make sure you capture all the information you need on the CASE as it will be the primary source of information for you and the team.
Capture Issues, Constraints, Assumptions, Dependencies
As mentioned earlier, everyone comes to a project with assumptions or pre-conceptions and these should be captured along with any identified constraints and dependencies. Also as work is done issues do come up and need to defined in a place open to everyone on the team where they can be seen and worked.
I have played with these four categories of lists for years and currently use something I call “Considerations”. By having one custom object called Considerations and then using record types for each (Issue, Constraint, Assumption, and Dependency) I can have a single place for all of the information without needing more than one custom object. Win win in my book.
As an issue/constraint/assumption/dependency is identified, it becomes a consideration related to the case.
Capture Notes
As people are working on the case it is important that they document what they are doing, have done, plan to do, etc. Also meeting minutes should be associated with the case.
Although Salesforce has a NOTES object, I find it difficult to use because I need to type my notes (meeting minutes, status, analysis, etc) which currently cannot be done on the standard NOTES object. Never fear the Citizen Developer is here! I created my own NOTEs object and related it to CASE so that all the great information is captured here.
Capture Tasks
Who is working on what can be easily tracked in Salesforce using activities (tasks) related to the case. They can be simple tasks or have additional custom fields as needed.
Communicating from Salesforce
Now that you’ve put in place the structure and process to capture change/enhancement requests and all the related information, it is time to provide that great information to the world… or at least the stakeholders and team members.
Reporting
- Status Report – create a report off of the Notes__c object for a specific case and schedule it to run weekly and be distributed to the project team and stakeholders (“push”) or have interested parties run the report as needed or subscribe to it (“Pull”).
- Executive Summary Report – executive level reporting could be handled by a dashboard that is run weekly and sent out via email (“Push”), available for executives to run on demand (“Pull”) or (if you want to get fancy) a visualforce page that renders as a tricked out pdf that someone sends out (“push”) or available for executives to select (“Pull”).
Shared Lists
- Current Assignments – Users can see who is working on what by running a report or by using a list view from Activities.
- I found it great to create a visualforce page that displays activities and then create a set of list views to provide the information users would need to see
- Request Pipeline – Users can see the pipeline by running reports or through list views on CASE. Using a set of statuses that have been clearly defined with all team members and stakeholders will provide everyone with an understanding of how many requests are in the pipeline and where each request’s place in the process currently is.
- Issues/Assumptions/Constraints/Dependencies List – Users can see open issues/assumptions/constraints/dependencies for a case by accessing a related list. For me that is considerations but you could have a separate custom object for each type.
Summary
While some aspects of expectation management cannot be fully supported by Salesforce (not making assumptions, facilitating various meetings), several aspects can be supported very well as discussed in this post. In my experience I have been able to manage and track several thousand change requests and keep the lines of communication open and humming using CASE and several custom objects (CONSIDERATIONS, NOTEs).
Question to You
How do you manage expectations? Have you been able to use Salesforce for some of that work?
Resources
Hello fellow Salesforce Citizen Developers!
that the business needs or wants upfront, documenting in detail each item, developing the solution, testing the solution, deploying the solution. You can think of a waterfall where at the top is the business saying what it needs and at the bottom splashing into the river below is the deployed solution.
Meet More, Document Less
Salesforce Citizen Developer 