Improving Lookup Search Results

Hi my fellow citizen developers.  Lookups are a great way to relate objects together but can lead to a bad user experience if the lookup search isn’t configured well.

In this post we will be looking at a simple example of using a lookup field to define the instructor for a class.  So below shows the instructor field where we enter the last name of the instructor to be assigned to the class.

LookupExample1

When we click on the lookup icon we see several results from our lookup search.  Unfortunately we have no additional information to determine which Ben Smith is the one we need to assign as the instructor.

LookupExample2

To help users find the right instructor we need to include additional information in the lookup search to help them choose.  To do that we need to modify the Search Layout on the object that is holding our instructor information.

LookupExample3

Go to the search layouts for the object you are using, in this case I am using Contact.  To help my users find the right contact record I am adding the contact’s title, department, reports to and email information in the Lookup Dialog.  So when a lookup search is done, more information is displayed.

LookupExample4

Now with this information my user should be able to select the correct contact to assign as instructor for the class.

Hope this helps you with your configuration setup and user experience design.

 

 

 

Using Salesforce to Manage Expectations

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.

meeting1

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.

screen-of-code1

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.

<Case Example 1>

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

Changing How a Date is Displayed

Dates are formatted differently depending on the country.  If you find that the dates are displaying in a format that you are not familiar with or do not prefer, you can change it by changing your locale.

date-formats1a

Go to My Settings – > Personal -> Language & Time Zones

Change Locale and save.

Example:

I logged into my org and entered a date.  It displayed as 29/11/2016. (DD/MM/YYYY)  Although I can understand what it means, it is not my preferred way of viewing dates.displaydate1

So I went to  My Settings -> Personal -> Language & Time Zones

sfmysettings

sflangtimezonemenu

Here is what I saw:

sflangtimezones1

I changed Locale to something more appropriate for me

sflangtimezones2

So going back to the same record the date now looks like this:

displaydate2

A Waterfall Analyst in an Agile World

business analystsHello fellow Salesforce Citizen Developers!

I’ve been working in some technology related function for most of my working life.  One of the key roles I have done is that of analyst.  Now analyst can mean different things to different people and even different things depending on the context of the work.  For this post think of an analyst as the person who helps the business clarify what needs to be done to meet a current business need.  In other words, analysts write requirements.

I know that some of you are cringing now with that simplistic definition but the point of this post is not to extol upon the definition of an analyst but to point out some key differences I have encountered regarding analysis work when working within a waterfall methodology and when working within an agile methodology.

Let’s first get some clarification around “waterfall methodology” and “agile methodology” in the context of this post.  In my experience what we call “waterfall” is basically defining everything waterfall-vs-agile2that 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.

As for “agile” the steps are similar but the work is done in small increments (called sprints) and pieces of the solution are delivered earlier than with waterfall methodology.  You also need, as I discovered, to unlearn some things you did in “waterfall” or the analysis work will bog down the agile process.

So what have I found that I needed to change to more effectively work within an Agile methodology?like-want-need

Create “Good Enough” Requirement Documentation

In Waterfall it is common to create a massive Business Requirements Document (BRD) that details every little thing.  You review it with your IT team and then walk away while they create a solution.

For Agile the business and tech work much more closely together so a doorstop of a document isn’t needed or, for that matter, wanted.  Instead the analyst should facilitate meetings between business and tech and talk through what needs to be solved and why.  The group then defines the requirements (stories) together at a level of detail that is good enough for everyone to be on the same page regarding the solution.

doco1Meet More, Document Less

I like to create documents.  There I said it!  I even used to be called the Doco Queen because I created some whopping huge and detailed Business Requirements Documents.  I also prefer to send all my fabulous documentation to folks to review instead of meeting. I have since learned that this is not the best way to get things done in an Agile way.

When you only have a sprint (typically 2 – 3 weeks) to get something defined, developed, tested and accepted you need everyone in the room and talking through each requirement.  Even for a team not located together, talking things through via phone, Skype, telepresence or some other mechanism, is preferable to reviewing documentation.  You need the give and take of a conversation to understand what the business needs and how you might go about building the solution.

So I have learned to document that basic requirement in the form of user stories and leave the details to the group sessions (typically called “grooming refinement sessions”).

Define What is a Successsuccess-criteria-1

To help everyone understand what “done” means regarding designing and building a solution, I have learned for each and every requirement the high importance of answering the question – “How do I know that this requirement has successfully met my business need?”

As an analyst this is an important part of the job when working with business partners.  Helping them to articulate what they would need to have/see/etc in order to consider what has been built to successfully meet their need.  This step can be hard for some folks but it is vital.

In Summary

So as a citizen developer I wear the analyst hat often and with great gusto.  I just need to remember to put on my Agile Analyst hat when I am working within an Agile world and define good enough requirements with only what’s needed documented including well defined criteria for success.

 

 

 

 

 

 

 

 

 

Blog Site Review – 89 Sites and counting!

As a citizen developer it is important to be in touch with the Salesforce community and to learn how others solve problems.  For me I have almost always been able to find the answer to my question either in the success community, developer forum or from a blog site.  In my quest for answers I have so far identified 89 Salesforce related blog sites and I find more every day.

I thought it might be helpful to you if I share what sites I have found so you too can benefit from them.  So I will begin a series of posts focusing on a different blog site.  I will provide (where I can) some basic statistics, an overview of the information found on the blog and key posts I have found helpful.

Basic Stats:

  • URL of the site
  • Primary owner of the site (person or company)
  • Date of first post
  • Total number of posts as of date of my summary
  • Post Categories/tags

I hope you will find this series helpful.  Let me know what you think.

blog5

Focus on ‘Why’ instead of ‘How’

Knowing the how is necessary.  Understanding the why is illuminating.

Knowing how to perform a task is necessary.  Understanding why the task needs to be done can help you achieve a deeper understanding of the task and the process to which it is related.why what how

Knowing how to implement a solution in Salesforce is necessary but understanding why the solution is needed is much more important and illuminating.   Many times users will ask for changes based on their perception of how to fix the problem.  These changes sometimes address the immediate need but not the underlying problem that created the issue in the first place.  By asking users why they need a specific change, the analyst can get to the heart of the problem and help find the best solution to address the underlying problem so the issue will not happen again.

According to a new study in the Journal of Consumer Research, people who become focused on how to achieve a goal may have a harder time achieving their aims than people who think abstractly about why they want to do something.

Question

Can you share an example when knowing the ‘why’ helped with finding the best solution?

 

Good, Better, Best Requirements

I have gathered and documented thousands of requirements for hundreds of applications over
the years.  Good requirements are easily understood by the IT team and are testable.

I recently found a great post by David Shaffer called “It’s the clipboard2Requirements fault! A Recipe for Requirement Clarity “.  He really provides a clear concise method for developing solid requirements.  Below are a list of questions from his article that I highly recommend any analyst consider when gathering and documenting requirements.

For each requirement you ask the following questions:

  1. Is the requirement written in S-V-O format? (Subject-Verb-Object)
  2. Is the requirement written in active voice using a strong auxiliary verb?
  3. Does the requirement focus on the business need rather than a technical solution?
  4. Is the requirement easy to understand by all audiences?
  5. Is the requirement simple, short, and unambiguous?
  6. Will an example improve the understanding of the requirement?
  7. Will a visual figure or wireframe improve the understanding of the requirement?
  8. Can the requirement be tested?
  9. Does the requirement contradict any other requirement?
  10. Does the requirement describe how it must be implemented (Ex: display in alphabetic order, ascending/descending order, required/optional field, alphanumeric, numeric, etc.)

Question

What are some questions you normally use when gathering requirements?